qBit Tracker Safety — The Problem
The Problem¶
Why You'd Want Extra Trackers¶
Public torrents on obscure or aging content often struggle with peer discovery. The handful of trackers embedded in a typical .torrent file might be dead, rate-limited, or geographically slow for you. Adding more trackers increases the chance of finding live peers, directly improving download speed and swarm health.
ngosang/trackerslist is the de-facto public tracker list. It's community-maintained, auto-updated, and pruned for live endpoints. A single paste into qBittorrent's "Automatically add these trackers to new downloads" field expands every new torrent's tracker set by 20+ endpoints instantly.
For a stack serving only public content, that's the end of the discussion — turn it on, download faster, move on.
Why You Can't Just Turn It On¶
The global setting has no awareness of which torrents are private
qBittorrent's global "auto-add trackers" setting applies to every torrent the client downloads — including ones from private trackers. Private trackers ban clients that announce their torrents to unauthorized trackers. The ban is usually instant, permanent, and cabal-shared (propagates to every tracker run by the same admin network).
Private trackers detect this in three different ways:
| Detection | How |
|---|---|
| Peer scanning | The tracker connects to its own swarm from an unauthorized IP using peer info leaked via public trackers |
| DHT monitoring | Tracker ops run DHT nodes watching for their info-hashes appearing in public DHT |
| Scrape correlation | Public trackers that scrape the private tracker's info-hash get cross-referenced |
Any one of these is sufficient. Once a private tracker flags you, recovery is nearly impossible — accounts, invite trees, and linked accounts on other cabal-aligned trackers are all at risk.
Why You Can't Segregate By Category Either¶
A natural first instinct is: "I'll put private torrents in one category and public in another, then only inject trackers into the public category." This doesn't work in an *arr stack.
- Sonarr/Radarr hand torrents to qBittorrent using one category per download client (e.g.
tv-sonarr,radarr). This category is determined by the *arr app, not the indexer — so a show Sonarr grabbed from a private tracker AND the same show grabbed from a public tracker both land intv-sonarr. - Prowlarr's per-indexer category overrides help with new torrents but don't retag existing ones.
- qBittorrent only allows one category per torrent, so you can't mix category-based routing with
private/publiclabels without losing the *arr ownership tag.
What We Actually Need¶
A classifier that decides per-torrent whether injecting extra trackers is safe — using the torrent itself as ground truth, not metadata from Prowlarr or user-assigned categories. The next section covers the mechanism that makes this possible: the BEP 27 private flag.
Real scenarios this needs to handle
- You download from a private tracker via Sonarr; it lands in
tv-sonarralongside public torrents - You manually paste a magnet link from a friend — Prowlarr never saw it
- You add a new indexer to Prowlarr as
privateafter you've already been downloading from it - Bitmagnet serves public DHT content but Prowlarr flags it as
private(because it's a local torznab endpoint)
TL;DR
Globally enabling qBittorrent's trackerslist injection will permanently ban you from any private tracker it touches. Category-based segregation doesn't work because *arr apps mix private and public content in the same category. What's needed is per-torrent classification at the client level, using the torrent's own metadata as ground truth.