TrackersListCollection: A Daily-Refreshed BitTorrent Tracker List and What It Does Not Do
🎈 Updated daily! A list of popular BitTorrent Trackers! / 每天更新！全网热门 BT Tracker 列表！
At a glance
- What is it?
- XIU2/TrackersListCollection is a curated, daily-updated set of public BitTorrent trackers published as plain text files at four levels of filtering. It is a data distribution project, not a client, and its value depends entirely on how you feed the lists into aria2, qBittorrent, BitComet or Motrix.
- Who is it for?
- Adopt it if you run aria2, qBittorrent, BitComet or Motrix and want a tracker list you do not have to maintain by hand, and if you are comfortable that the list is assembled from other public sources rather than verified by you.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between a torrent file and a peer it can actually reach
A magnet link or a torrent without working trackers leaves a client with DHT and peer exchange as its only discovery paths. The README states the tracker's role plainly: it records which users are downloading the same resource so the client can connect them. That is the whole problem this repository addresses. It does not make transfers faster by itself, and it does not touch the BitTorrent protocol. It hands your client a longer, fresher list of announce URLs so that at least some of them answer.
The audience is narrow and practical. The README gives setup instructions for aria2, BitComet, qBittorrent, qBittorrent Enhanced Edition and Motrix. If your client is not one of those, the lists are still plain text and you can paste them wherever your client accepts a tracker field, but you are outside the documented path. The project is also aimed at people who would otherwise maintain their own tracker list, which is a chore that decays quickly because public trackers go offline without notice.
Four lists, one source pool, refreshed daily
The repository publishes four text files, and the README gives the tracker count for each as of the 2026-09-10 update: best.txt with 71 trackers, all.txt with 135, http.txt with 61, and nohttp.txt with 73. The naming is descriptive rather than technical. best is the filtered subset the maintainer considers worth using. all is the union. http contains only HTTP(S) announce URLs. nohttp contains only the non-HTTP ones, which in practice means UDP trackers, since those are the other scheme the README's aria2 example shows.
The lists are not assembled from the maintainer's own probing alone. The README names six upstream sources: ngosang/trackerslist, newtrackon.com/list, the itzmx OpenTracker mirror, tinytorrent.net, torrenttrackerlist.com, and DeSireFire/animeTrackerList. So the pipeline is aggregation plus filtering plus daily republication, not independent verification. That distinction matters when you are deciding how much trust to place in the best.txt label.
Distribution goes through several mirrors. The primary host is cf.trackerslist.com, and the README lists alternatives on Bitbucket, three jsDelivr endpoints (cdn, fastly, gcore), Statically, and raw.githubusercontent.com. The pattern in the alternate-address block is that you substitute the file name, so best.txt becomes all.txt or http.txt at the same host. That matters for anyone whose network blocks or throttles one of these domains.
Loading the lists into aria2.conf and the desktop clients
For aria2 the project publishes a second set of files with an _aria2 suffix: best_aria2.txt, all_aria2.txt, http_aria2.txt and nohttp_aria2.txt. The README instructs you to copy the contents and paste them into the tail of the bt-tracker= line in aria2.conf. The example it gives is bt-tracker=http://aaa.aa:80/announce,udp://bbb.bb:80/announce, which shows the expected shape: a comma-separated list of full announce URLs, no line breaks. The README adds an explicit warning to delete the old tracker content before pasting, to avoid formatting errors. That warning is the most operationally useful sentence in the document, because a stale fragment left on the line is the failure you will actually hit.
The _aria2 files exist because the default lists are formatted for graphical clients, where one URL per line is normal. Feeding a newline-separated file into a single config value produces a broken config, which is why the separate format exists rather than a note telling you to convert it yourself.
For the GUI clients the README relies on screenshots rather than text steps: BitComet, qBittorrent Enhanced Edition, qBittorrent, and Motrix each get an image showing where the tracker field lives. qBittorrent gets an extra collapsed section for versions below v5.0, which the README treats as a different UI path. If you are writing automation or documentation from this README, note that the GUI instructions are not reproducible as text. You have to open the images or already know your client.
What the project deliberately refuses to do
The README is direct about scope. It describes itself as a small project with simple functions, and states that Issues are closed and tracker submissions are no longer accepted. If you find an obvious error or want a tracker removed, the documented route is a pull request. That is a real constraint, not a stylistic choice. There is no issue tracker to report a tracker that has started serving bad data, no discussion of why a given URL made best.txt, and no published criterion for what separates best from all beyond the maintainer's judgement.
For most users this is fine. The lists are inputs, not dependencies, and a bad entry usually costs you a failed announce rather than anything worse. But if your workflow needs to justify why a particular announce URL is in your client configuration, this project cannot supply that justification. The upstream sources it aggregates may, but that means going to ngosang/trackerslist or newtrackon directly.
The update cadence is also worth reading carefully. The README says updated daily and stamps the page with a date, but there is no release history in the repository metadata, so the daily claim is a property of the publishing pipeline rather than something documented as a versioned artifact. You are consuming a moving target at a stable URL. If you need a frozen list for reproducibility, you would have to snapshot the file yourself.
Where a tracker list stops being the right answer
The clearest case against this project is when the problem is not tracker coverage. If a torrent has plenty of seeders and your client still stalls, adding 71 more announce URLs will not help, and the README itself points at this: it suggests judging your BT configuration and network by watching the download speed of the ubuntu.torrent file, on the reasoning that a popular resource should download quickly under normal conditions. That is a diagnostic suggestion, and it implicitly concedes that tracker lists are one variable among several.
A second case is privacy and control. These are public trackers. Your client announces your IP address and port to every one of them that accepts the connection. Someone who wants to limit which third parties see their swarm participation should not paste a 135-entry public list into their client. The README does not discuss this at all, which is a gap rather than a flaw in the software, but it is the kind of thing a reader should decide before following the setup steps.
A third case is a client that manages trackers itself or that you have configured with a private tracker. Public tracker lists and private tracker ecosystems do not mix well, and nothing here filters for that.
How it differs from ngosang/trackerslist and newtrackon
The obvious alternative is one of the upstream sources this project draws from, and the difference is not quality but role. ngosang/trackerslist is itself a curated list repository, and newtrackon.com/list is a service that reports on tracker uptime. TrackersListCollection sits downstream of both: it merges their output with four other sources, applies its own best/all split, and republishes on a CDN with multiple mirrors and a separate aria2 format.
That gives you two concrete things the upstreams do not necessarily give you in one place. First, the format variants. Having best_aria2.txt and nohttp_aria2.txt ready to paste is a small convenience that saves a conversion step. Second, the mirror set. If cf.trackerslist.com is unreachable from your network, the README lists six other hosts, and the same substitution works across all four list types. If you go directly to newtrackon, you get uptime information, which this project does not surface, but you get it in whatever format that service produces and without the best/all filtering.
The honest framing is that TrackersListCollection is a packaging layer. If you want to know why a tracker is in the list, go upstream. If you want a file you can paste into aria2.conf today without thinking about it, the packaging is the point.
Licence, maintenance and what the daily update costs you
The repository is GPL-3.0. For a collection of plain text URLs, the practical effect is mostly about redistribution: if you republish the lists or a modified version, the licence terms apply to that distribution. This is not legal advice, and if you plan to ship these lists inside a product, read the licence text rather than this paragraph.
Maintenance cost on your side is low but not zero. The lists change daily, so a one-time paste goes stale. The README does not document an update mechanism, a cron example, or a client-side auto-update setting. Keeping current means re-fetching one of the URLs and re-pasting, or scripting that yourself against cf.trackerslist.com or a mirror. There is no release artifact to pin, which is why a snapshot is the only way to get a fixed version.
On the maintainer's side, the README says energy is deliberately limited: Issues closed, submissions closed, pull requests accepted for obvious errors and removals. That is a sustainable posture for a data file, and it also means the project will not grow features. Expect the URL list to change and nothing else to.
Editorial conclusion
Adopt it if you run aria2, qBittorrent, BitComet or Motrix and want a tracker list you do not have to maintain by hand, and if you are comfortable that the list is assembled from other public sources rather than verified by you. Do not adopt it if you need per-tracker reliability data, if you require a submission or dispute process (Issues are closed and tracker submissions are no longer accepted, only pull requests for obvious errors or removals), or if your client cannot consume a plain comma-separated tracker string. Before wiring it into a config, fetch https://cf.trackerslist.com/best_aria2.txt and confirm the format matches the bt-tracker= line your aria2 build expects, and check that your client's version matches the UI path the README shows, since qBittorrent below v5.0 is documented separately.
Community notes