有一些 BT 下载任务卡在了 99.9%，似乎都是制作种子时没有分块对齐导致的。里面的文件已下载完成，只有几个无关紧要的小文件，不打算下载，因此希望禁用反吸血，否则正常客户端请求下载时，也会由于对方不提供数据而错误封禁对方。
注意：这种情况下只是允许 Peer 只下载文件，不上传，但是仍然遵循选项-任务-BT 下载-允许连接的 BT 客户端列表中的设置和 bittorrent.anti_leech_banned_client_names、bittorrent.anti_leech_banned_peer_ids 中的设置。
反吸血不会误封没有下载速度的用户，会计算tcp协议开销，也就是发ack的流量，也就是说0误封
不是，我是说有的任务迅雷下载后使用 BitComet 补种（BitComet 一直没进度），由于分块没有对齐，检查完整性后卡在 99.9%，所以实际上任务保持下载状态，所以反吸血也会生效，由于文件事实上已经下载完成，所以任何客户端几乎都不可能向我提供数据，符合吸血的行为，导致误封。
也有比较幸运的，刚开始也是卡在 99.9%，后来过了不知道多久，下载了填充的分块（.piece_part.bc!），进度成功完成，可以正常做种。
说的就是你这点，比特彗星的反吸血不会导致误封，比特彗星检测的不是下载大小，而是流量，比如对方与你连接后，对方给你发送"我需要下载"的ack数据包，那么对方就会产生上行流量，你这边反而其之成功收到了下行流量，这些流量在反吸血检测范围内，所以反吸血不存在误封的可能性，除非对方没有产生任何发送的上行流量与你交互
肯定不是的，就好比你在nas复制文件给你的电脑，你的网卡产生了950Mbps的下行流量，但是同时会有25Mbps≈30Mbps的上行流量，这些上行流量会发送给nas告知你需要下载和你下载的文件，nas才能知道你要做什么，然后把文件发给你
针对网络协议可以在网上了解一下，B站上也有很多视频
不对。你看其他做种的文件，这种是正常下载完成，没有卡 99.9% 的，那些用户不也是没有给我一点数据吗（下载大小 0 B），这种总不能说他们也是吸血吧。这个帖讨论的是那些没有分块对齐的任务，卡 99.9% 就无法做种的问题。这种情况下文件实际上只是缺了个 .piece_part.bc! 填充文件，文件本身是下载完成的。
比特彗星检测的不是下载大小，而是流量，流量是不会显示在"下载大小"里，而是显示在下载速度那一栏
可以看"状态"这一栏，只要封禁原因是反吸血，那么可以百分百确认对方是吸血客户端存在吸血行为，没有可能产生误封的情况
就好比你这张图，上传速度900KB/s，下载大小全部为0，但是你看是不是左侧的下载速度显示5KB/s，这就是产生的流量，比特彗星检测的是这个，所以不存在误封可能性
你可以试一下用一个没分块对齐，卡 99.9% 的种子，本地用 BitComet 做种，再开一个 qBitTorrent 下载，手动用 qBitTorrent 增加来源（127.0.0.1:<BitComet 端口>），下载限速 1KB/s，过几分钟看一下是不是被以 anti_leech 的理由封禁了
你说的问题测试的时候，反而测出来utorrent对于99%进度的任务，存在只下载一个区块的bug，对方不在请求其它的下载区块，使用utorrent连接utorrent自身都没有用，客户端不对对方发送需要下载的数据包，始终只存在1区块的bug
总结
因为没有区块对齐导致用户A单个文件进度99%的时候，使用utorrent用户B无法正常下载，需要联系utorrent开发者修复bug
测试过程中，qbittorrent和utorrent的毛病差不多，不过两者的问题还是有点区别，qb能正常进行下载开始跑进度，虽然收到的下载大小为0，但是检测到对方有发送ack，比特彗星显示有下载速度的时候，依旧被反吸血封禁
可能是这种情况下比特彗星检测下载速度计算流量有bug，被下载大小优先级覆盖了，可以让官方加一个任务单独设置忽略反吸血规则
试了一下，下载速度的判断应该是只在上传大小没有变化的时候才生效，比如双方都是50%进度的情况，此时大小没有发生改变，只有速度产生
如果触发了上传大小发生改变，那么下载大小的反吸血优先级最高，总体来说反吸血还是没有问题的，但是你这个情况确实需要禁用反吸血