警告： AutoBangumi v3.2.2–v3.2.6 连接池 Bug 在 Clash/Mihomo Party 代理环境下可能导致异常磁盘写入
我想提醒一下使用开源项目 EstrellaXD/Auto_Bangumi 的用户，尤其是运行环境中使用 Clash Party / Mihomo Party 作为代理的用户： AutoBangumi v3.2.2–v3.2.6 期间存在一个连接池相关 Bug ，在特定网络架构下可能触发代理程序持续刷 Warning 日志，从而造成非常高的磁盘写入量。
该问题已在 7 月 2 日 的 v3.2.8 被修复并交付，开发者也确认这是 AutoBangumi 的连接池 Bug 。 如果你曾经在 v3.2.2–v3.2.6 期间运行过 AutoBangumi ，并且代理链路经过 Clash Party / Mihomo Party ，建议尽快检查系统磁盘写入量和 SSD SMART 寿命信息。
我的环境
我的 AutoBangumi 是通过 Watchtower 自动升级的。 在 2 月 9 日，AutoBangumi 被自动升级到 v3.2.2 后，我开始观察到 Mac 上的 Mihomo Party 日志刷新非常快。
当时我定位后发现问题来自 AutoBangumi ，并在 GitHub 提交了 issue：
https://github.com/EstrellaXD/Auto_Bangumi/issues/984
我的部署架构大致如下：
- AutoBangumi：运行在 OrbStack 的 host network 下
- 代理：连接宿主机
127.0.0.1 - qBittorrent：局域网内另一台设备，
192.168.1.x:7600 - Docker 镜像：
ghcr.io/estrellaxd/auto_bangumi:latest
version: "3.8"
services:
AutoBangumi:
image: "ghcr.io/estrellaxd/auto_bangumi:latest"
container_name: AutoBangumi
volumes:
- /Users/???/Appdata/AutoBangumi/config:/app/config
- /Users/???/Appdata/AutoBangumi/data:/app/data
network_mode: host
restart: unless-stopped
dns:
- 117.50.10.10
- 0.250.250.200
environment:
- TZ=Asia/Shanghai
- PGID=20
- PUID=501
- UMASK=022
当时观察到的现象
AutoBangumi 启动后，每隔约 10 秒会集中刷出大量类似错误：
[2026-02-09 10:33:24] WARNING: Server disconnected without sending a response.
[2026-02-09 10:33:24] WARNING: Cannot connect to qBittorrent. Wait 5 min and retry...
[2026-02-09 10:33:24] WARNING: Server disconnected without sending a response.
[2026-02-09 10:33:24] WARNING: Cannot connect to qBittorrent. Wait 5 min and retry...
[2026-02-09 10:33:24] WARNING: Server disconnected without sending a response.
[2026-02-09 10:33:24] WARNING: Cannot connect to qBittorrent. Wait 5 min and retry...
从 AutoBangumi 的功能表现来看，程序并不是完全不可用，qBittorrent 也可以正常连接和下载。 但该问题会导致 renamer 经常不能及时工作，已下载剧集可能延迟 1–2 小时，甚至更久才会被正常重命名。
从代理日志看，AutoBangumi 会在短时间内集中创建大量连接，其中一部分连接最终超时或断开。 旧版本 v3.1.18 没有观察到这个问题。
更严重的问题：代理日志导致异常磁盘写入
在 Bug 修复前，我并没有第一时间意识到它还会带来磁盘写入问题。 直到最近我给 Mac 外挂了一个 1TB 硬盘，偶然在 macOS 活动监视器里看到：系统盘在开机约 2 天内写入了 22TB 数据，而且写入来源全部是 Mihomo Party 。
进一步排查后，我认为这和 AutoBangumi v3.2.2–v3.2.6 期间的连接池 Bug 有关： AutoBangumi 持续触发大量异常连接，Clash Party / Mihomo Party 持续记录 Warning 级别连接日志，最终造成极高的日志写入量。
在我的机器上，活动监视器显示 Mihomo Party 每天约产生 12TB 左右写入。
我的 SSD SMART 结果
我的 Mac 是 256GB 标准版。发现异常后，我使用 smartmontools 查询内置 SSD 的 SMART 信息，结果显示这半年内累计写入已经达到 389TB：
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 39 Celsius
Available Spare: 100%
Available Spare Threshold: 99%
Percentage Used: 24%
Data Units Read: 28,221,664 [14.4 TB]
Data Units Written: 760,713,590 [389 TB]
Host Read Commands: 542,135,493
Host Write Commands: 1,001,723,211
Controller Busy Time: 0
Power Cycles: 166
Power On Hours: 744
Unsafe Shutdowns: 13
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
对于 256GB SSD 来说，389TB 写入约等于 1500+ 次全盘写入。
如果按我观察到的异常写入速度估算，峰值期间约为 49 DWPD。目前主控报告的 Percentage Used 已经达到 24%。
虽然 SMART 仍然显示健康状态通过，且没有介质错误，但这个写入量显然已经远超正常桌面使用强度。
建议受影响用户立刻检查
如果你符合以下条件，建议尽快检查：
使用过 AutoBangumi v3.2.2–v3.2.6 ；
AutoBangumi 通过代理连接外部网络；
代理程序是 Clash Party 、Mihomo Party ，或其他会持久化连接日志的 Mihomo/Clash 图形客户端；
曾经看到过大量类似日志：
Server disconnected without sending a responseCannot connect to qBittorrent. Wait 5 min and retry- 代理端大量
warning/timeout/disconnect连接日志；
使用的是 Mac ，尤其是 256GB / 512GB 内置 SSD 机型。
建议
尽快升级 AutoBangumi 到已修复版本。 不建议继续停留在 v3.2.2–v3.2.6 。
检查代理程序日志写入量。 即使 AutoBangumi 功能看起来正常，代理端也可能已经在持续写入大量 Warning 日志。
检查 SSD SMART 。 尤其是 Mac mini 、MacBook Air 、MacBook Pro 等内置 SSD 不方便更换的设备。