凌晨两点，我把一个 4.2 GB 的种子做完了第 37 次校验

磁力兔 笔记：一个 infohash 是怎么从 40 个字符变成 4.2 GB 的

昨天凌晨一点四十，我坐在书桌前，把一块用了四年的外置硬盘插上，屏幕右下角的托盘图标闪了一下。我在终端里敲下 aria2c 加一串以 magnet:?xt=urn:btih: 开头的地址，回车之后，日志第一行跳出来的是 INFO - DHT: 8 nodes returned in 412 ms。那一刻我没觉得这东西有多神秘，反而觉得它像一个被拆开的钟表：齿轮都在，只是没人愿意去看。

这篇笔记想做的事很具体——把磁力链接从字符层到文件层走一遍。我参考了 BitTorrent 社区在 2023 年公布的一份 DHT 测量报告（报告里统计了 12 个公开爬虫节点、共 4.7 亿条 infohash 的存活情况），也参考了自己过去 6 个月在 3 台机器上留下的下载日志。数据不一定权威，但足够让我把话说清楚。

先说结论里我最想强调的一点：磁力链接本身不存文件，它只存一个 40 位十六进制的 SHA-1 摘要，所有关于「这个链接能下到什么」的想象，都是 DHT 网络用几十个节点、几百毫秒替我们补齐的。理解这一点之后，很多争论其实可以停下来。

上面那行日志不是摆设。我用一台在杭州的旧笔记本反复测了 20 次，第一次拿到 peer 列表的平均时间是 412 毫秒，最快一次 187 毫秒，最慢一次在 1.9 秒，那次是因为路由器刚重启、NAT 还没打通。8 个返回节点里，有 5 个位于欧洲，2 个在北美，1 个在日本。这个分布跟我原本的直觉不一样——我以为离得近的节点会更快，实际上响应速度和地理距离的关系没那么强，跟节点是否长期在线关系更大。

下载完成后，客户端会按 piece 逐块校验 SHA-1。我这次下的那 4.2 GB 文件被切成 1024 个 piece，每个 4 MB 出头，校验一共跑了 37 次才算通过——不是 37 遍全量，而是其中 37 个 piece 在第一次校验时失败、被重新拉取。失败的节点集中在两个 IP 段，后来我在日志里看到它们的上传速率都在 3 KB/s 以下，基本可以判断是坏块来源。这个数字让我对「下载完成」四个字多了点敬意。

上周四下午我在小区门口碰到做运维的老周，他问我最近在折腾什么，我说在整理磁力链接的结构。他笑了一下说：「你们这些人总把它当技术问题，其实一半是元数据问题。」我当时没接话，回家翻了三个小时资料才承认他说对了一半——tracker 的淘汰、DHT 的普及、种子的存活周期，这些确实更像元数据治理，而不是纯粹的网络协议问题。

一句可能不太受欢迎的判断

说实话，我认为现在大部分关于磁力链接的讨论都被高估了——不是话题被高估，是「讨论的方式」被高估。人们热衷于争论某个站能不能用、某个链接是不是失效，却很少有人愿意花十分钟去看一眼 infohash 的结构。这种讨论方式把一个可拆解的技术对象，变成了一场关于「我能不能下到」的情绪交换。我不同意把它当作纯工具看待，它至少值得被当成一个可阅读的协议文本来对待。

这半年最明显的教训是：问题几乎都出在元数据层。种子在不在、tracker 活不活、peer 是不是坏块，这些才是 90% 的麻烦来源。协议本身很老实，它甚至把失败原因都写在日志里了，只是没人看。