qBittorrent Ban Vampire for Docker - 禁止迅雷吸血

qBittorrent Ban Vampire for Docker - 禁止迅雷吸血

此工具已由 PeerBanHelper 替代 https://github.com/Ghost-chu/PeerBanHelper

此工具已由 PeerBanHelper 替代
https://github.com/Ghost-chu/PeerBanHelper
已在 DSM 7.1.1 Docker 套件配合 imnks 的 qBittorrent 套件源的 qBittorrent 测试过,理论兼容 qb v4.x.x

今天午觉一觉睡醒,例行打开QB发现迅雷喜闻乐见的又来吸血了。

虚假上报下载进度的迅雷

由于自己最近一直在玩 PT 下载,因此 PT 站都或多或少的对 BT 客户端有一定的限制,例如 QBEE 是不被允许使用的。

如果你没有不使用QBEE的需求,在继续阅读这篇文章之前,也许你可以先考虑一下:

效果预览

下载和使用

下载

本文以 Synology DSM 的 Docker 套件举例。

首先转到映像页面,点击“新增”,选择从URL添加。可以填写下面的信息拉取镜像:

HUB页面:https://hub.docker.com/r/ghostchu/qb-ban-vampire-docker
存储库URL:docker.io/ghostchu/qb-ban-vampire-docker
填写Hub页面地址

完成后点击新增,等待镜像拉取完毕。

创建容器

转到容器页面,点击“新增”来创建一个新的Docker容器,并选择我们刚刚下载的镜像。

选择 Docker 镜像

配置容器网络

在网络页选择 ”使用与 Docker Host 相同的网络“,点击下一步。

网络页选择”使用与Docker Host相同的网络“

配置环境变量

在常规页面勾选自动重新启动,然后点击 “高级设置”, 进行环境变量的配置。

勾选自动重新启动,并点击高级设置按钮。

然后对环境变量进行配置,具体每个配置代表的意思参见下方表格。

配置环境变量
API_PREFIX: WebUI 地址,末尾不需要加(/)
API_USERNAME: WebUI 用户名
API_PASSWORD:WebUI 密码
BASICAUTH_ENABLED: qBitTorrent 是否处于基本HTTP认证保护层的后面,默认 false,如果不知道这是什么,请不要改动
BASICAUTH_USERNAME: 基本HTTP认证用户名 如果 BASICAUTH_ENABLED 为 false,该项不会被使用
BASICAUTH_PASSWORD: 基本HTTP认证密码 如果 BASICAUTH_ENABLED 为 false,该项不会被使用
INTERNAL_SECONDS: 监测间隔时间,单位为秒,默认为 5,频率过高可能会增加 qBitTorrent 的负载
DEFAULT_BAN_SECONDS: 默认情况下,IP地址被拉黑的时长,单位为秒,默认 3600 秒(1小时)
BAN_XUNLEI: 对迅雷客户端进行屏蔽(推荐,迅雷只下载且从不上传),默认为 true
BAN_PLAYER: 对 BT 播放器进行屏蔽,部分播放器可能只下载不上传,默认为 true
BAN_OTHER: 对 Cacaoweb, FlashGet, Net Transport, QQ下载, TuoTu, Baidu 也进行屏蔽,默认为 false
BAN_WITHOUT_RATIO_CHECK: 在 BAN 掉指定 IP 之前,是否对其分享率进行检查,默认为 true;为 true 的状态下,如果 BT 客户端上传了超过 1000000 的数据且客户端回报下载进度为 0% 才进行屏蔽;为 false 的状态下则直接屏蔽

测试效果

最后跳过存储空间设置,一路下一步完成容器的创建并且启动容器。

随后,你可以前往容器的 “终端机” 页面检查程序运行日志。

如需测试,可以通过 QB 下载一个 Win11 镜像进行测试,这个镜像下面吸血的还挺多的:

magnet:?xt=urn:btih:e3784ee17e8be49a97cf0bfc51b1626e62148f51&dn=zh-cn_windows_11_consumer_editions_version_22h2_updated_sep_2022_x64_dvd_23d39103.iso&xl=5579771904

尾言

在例如迅雷等一众下载大厂的广告之下,大部分普通人都只知道 “迅雷” 的百度网盘的 “离线下载” 可以下载 BT 种子和 Magnet 磁链。

百度网盘还好,下载次数有限,不会对 BT 网络产生太大影响。

然而迅雷并不是。

BT 之所以能够达到 “下载的人越多,下载的速度越快” 是因为每个客户端从其他人那里取来文件的一部分之后,都会将其分享传输给其他人。

下载的人越多,文件各个部分在整个网络中传播的也就更快更有效率,从而大大减轻文件源的传输压力,提高传输速度。

你可以理解为,这是一个天然的 CDN。每个人既是客户端,也是服务器,互相之间传输。

然而迅雷只下载不上传直接导致了其不会向除了任何其他 BT 客户端传送任何数据,导致网络中的其他节点要负责传输更多的数据并拉低整个网络的传输能力。

举个例子:

如果每个人都有 1.00 的分享率,5名下载者。

理想情况下,1号上传者在上传完一遍整个文件之后,1号上传者就可以不继续上传了。

其他5名下载者互相交换文件的各个部分,最后每个人都能拼出来一个完整的文件。

大家都节约了时间,1号上传者除了节约了时间,还节约了网络流量。

然而,如果 5 名下载者中间出现了 3 个迅雷用户。

1号上传者要上传多得多的流量,才能使得其他每个下载者都拿到完整的文件,因为其中 3 个迅雷用户拿到文件后不会分享给任何人。也因此,这个网络上的所有人的下载效率也都大大降低了。

害人不浅。

如果有条件的话,试试看那些正经的 BT 下载器吧:

Github

版权信息

本项目是 https://gist.github.com/Sg4Dylan/cb2c1d0ddb4559c2c46511de31ca3251 的 Docker 封装,并同时修复了当 WebAPI 超时会导致进程退出的问题。

Comment