How Tracker Reachability Works
One of the most powerful features of the Torrent Tracker Analyzer is its ability to test whether trackers are actually reachable — not just listed in the torrent file. This article explains the technical process behind it.
HTTP Trackers: HEAD Requests
For http:// and https:// trackers, we use the browser’s native fetch() API with the HEAD method. This sends a lightweight request that asks only for headers — no body is downloaded.
fetch(url, [object Object]})If the server responds with any 2xx or 3xx status, the tracker is marked Success with response time in milliseconds.
CORS Limitations
Many trackers don’t send CORS headers. We use mode: 'no-cors' to allow the request to go through, but this means we can’t read the response status. In such cases, a successful network connection still counts as “reachable.”
UDP Trackers: Not Supported in Browser
UDP announce requests require raw socket access, which is not available in web browsers for security reasons. These trackers are clearly marked as “UDP (not checked)” in the UI.
Concurrency & Timeouts
To avoid slowing down the user, we check up to 10 trackers concurrently using Promise.all(). Each request has a 5-second timeout via AbortController.
Performance Example
A torrent with 25 trackers takes ~6–8 seconds total — far faster than sequential checks.
FAQ
Why use HEAD instead of GET?
HEAD is lighter and faster. Trackers don’t need to send scrape data during announce checks.
Can it detect tracker redirects?
Yes — 301/302 responses are considered successful if the final destination responds.
What if a tracker requires the info_hash?
Some trackers return 400 without it — still counts as “reachable” since the server is online.
Want to test your own torrent? Open the Analyzer