本文分享了一种PT下载的新思路，通过搭建一个Tracker代理服务器，有效规避了PT站点对下载量的统计限制。作者深入研究了BT和PT机制，发现客户端汇报的下载上传数据并非为严格限制Ratio设计，因此存在漏洞。通过实现一个Tracker代理，该代理能够缓存Peer列表，避免客户端直接向真实Tracker汇报下载信息，从而达到不计入下载量的效果。此外，这种代理方式还能整合不同PT站的用户，增加Peer连接数量，提升下载效率。作者还提供了一个简单的网页工具，方便用户上传种子并下载修改后的种子文件，以便添加到BT客户端使用。

💡 PT下载机制的潜在漏洞：PT站点主要依赖客户端汇报的下载（downloaded）和上传（uploaded）数据来统计用户Ratio。然而，这些字段最初并非为严格限制Ratio而设计，这为绕过限制提供了可能。

⚙️ Tracker代理的实现原理：通过搭建一个Tracker代理服务器，当BT客户端向其汇报时，代理会检查缓存中是否存在该种子的Peer列表。若存在且未过期，则直接返回；否则，向真实Tracker请求Peer列表，并将其缓存起来，以此实现不计入下载量的效果。

🚀 提升下载效率的额外优势：这种Tracker代理机制还可能整合来自不同PT站的用户。当两个下载同一种子但来自不同PT站的用户通过此代理连接时，他们的Peer列表会被合并，使得每个人都能连接到更多的Peer，从而提升整体下载速度和效率。

🛠️ 简易操作工具的提供：作者开发了一个简单的网页前端，用户只需上传种子文件，该工具会自动修改并下载处理后的种子文件。用户随后将此修改后的种子文件添加到BT客户端即可开始下载，操作便捷。

我入坑 PT 也快一年了，之前偶然读到了一篇博客，讲的是 PT 机制的几个有意思的漏洞。正好我对 BT 也不是很了解，就一路从 bencode 学到 tracker 协议，现在也算是对这块比较熟悉了。

PT 只靠客户端汇报的 downloaded 和 uploaded 来统计数据，而这些字段原本不是设计来限制 ratio 的，所以自然就留下了很多可以做文章的点。我就跟着博客作者的思路，实现了一个 tracker “代理”，当 BT 客户端向代理汇报的时候代理就会检查缓存里是否有这个种子的 peer 列表，如果有并且没过期就直接返回，否则向真实 tracker 发起一个“开始下载”的请求，得到 peer 列表并存储。这样就可以实现不计入下载量的效果。

而且可能还有一个额外的好处，就是如果两个人下载同一个种子，但是通过不同的 PT 站，那么 peer 列表会被整合，让每个人都能连接到更多的 peer 。

因为我不太会前端，所以网页做得比较简单，就一个按钮，把种子上传之后会自动修改并下载修改后的种子，然后添加到 BT 客户端就可以下载了。如果感兴趣可以试一试。

网站： https://tracker.submy.org

仓库： https://github.com/arielherself/btc