# ngosang/trackerslist is rewritten every day, and the protocol files overlap

> Eleven plain text lists of public BitTorrent trackers, regenerated daily by a bot, with no releases and no code. The per-protocol files hold 95 entries between them against a 74-entry all-list, the IP variants are a smaller and different set, and the WebSocket, I2P and Yggdrasil entries need infrastructure most readers do not have.

**ngosang/trackerslist** — GitHub describes it as Updated list of public BitTorrent trackers. The metadata lists the GPL-2.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/ngosang/trackerslist
- Website: https://ngosang.github.io/trackerslist/
- Stars: 55,254 · Forks: 6,582
- Language: Unknown
- License: GPL-2.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ngosang-trackerslist

## There is no version to pin, because the files are rewritten daily

Start with the constraint that shapes everything else. The page states that the lists are updated automatically every day, and it prints the date of the last update above them. There are no GitHub releases, no tags and no version numbers, and the repository has no code to speak of, only data. The consequence is that this is a feed and not a dependency. Any client configuration, script or download job that points at the master branch receives whatever was current on the day it ran, which is usually what you want and occasionally is not. The 20-entry best list is the sharpest case, because it is ordered by popularity and latency, so its contents and its order are a snapshot of one measurement pass rather than a durable ranking. If you need a fixed set of trackers, copy the entries into your own configuration and keep the copy, and treat the upstream list as something you refresh deliberately.

## The per-protocol files hold 95 entries between them, not 74

The eleven files are not a partition, and the counts give it away. The all-list holds 74 entries. The UDP file holds 47, HTTP 17, HTTPS 10, WebSocket 3, I2P 17 and Yggdrasil 1. Those six add up to 95, which is 21 more than the whole. So entries appear in more than one protocol file, which makes sense for a tracker reachable over more than one transport and means the protocol files are a filter view rather than an additive set. The consequence is a real trap for anyone building their own list by hand: concatenating the six protocol files and deduplicating nothing gives you roughly a quarter again as many trackers as the project actually maintains, and a client that treats duplicates as distinct peers spends announces on entries it already has. Use the all-list, and use the protocol files only to filter it.

## The IP lists are a different and smaller set, and Cloudflare is the reason

Three of the eleven files are offered as a workaround for DNS problems, containing the same trackers resolved to IP addresses. They are not the same set. The all-IP list holds 55 entries against 74, and the page gives the reason: Cloudflare addresses are removed from the IP lists, so nineteen domain entries simply do not appear. The best-IP list is the exception that proves the rule, holding the same 20 as the domain version, so nothing in the curated twenty sits behind Cloudflare. The Yggdrasil pair is stranger still, with 1 entry by domain and 4 by IP. The consequence is that the IP lists are not a safe substitute for the domain lists, they are a biased subset. A tracker fronted by a content delivery network disappears from them without warning, and since a fair share of public trackers are fronted that way, the list you get in a DNS emergency is smaller and differently composed than the one you would have got otherwise.

## The IP variant is the workaround most likely to rot

Resolving a hostname to an address is a snapshot, and the project does not say the IP files are refreshed on a different schedule from the rest. All eleven files are described as updated every day, so the addresses are redone daily too, which helps, but a tracker that moves to a new host will keep serving from an old address until the next pass catches up, and a tracker that changes address and is not reachable at the old one will fail in a way that looks like the tracker being dead rather than like stale configuration. The consequence is that the IP lists trade one failure mode for another. DNS resolution failure becomes a silently wrong address, and the debugging step is no longer obvious because nothing reports a bad address, the peer simply never answers. Use them when you must, and treat a tracker that stopped working overnight as a candidate for the domain list before you conclude the project dropped it.

## WebSocket, I2P and Yggdrasil need routers and clients most readers lack

Twenty-one of the 74 entries are for networks that need extra software, and the page is explicit about each. WebSocket trackers, also called WebTorrent, ws or wss, are said to be supported by few clients, and there are only three of them in the list. I2P needs seventeen entries and requires an I2P Router plus a compatible client, with four named as examples. Yggdrasil accounts for one entry and needs its own network router. That is nearly a third of the all-list gated behind infrastructure that a reader may not have and cannot infer from a line of text. The consequence is a silent one. Paste the whole list into a client that cannot speak those transports and the entries are not rejected, they are simply ignored, so you get a worse result than the file suggests and no error to explain it. Check your client's supported protocols before choosing a list, and remember that the count in the filename is not the count you will end up using.

## Deduplication is by domain or by IP, and the blacklist does the rest

The curation rules are stated and they are only two. A tracker should be removed if its owner explicitly says the library is not maintained, or if it has not been committed to for two to three years. And entries that share a domain or point at the same address are removed, with the removals recorded in a blacklist file at the root. That second rule is doing more work than it looks. A single host serving several useful trackers on different ports collapses to one entry, so you can lose a working tracker as collateral of a tidy-up that was only trying to remove a duplicate. The same applies to two hostnames on one address. The consequence is that the count in the filename is a count after merging, not a count of distinct things you can connect to, and a tracker absent from the list is not necessarily a tracker that stopped working. The blacklist is a single flat file with no review process described, so if you suspect a removal was wrong, the contribution path is an issue rather than a pull request.

## The repository is eleven text files, and issues are the only way in

Look at the tree and the project is exactly what it claims. There is a GitHub configuration directory, the licence, the readme, a config file for the site generator that produces the pages mirror, the blacklist, and the eleven tracker files. No source files in any language, which is why the repository's language field comes back empty. The contribution path matches. To add a public tracker or to report one that is not working you open an issue, and the page also points at a donation profile. The consequence is that updates are entirely on the bot's schedule. There is no pull request to make, no change to propose and no way to get your own tracker into the list faster than the next daily pass, so if you run a tracker and want it listed you are waiting at minimum a day and possibly for a maintainer to notice. For everyone else the absence of code is a feature, since there is nothing to build, run or break.

## Conclusion

Use ngosang/trackerslist as a daily feed rather than a dependency, and copy the entries you want into your own client configuration rather than pointing a client at the raw URL, because the files change every day and there is no release to fall back to. Do not concatenate the protocol files to build your own list, since they overlap and will give you 95 entries instead of 74. Two things to decide before you wire it in. Pick the domain lists unless you actually have a DNS failure, because the IP variants silently drop anything fronted by Cloudflare and go stale when a tracker moves. And check which of your client's supported protocols the entries need, since a fifth of the list is WebSocket, I2P or Yggdrasil and will do nothing without the matching router and client.

## FAQ

### Which BitTorrent tracker is the best?

The repository does not name one. It publishes a trackers_best list of 20 entries sorted by popularity and latency from best to worst, and those lists are regenerated every day by a bot, so the contents and the order reflect the last measurement pass rather than a fixed ranking. A tracker at the top today may not be there tomorrow.

### Where can I find a list of trackers for qBittorrent?

From this repository, which publishes eleven plain text lists and links to a qBittorrent bash script under its third-party tools section for adding them to a client. The per-protocol files cover UDP, HTTP, HTTPS, WebSocket, I2P and Yggdrasil, and every list is reachable from three places: a raw GitHub link, a GitHub Pages mirror and a CDN mirror.

### What are the top public trackers?

The trackers_all list holds 74 entries and trackers_best holds 20, both regenerated daily. Entries sharing a domain or resolving to the same IP address are removed and the removals are recorded in a blacklist file, so the counts are after merging rather than a count of distinct things you can connect to.

## Sources

- [Official documentation](https://ngosang.github.io/trackerslist/)
- [Official README](https://github.com/ngosang/trackerslist#readme)
- [Project repository](https://github.com/ngosang/trackerslist)

---

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