Trackers

A tracker holds no files, no pieces and no copy of anything being transferred. It keeps a short lived list of addresses for each info hash it has been told about, hands out a sample of that list when a client asks, and forgets any client it has not heard from in a while.

What a tracker is, and what it keeps

A tracker is an address book for one swarm at a time, and the entry it keeps for you is a network address, a port, a peer identifier and a timestamp. It does not know what the data is, it cannot reconstruct any part of it, and shutting it down removes the introductions rather than the content. A swarm whose tracker has gone offline usually keeps running on the connections it already made.

Two things separate a tracker from the other ways a client finds peers. It is a single point, so it can be blocked, overloaded or switched off, and everything it knew goes with it. And it is fast: one request returns a batch of live addresses in a fraction of a second, where a distributed lookup takes several rounds. That trade is why almost every torrent still names a tracker even though none is required.

What a tracker address looks like inside a torrent

The tracker address is stored in the torrent as an ordinary URL, in the field called announce, with any additional addresses in an announce list defined by BEP 12. An address has a fixed shape: a scheme, then a host name, then a port, then a path that ends in announce, and that final path segment is part of the protocol rather than decoration. The UDP form, specified as BEP 15, exists because the HTTP form was expensive at scale: a UDP announce is two small datagrams where an HTTP announce is a full request and response.

Those addresses are not part of the identity of the torrent. They sit outside the info dictionary, so editing them changes nothing about the info hash, and two torrent files naming completely different trackers are the same torrent when their info hashes match. That explains both why adding an address is harmless and why it is so often useless: the client announces to the new address, and the address either knows this info hash or it does not.

How to tell whether a tracker is answering

Every client shows the state of each tracker on a tab of the torrent's detail view, and reading it takes seconds. The columns are the address, a status, the seeder and leecher counts it reported, and the time until the next announce. A tracker that is not answering shows a timeout, a connection failure or an HTTP error, and the client keeps retrying on a widening interval.

Working

The last announce succeeded and the peer counts on that row came from this tracker.

Updating

An announce is in flight right now. Normal, and usually over in moments.

Not working

The last attempt failed. The message column names the reason, such as a connection timeout.

Not contacted yet

The client has not reached this row, often because an earlier tracker already answered.

Torrent not registered

The server answered and said it has never heard of this info hash. The tracker is alive; it simply does not serve this swarm, and it is working perfectly when it says so.

What announce and scrape actually ask

An announce is the client introducing itself and asking for peers in one message. It sends the info hash, its own peer identifier, the port it listens on, how much it has uploaded and downloaded, how much it still wants, and an event word such as started, completed or stopped. The tracker records the entry and replies with an interval and with a list of peers that is usually a sample rather than the whole swarm.

A scrape asks for numbers only and returns no addresses: how many seeders, how many leechers, and how many completed events are recorded for that info hash. That is where the counts in your client come from. A scrape is cheap and an announce is not, which is why clients respect the interval the tracker sends. Announcing more often gets a client refused rather than served.

Whether adding trackers makes a transfer faster

Adding tracker addresses does not increase speed, and it helps in one circumstance only: when the address you add already serves this exact info hash and knows peers your client has not met. An address that does not serve this swarm produces a row saying the torrent is not registered and changes nothing. Speed comes from the number of live peers holding pieces you need, from how much you are uploading, and from whether your client can accept incoming connections.

Transfers that genuinely lack peers are short of seeders rather than short of introductions. Before editing a tracker list, check the three things that move the number: whether availability is above 1.000, meaning a complete copy exists among the peers you can see; whether the client reports itself firewalled, meaning no incoming connections arrive and much of the swarm cannot reach you; and whether the distributed hash table and peer exchange are enabled, since between them they often find more peers than any tracker will. qBittorrent exposes all three on one screen. Protocol encryption is sometimes offered as a speed fix, and it is worth understanding on its own terms rather than as a performance setting.

What a tracker never holds

A tracker never holds the data, never sees a piece of it, and cannot serve you a byte. There is no such thing as downloading from a tracker: the download always comes from peers, and the tracker only said where some of them were. That also explains why a torrent whose trackers are all dead can still complete, and why one with four healthy trackers and no seeder will not.

A private torrent changes this in one way. When the private flag defined by BEP 27 is set inside the info dictionary, clients are expected to disable the distributed hash table, peer exchange and local discovery for that torrent, leaving the named tracker as the only route to any peer. That is a property of the flag in the file rather than of the tracker software, and it is why the tracker becomes a genuine single point of failure for those torrents alone. How a transfer works covers what happens once the peers have been found.