警告： 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 仍然显示健康状态通过，且没有介质错误，但这个写入量显然已经远超正常桌面使用强度。

建议受影响用户立刻检查

如果你符合以下条件，建议尽快检查：

1. 
   

   使用过 AutoBangumi v3.2.2–v3.2.6 ；

   
   


2. 
   

   AutoBangumi 通过代理连接外部网络；

   
   


3. 
   

   代理程序是 Clash Party 、Mihomo Party ，或其他会持久化连接日志的 Mihomo/Clash 图形客户端；

   
   


4. 
   

   曾经看到过大量类似日志：

   
   
   
   
   • Server disconnected without sending a response
   
   
   • Cannot connect to qBittorrent. Wait 5 min and retry
   
   
   • 代理端大量 warning / timeout / disconnect 连接日志；
   
   
   
   


5. 
   

   使用的是 Mac ，尤其是 256GB / 512GB 内置 SSD 机型。

   
   

建议

1. 
   

   尽快升级 AutoBangumi 到已修复版本。
   不建议继续停留在 v3.2.2–v3.2.6 。

   
   


2. 
   

   检查代理程序日志写入量。
   即使 AutoBangumi 功能看起来正常，代理端也可能已经在持续写入大量 Warning 日志。

   
   


3. 
   

   检查 SSD SMART 。
   尤其是 Mac mini 、MacBook Air 、MacBook Pro 等内置 SSD 不方便更换的设备。