Qbittorrent: 有没有办法阻止特定客户端（Thunder）？

并且我使用了反吸血上传拥塞控制策略。 （我不知道英文确切名称）

这里有一个您可能感兴趣的 qBittorrent 分支，请参阅https://github.com/c0re100/qBittorrent-Enhanced-Edition/issues/2

这里有一个你可能感兴趣的 qBittorrent 分支，参见c0re100#2

这似乎不错。
但是我很好奇原点qBittorrent是否愿意添加类似的功能。
如果可以，我更喜欢使用官方版本而不是 3rd 方版本。

我认为如果我们可以设置一些规则来匹配客户端并阻止它会很好。

比如屏蔽一个ip在xxxx到xxxx范围内的peer，或者屏蔽一个client name包含字符串'XL0012'的peer，等等。

甚至我们可以编写用户脚本来实现高级功能。

“而且我已经使用了反吸血上传拥塞控制策略。（我不知道英文确切名称）”

Anti-leech 是该选项在英语中的名称。
从这个链接： https :
“反水蛭播种算法基于 Chow 等人的论文“改进 BitTorrent：一种简单的方法”，并根据对等节点拥有的块数对其进行排名，更喜欢取消刚开始的对等节点和接近的对等节点完成。”
它比 5-95% 的完整随机同行上传更多给 0% 完整的迅雷（迅雷）客户端！

对抗无所作为的同行的一种更有效的方法是在所有种子上启用“常规”超级种子。 最大上传插槽必须低于连接的对等点数，否则 qBitTorrent 仍会上传到每个对等点。
严格的超级播种是一种更极端的形式，它不适用于连接少于 5 个对等点的种子——它最终不会在很长一段时间内上传到好的对等点。

不幸的是，如果您想将上传内容保持在最低限度，手动禁止对等点是必要的。 这可能需要为最坏的 ip 范围创建一个 ipfilter.dat 块范围。

“而且我已经使用了反吸血上传拥塞控制策略。（我不知道英文确切名称）”

Anti-leech 是该选项在英语中的名称。
从这个链接： https :
“反水蛭播种算法基于 Chow 等人的论文“改进 BitTorrent：一种简单的方法”，并根据对等节点拥有的块数对其进行排名，更喜欢取消刚开始的对等节点和接近的对等节点完成。”
它比 5-95% 的完整随机同行上传更多给 0% 完整的迅雷（迅雷）客户端！

对抗无所作为的同行的一种更有效的方法是在所有种子上启用“常规”超级种子。 最大上传插槽必须低于连接的对等点数，否则 qBitTorrent 仍会上传到每个对等点。
严格的超级播种是一种更极端的形式，它不适用于连接少于 5 个对等点的种子——它最终不会在很长一段时间内上传到好的对等点。

不幸的是，如果您想将上传内容保持在最低限度，手动禁止对等点是必要的。 这可能需要为最坏的 ip 范围创建一个 ipfilter.dat 块范围。

我知道了。 我从字面上取了选项名称。

所以，这意味着无论使用“超级播种”模式还是更改选项，官方版本都没有好的方法来阻止它，对吧？

和他们一样，我也不想向这些垃圾客户端上传任何内容。

我现在用的是3rd-party版本，感觉不错。

上传插槽限制低于最大连接数的超级播种在 1 个多小时的时间内运行良好。
一个 0% 的同行将获得一个其他同行很少/没有其他同行拥有的片断，直到其他同行报告拥有该片，0% 的同行不太可能从您那里获得更多上传。

阅读此页面后，我了解了超级种子模式的工作原理。

但是我不是最初的播种者，所有同行都可以轻松获得任何碎片，所以我认为它帮不了我。

超级播种不需要您成为初始播种者，它只是在那里更有效地工作 - 减少重复上传。 但是，您可能并不关心在 1 小时的间隔内将同一块上传到多个对等点，而不是将多个块上传到正在窃取的迅雷客户端。

theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

如图这种XL0012的迅雷客户端，不论你上传多少给他们，他回报的进度永远是0%，并且不会上传任何信息给你。

不信你自己去公网随便下载几个种子，就清楚了。

有些版本的迅雷(UA是迅雷的版本号，而不是XL0012)，是会上传的。

即使是9102年了，迅雷做过的恶依然不会消失！

“你快照里两个迅雷客户端的进度都是0%，怎么上传给别人？”

他们谎报他们的完成百分比，即使在种子和同行向他们上传了许多作品之后，他们也始终声称为 0%。

较旧版本的 qBitTorrent（大约 3.0.10 或之前？）在较小程度上做了同样的事情，部分原因是错误和/或编程疏忽。

我启用了 Strict Super Seeding 并将 Upload Chking Algorithm 设置为 Anti-leech。 然而，迅雷客户端似乎在流行种子的高峰时间用连接淹没了群体。 提高下载和上传速率的唯一解决方案是在连接时手动禁止带有客户端标签“-XL0012...”的 IP - 这非常费力。

ankushnarula，正如我之前在这个问题线程中已经指出的那样，反水蛭使问题变得更糟而不是更好。
此外，常规超级播种比严格超级播种更有效——无论是在轻微抵抗水蛭攻击还是在对付敌对同伴方面。

需要有一种更全面的方式来处理敌对的同行。 不幸的是，禁止敌对客户端需要自动化/自动，但由于其逻辑中可能存在错误，因此可以通过一种方法来禁用它。

对不起。 我误解了。 但是，我通过反复试验得出了您的结论。 这似乎也不会在每个 Torrent 分布式共识方法之外得到公平解决。

在 2019 年 4 月 24 日 18:46，

ankushnarula，正如我之前在这个问题线程中已经指出的那样，反水蛭使问题变得更糟而不是更好。
此外，常规超级播种比严格超级播种更有效——无论是在轻微抵抗水蛭攻击还是在对付敌对同伴方面。

需要有一种更全面的方式来处理敌对的同行。 不幸的是，禁止敌对客户端需要自动化/自动，但由于其逻辑中可能存在错误，因此可以通过一种方法来禁用它。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在 GitHub 上查看（https://github.com/qbittorrent/qBittorrent/issues/10258#issuecomment-486455764），或将线程静音（https://github.com/notifications/unsubscribe-auth /AAAQWM7YZNFLNGHCQWTNR7TPSDPOBANCNFSM4GUKOVLQ）。

同样，在下载公共 torrent 时手动禁止 -XL012 很费力，因为如果不添加第三方跟踪器，它们会通过 dht pex 不断弹出（一些流行的跟踪器要么在中国被阻止，要么阻止中国 ips）。 如果不加检查，它们不仅看起来为 0% 并且占用您上传带宽的很大一部分，而且也不给予任何回报。 虽然对于非中国用户来说这不是问题，但据我所知，GFW 过滤入站流量比过滤出站流量还要多，所以迅雷无法有效地窃取。
（但据我所知，除非 libtorrent 实现，否则 qb 不会有这个功能。）

你是对的。 也许我应该将它发布到 libtorrent 的仓库？

发送自 Windows 10 版邮件应用

发件人：NAVrasZ
发送时间：2019年5月13日18:10
射：qbittorrent/qBittorrent
抄送：先生； 作者
主题：回复：[qbittorrent/qBittorrent] 有没有办法阻止特定客户端（Thunder）？ (#10258)

在这里也是一样，在下载公共 torrent 时手动禁止 -XL012 很费力。 它们不仅看起来是 0%，如果不加检查，它们通常会占用您上传带宽的很大一部分，给其他人留下很少的东西，并且没有任何回报。
（但据我所知，除非 libtorrent 实现，否则 qb 不会有这个功能。）
—
您收到此消息是因为您创作了该线程。
直接回复此邮件，在 GitHub 上查看，或将线程静音。

它已在https://github.com/arvidn/libtorrent/pull/3833 中引用，但他们对此的看法是修复被滥用的漏洞，而不是添加额外的禁止功能。

也许加入黑名单是阻止迅雷的快速方法？ 我只需要将XL0012到该黑名单中，qbt 就会自动阻止这些客户端。 破解水蛭很容易，但有时可能有点用。

你快照里两个迅雷客户端的进度都是0%，怎么上传给别人啊？开什么玩笑？
都9102年了，还有人在说迅雷不上传给其他客户端...

我用qbit已经四年了，
而且我从来没见过迅雷上传（迅雷/XL002）。
即使我给他上传1GB，他仍然显示0%的进度，
只有速度版本 (7.xxx) 会以 50kb 或更低的速度上传。
迅雷用户太多，需要抗血功能。
只想用正式版。

libtorrent 1.2.1中已经实现了“choke dishonest peer in anti-leech seeding algorithm”，目前有qbittorrent 4.2.0RC和libtorrent 1.2.2发布，有迅雷问题的可以测试一下吗你报告是否有任何上传仍在发生？？

libtorrent 1.2.1中已经实现了“choke dishonest peer in anti-leech seeding algorithm”，目前有qbittorrent 4.2.0RC和libtorrent 1.2.2发布，有迅雷问题的可以测试一下吗你报告是否有任何上传仍在发生？？

https://imgur.com/qYKQqfr
还在上传

@cannotbeblank你在使用反水蛭算法吗？？

@cannotbeblank你在使用反水蛭算法吗？？

需要使用这个功能吗？ 我以为它默认被阻止了。
我现在正在使用算法。
但还是
https://imgur.com/ME9peky

Anti-leech 不仅无效，而且与名称所暗示的相反——正如我之前在此线程中所解释的那样。

qBitTorrent 的超级播种方法（但不是严格的超级播种或初始播种）更有效——但前提是每个 torrent 的上传插槽少于该 torrent 上的同行。

libtorrent 1.2.1中已经实现了“choke dishonest peer in anti-leech seeding algorithm”，目前有qbittorrent 4.2.0RC和libtorrent 1.2.2发布，有迅雷问题的可以测试一下吗你报告是否有任何上传仍在发生？？

该解决方案似乎不起作用。

反水蛭算法。 Windows 10.qBittorren 4.2.0RC

目前我已经向客户端上传了或多或少的 800KiB。

编辑 - 跟进

客户端刚刚下载了 1 MiB，但仍标记为 0.0% 的进度。 在群中，其他已下载 64 KiB 的客户端在进度列中标记为 0.1%。

编辑/2

重启后群里暂时没有迅雷的踪迹

编辑/3

迅雷 0012 和 0.0.1.8 仍然存在，仍在下载，仍在标记 0 % 进度

使用 Linux 和 4.3.0alpha1 版本，它们仍然连接并且只连接 leech。 有一个奇怪的人实际上展示了超过 0% 的完成度。

似乎 PR arvidn/libtorrent#3833 没有帮助。

qbittorrent 版本：4.2.0

上传窒息算法已设置为“反水蛭”。 （其他两种算法也无济于事。）

如您所见，它收到了超过 120MB（目前在被禁止之前为 180MB），这意味着 30 个块和整个 torrent 的 1.5%。

此外，在屏幕截图中，您可以看到 UA 为7.10.34.360 。 是老版的迅雷，老实说。

如果种子完全充斥着传入连接，其中许多/大多数是水蛭或更糟的敌对者，请尝试暂时禁用传入连接（通过删除端口转发/添加防火墙规则）、DHT 和 PEX。
...并将每个 torrent 的最大连接数减少到等于或低于当前连接的 peers+seed 数。 （这应该与禁用传入连接具有相同的效果，但可能会占用更多带宽。）

根据维基百科，Thunder 不支持 uTP ......或者如果支持，甚至比 qBitTorrent/libTorrent 更糟糕！ 所以禁用 TCP 种子+对等连接应该完全阻止它。
即使不允许传入的 TCP 连接（例如，仅在您的路由器上进行端口转发 UDP）也应该很少看到它们——因为中国的防火墙阻止了大多数中国以外的尝试连接到中国的 Thunder 客户端。

如果种子完全充斥着传入连接，其中许多/大多数是水蛭或更糟的敌对者，请尝试暂时禁用传入连接（通过删除端口转发/添加防火墙规则）、DHT 和 PEX。
...并将每个 torrent 的最大连接数减少到等于或低于当前连接的 peers+seed 数。 （这应该与禁用传入连接具有相同的效果，但可能会占用更多带宽。）

根据维基百科，Thunder 不支持 uTP ......或者如果支持，甚至比 qBitTorrent/libTorrent 更糟糕！ 所以禁用 TCP 种子+对等连接应该完全阻止它。
即使不允许传入的 TCP 连接（例如，仅在您的路由器上进行端口转发 UDP）也应该很少看到它们——因为中国的防火墙阻止了大多数中国以外的尝试连接到中国的 Thunder 客户端。

哈哈
你有没有看到之前评论的图片......？
迅雷早就支持uTP了，，，，，，

好点……是的，我错过了。 但是它可以用 uTP 做 STUN 吗？
...如果没有，请不要转发 UDP，它可能无法连接传入。

借助 web api 和 ipfilter.dat（如获取种子数据和设置应用程序首选项），那些特定的对等客户端（如 XL0012、迅雷、客户端：7.2.）仍然很容易被过滤掉，尽管它是一个未构建的- 在功能。

顺便说一句，考虑到那些没有静态 ip 的客户端，可能需要实现基于时间的轮换过滤 ip 机制。

我假设每个人都考虑过这个事实，如果你试图禁止特定的客户端，那些编码该客户端的人可能只是制作或启用某些东西来欺骗他们的客户端 ID 给另一个不真实的，所以这真的不是一个好一定要“修复”吗？ 或者希望我错了，我不做太多编码。

我不想这么说，但也许您优先考虑来自某些国家/地区的连接，例如使用下拉菜单，然后您可以根据传输速度确定传输速率？ 但这可能已经超出了 qBitorrent 的问题？ 我相信我也不是第一个想到这个的人，抱歉。

With the help of web api and ipfilter.dat (like Get torrent peers data and Set application preferences), those specific peer clients (like XL0012, Xunlei, client: 7.2.) are still easy to be filtered out, though it's a not built-in feature.

BTW, considering about those clients without static ips, a time-based rotate mechanism of filtering ip may be needed to implement.
老哥能弄个懒人版的脚本吗？
只需要ban xl0012就行了，那个第三方的qtorrent把所有迅雷都ban了

我不想这么说，但也许您优先考虑来自某些国家/地区的连接，例如使用下拉菜单，然后您可以根据传输速度确定传输速率？ 但这可能已经超出了 qBitorrent 的问题？

qBitTorrent（或者更确切地说是 qBT 使用的 libtorrent）具有本地对等处理，它可以为它确定为“本地”的 ip 提供更高的优先级或无限的速度。 这种行为可能会扩展到具有低 ping 时间和/或跟踪路由跳数的中距离对等点……而远距离对等点将获得较低的优先级。
这种行为可能需要默认为 OFF，因为不是每个人都需要它，并且默认为 on 可能对没有很多 Thunder 同行的 torrent 群有害。

作为临时解决方法，Linux 用户可以配置他们的防火墙来过滤来自这些恶意客户端的数据包。

例如：
iptables -I INPUT -p tcp -m string --string XL0012 --algo bm -j DROP
iptables -I INPUT -p udp -m string --string XL0012 --algo bm -j DROP

在大多数情况下，这会起作用，但有时我仍然可以看到一些 XL0012 客户端已连接。 我不确定他们是否在进行某种混淆处理。

在#issuecomment-462029063 中，有人说：

你快照里两个迅雷客户端的进度都是0%，怎么上传给别人啊？开什么玩笑？
都9102年了，还有人在说迅雷不上传给其他客户端...

翻译：

现在是2019年了，还有人说迅雷（迅雷）不会上传到其他客户端

都 0202 年了

然而，现在甚至是 2020 年，这就是我所看到的：

（永远的 0% 同行）

是的，迅雷已经发布了不是那么邪恶的新版本，但是仍然有一些人在使用旧版本的邪恶客户端。 所以反水蛭和封禁客户端功能还是很有必要的。

更新：添加英文翻译

换成bitcomet就行了，对付迅雷不上传的客户端非常有效。这作者看样子也不会花时间去解决国内种源特有的迅雷问题

@Phuker @foxdodo请只

我也在看这个问题。 带有字符串“-XL0012”的客户端正在窃取而不推进他们的进度。 也许它超出了范围，但有一个功能来阻止这些客户端会很好。

你快照中两个迅雷客户端的分步是 0%，他们怎么能上传到别人呢？ [9102]，...

我已经使用 qbit 四年了，
我从来没有见过雷声上传 （迅雷 / XL002） 。
即使我上传 1GB 给他， 他仍然显示 0% 的进展
， 只有速度版本 （7.x. x. x） 将上传的速度 50kb 或更少。
雷霆用户太多，我们需要防血功能。
只想用官方版。

it seems true, I am concerned about that, while using the pt to download torrent, the pt website band the qbittorrent enhanced version which is works in prohibiting thunder(XL0012), but using the offical version won't be like that.