# adysec/tracker: a daily refreshed BitTorrent tracker list with a Rust checker behind it

> adysec/tracker is a data repository rather than a client: a daily job merges trackers from multiple upstream open source lists, runs a Rust checker over them, and publishes both the full list and per protocol subsets. Useful for anyone whose torrent client has an empty or dead tracker set, with the caveat that it only covers public trackers.

**adysec/tracker** — BT tracker 服务器列表，提供全网最全的 tracker 列表，每日聚合并测试存活服务器，trackers_all.txt 为全量列表（2902 行），trackers_best.txt 为可用列表（1137 行）

- Repository: https://github.com/adysec/tracker
- Website: https://tracker.adysec.com/
- Stars: 1,730 · Forks: 156
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/adysec-tracker

## A list on disk, not a tracker server

adysec/tracker publishes no tracker of its own. It is a text file repository plus a checking tool. The top level of the repo holds trackers_all.txt, trackers_best.txt, four per protocol variants of the best list, a blackstr.txt exclusion file, a date.txt stamp, a tracker_history.tsv, and the tracker-checker/ directory containing the Rust program that does the actual work.

The split between all and best is the whole design. trackers_all.txt is the raw merged pool, 2902 lines according to the project description. trackers_best.txt is what survives a connectivity check, 1137 lines. The four subsets, trackers_best_http.txt, trackers_best_https.txt, trackers_best_udp.txt and trackers_best_wss.txt, are the same filtered set split by protocol so a client that cannot speak one transport can still get a usable list.

The people behind it describe the motivation plainly. The README says the project started because too many public trackers performed badly while fetching torrents, and it says they wanted one aggregated, tested, frequently refreshed list instead. It also frames trackers as more than download plumbing: any tracker records the client IP and port, which the authors treat as threat intelligence material for mapping where a given torrent is downloaded from.

The last push was on 2026-10-15. The repository is not archived.

## Where the entries come from

Every entry in trackers_all.txt originates in someone else's project. The README names the sources it merges: ngosang/trackerslist, XIU2/TrackersListCollection, chenjia404/CnTrackersList, hezhijie0327/Trackerslist, DeSireFire/animeTrackerList and NewTrackon, plus other community maintained lists.

That means the repository inherits both the reach and the blind spots of its upstreams. If a source list goes stale or starts adding entries that no longer resolve, adysec/tracker has no way to fix it except through the daily filter, and the README does not document a dispute process or a contribution path for adding a new upstream. The .github/ directory holds the Daily Update Tracker workflow, which is what the status badge in the README points at.

There are no GitHub releases. Versioning, if there is any, comes from commit history and the files themselves, so a script that pins to a commit gets a stable snapshot and a script that hits the raw URL gets whatever ran most recently.

## Pulling a list into a client

There is no package to install. Consumption is a URL paste, which is why the client instructions are so short. For qBittorrent the README points at Options, BitTorrent, the automatic tracker field, and pasting the list URL. For Transmission it is Edit Preferences, Tracker, add tracker URL. Any other client takes the same URL in its tracker settings.

Two download mirrors exist for every list: the project's own host at tracker.adysec.com and the raw file on GitHub at raw.githubusercontent.com. The README calls the first the primary and the second the fallback.

```bash
# fetch the recommended list
curl -s https://tracker.adysec.com/trackers_best.txt

# fetch only the UDP subset
curl -s https://tracker.adysec.com/trackers_best_udp.txt
```

The output is plain text, one announce URL per line, so it pipes straight into a file or into another tool. Note what this format cannot do: it carries no announce key, no scrape token and no tiering, so it is useless for a private tracker and it tells your client nothing about which entry is likely to answer first.

## Running the same checker the daily job runs

The repository ships the filter itself, and the README documents the invocation. It is a Cargo project under tracker-checker/ that reads a merged list and writes the best list, and it takes a worker count.

```bash
cargo run --release --manifest-path tracker-checker/Cargo.toml -- trackers_all.txt trackers_best.txt --workers 40
```

The README describes this as the strict validation tool, the same one used in CI. That matters for anyone who distrusts the hosted file: copy trackers_all.txt, run the command locally, and compare the result against the published trackers_best.txt.

The one knob the README exposes is blackstr.txt, a newline separated exclusion list read from the working directory. Anything matching it is filtered out.

```bash
echo "192.168.1.100" >> blackstr.txt
echo "malicious-tracker.com" >> blackstr.txt
```

The README states that threat intelligence is integrated to drop malicious IP addresses automatically, but it does not name the feed, the update cadence of that feed, or what happens when it is unavailable. If that filter matters to you, blackstr.txt is the part you can reason about and the part you cannot audit from the outside.

## What a connectivity test cannot tell you

The filter is described throughout as a connectivity test, and that word sets a low bar. A tracker that answers an announce request is kept; the published counts, 2902 down to 1137, describe survival, not quality. Nothing in the repository indicates that slow responders, trackers that return stale peer lists, or trackers run by an adversary with a valid response are removed.

This matters because trackers are a rare case where the list is public and the traffic is not. A tracker sees every client that announces to it, together with the info hash and the port. The README itself notes this, and suggests the connection distribution can be used to reason about where a torrent is being fetched from and, during a breach, about the scope of an incident. A list curated for speed is not curated for discretion.

There is also no documentation of retries, timeouts, scrape behaviour, or how the history file tracker_history.tsv is produced and consumed. If a tracker drops out today and returns next week, the repository will not tell you why.

## Where it sits against the upstream lists

The alternative is not a rival product, it is the sources themselves. The README names ngosang/trackerslist, NewTrackon and several other projects as upstream sources for its tracker data.

The difference is in what gets removed. An upstream list is a curated or scraped inventory: it keeps entries because someone added them, and stale ones linger until a human notices. adysec/tracker runs the merged pool through a checker on a daily schedule and publishes only the survivors, plus protocol subsets that most upstream lists do not split out. In exchange, you accept a list that is only as good as one day's probe, measured from the project's own network, which may not resemble yours.

For private trackers, torrents with a real DHT bootstrap, or magnet links that never touch the HTTP tracker, neither approach changes anything. The problem adysec/tracker solves is narrow and it solves it every day, but it is narrow.

## Conclusion

Adopt it if your client has no working tracker set or you want a maintained public list split by HTTP, HTTPS, UDP and WSS; skip it if you run a private tracker, if you want anonymity, or if you need a guarantee about list size, because the repository publishes no test criteria and no release history. Before switching, diff trackers_best.txt against the list your client already uses and run the tracker-checker command yourself, since the daily job only proves reachability, not that a tracker is trustworthy.

## FAQ

### Which adysec/tracker list file should I use?

The README names trackers_best.txt as the recommended option, since it contains working trackers across all protocols and has the widest client compatibility. trackers_all.txt holds every merged entry without availability filtering, and the four trackers_best_* files are protocol specific subsets.

### Does adysec/tracker work with qBittorrent and Transmission?

Yes. For qBittorrent the README points to Options, BitTorrent, the automatic tracker field, where the list URL is pasted. For Transmission it is Edit Preferences, Tracker, then add tracker URL.

### Can I block a specific tracker in adysec/tracker?

Yes, by putting the address or domain on its own line in a blackstr.txt file in the working directory before running the checker. The README also states that threat intelligence is integrated to filter malicious IP addresses automatically, but it does not name the feed.

## Sources

- [adysec/tracker on GitHub](https://github.com/adysec/tracker)
- [Issues](https://github.com/adysec/tracker/issues)
- [License: GPL-3.0](https://github.com/adysec/tracker/blob/main/LICENSE)
- [Project website](https://tracker.adysec.com/)
- [README](https://github.com/adysec/tracker/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/adysec-tracker