你写了个小脚本，批量把种子投递给下载客户端，顺手给每条都配上几个公共 tracker，想着这样能提高连通率、跑得更快。跑了一阵子发现连通率一点没变。最后定位到的原因特别简单：配置本身没写错，只是改晚了。
现象
同一批种子，用两种方式加进客户端，结果完全不同：
- 通过客户端的搜索/订阅路径添加的种子，tracker 生效，能连上更多对端；
- 通过 API 直接投递（把种子文件或磁力链接丢给客户端）添加的种子，tracker 完全没生效，走的还是种子自带的 DHT。
两边的种子是同一批，tracker 列表也是同一份，唯一的差别是"从哪条路进去"。
更迷惑的是界面：进任务详情看，tracker 那一栏是空的。大多数人会把这理解为"没连上 tracker"，于是去查网络、查 tracker 地址有没有写错——方向从一开始就偏了。
根因
问题出在客户端读取 tracker 偏好的时机上。
这类客户端对 tracker 的处理是一次性读取的：它在"添加种子"这个动作发生的瞬间，去读一次当前配置里的 tracker 偏好，并把结果固化到这条任务上。一旦任务已经建立，之后再改全局的 tracker 设置，对这条任务不再有任何影响——任务已经带着它当时读到的（空的）偏好开始跑了。
而两条添加路径的差别在于：搜索路径在添加之前会有一步"应用偏好"的动作，直接投递路径没有。于是同样一份配置，一条路赶上了，另一条路没赶上。
这也解释了为什么"改配置 + 重启客户端 + 重新校验"全都无效：任务对象的偏好是创建时快照下来的，跟你现在配置里写什么已经没关系了。
解决
把 tracker 的设置挪到整个流程的最前面，在所有种子被添加之前完成：
# 错误顺序：先加种子，后设 tracker —— 已经加进去的那些不会生效
for torrent in torrents:
client.add_torrent(torrent)
client.set_preferences({"add_trackers": TRACKER_LIST}) # 太晚了
# 正确顺序：先把偏好写好，再加种子
client.set_preferences({"add_trackers": TRACKER_LIST})
for torrent in torrents:
client.add_torrent(torrent)
如果确实要用直接投递（API）这条路，还有两种补救办法：
- 在投递请求里带上 tracker——不少客户端的添加接口支持一个附加参数，允许在添加时直接指定 trackers，这样就绕开了"读全局偏好"的时机问题；
- 加完之后再批量补一层——对已存在的任务调用"添加 tracker"的接口，把列表补进去。注意这和"改全局偏好"是两件完全不同的事：前者作用在已有任务上，立刻生效；后者只影响未来新建的任务。
改完要验证的指标不是"配置里有没有这个 tracker"，而是任务里有没有：进单条任务的详情页看它的 tracker 列表，或者看它有没有连上更多对端。配置是意图，任务是事实。
延伸与预防
这类坑的通用教训是：工具的"一次性读取"配置，改的时机比改的内容更重要。
凡是遇到"配置明明是对的、就是不生效"，先问一个问题：这个配置是在什么时候被读进去的？ 大致分三类：
- 启动时读一次：进程起来之后改配置无效，必须重启（大多数服务的监听地址、日志级别都属于这一类）；
- 创建对象时读一次：像这里的 tracker，作用在"每个任务"上，只影响之后新建的对象；
- 每次使用都读：最灵活，改完立即生效。
这三类的排查动作完全不同：第一类要重启进程，第二类要重建对象，第三类才可能"改完就好"。分不清属于哪一类，就会陷入"改了没用、再改还是没用"的循环。
一个实用习惯：任何"批量添加任务"的脚本，都先设偏好、再加任务。 把"配置阶段"和"执行阶段"在代码里显式分开，比事后一条条补配置可靠得多。