问题背景#

最近在弄BT做种，本来想偷懒的，但是发现由于BT的RSS数量过多且如果发布旧种无人做种的情况下会一直占着队列导致新的反而无法下载（设置了最大例如8个同时下载）。

项目定位#

AniBT-Speed 参考了 PBH-BTN/SwarmAccelerator 的设计理念，但从实现层面完全重写，目标是提供一个：

前端可配置的管理面板，所有策略参数通过 Web UI 调整，无需编辑配置文件
多实例架构，支持同时管理多个 qBittorrent 实例并做负载均衡
一键部署，Docker Compose 启动即用

核心功能#

智能空间管理#

做种最头疼的问题之一就是磁盘空间。AniBT-Speed 实现了基于时间和分享率的智能删除策略：

1
空间告警阈值: 85%（触发清理）
2
保护时间窗口: 8 小时（新种子强制保留）
3
分界时间: 12 小时
4

5
删除优先级:
6
  - 添加不满 8h → 强制保护，不删除
7
  - 8h ~ 12h   → 优先删除高分享率的（已经做够了）
8
  - 超过 12h   → 优先删除低分享率的（帮助初种）

这个策略的核心逻辑是：新种子需要保护，中期种子如果分享率已经很高说明贡献足够了，老种子如果分享率还很低说明没人要可以清理。

flowchart TD A[定时检查每5分钟] --> B{磁盘使用率 > 85%?} B -- 否 --> Z[无操作] B -- 是 --> C[获取所有种子列表] C --> D{添加时间 < 8h?} D -- 是 --> E[强制保护不删除] D -- 否 --> F{添加时间 < 12h?} F -- 是 --> G[按分享率降序排列优先删除高分享率] F -- 否 --> H[按分享率升序排列优先删除低分享率] G --> I[删除种子+数据] H --> I I --> J{空间恢复到阈值以下?} J -- 否 --> D J -- 是 --> Z

RSS 订阅与负载均衡#

当你有多个 qBittorrent 实例时，新种子应该下载到哪个实例？AniBT-Speed 采用负载均衡算法自动选择：

1
score = active_torrents * 1.0 + upload_speed_mbps * 0.3 + paused_torrents * 0.2
2
# 分数越低，负载越轻，优先分配新任务

RSS 订阅支持两种模式：

自动分配（instance_id = 0）：后端轮询 RSS，通过负载均衡选择最佳实例
指定实例（instance_id > 0）：使用 qBittorrent 原生 RSS 规则，直接绑定到特定实例

flowchart TD A[RSS 轮询每5分钟] --> B[获取 RSS Feed 列表] B --> C{遍历每个 Feed} C --> D{instance_id = 0?} D -- 是自动模式 --> E[后端解析 RSS XML] D -- 否指定实例 --> F[qBT 原生 RSS 规则处理] E --> G[过滤匹配关键字] G --> H{已处理过?} H -- 是 --> C H -- 否 --> I[查询所有实例负载] I --> J[计算负载评分选择最优实例] J --> K[添加种子到选中实例] K --> L[记录已处理 GUID] L --> C

智能队列管理#

当一个种子的所有 Tracker 和 DHT 网络上都没有下载者（leechers = 0）时，继续做种只是浪费资源。队列管理器会自动暂停这些种子，等到有新的下载者出现时再恢复。

速率限制#

为了不影响服务器上的其他服务，限速策略分为两档：

场景	上传限速	下载限速
仅做种	100 MB/s	不限制
有活动下载	80 MB/s	60 MB/s

还支持滑动窗口限速：设置每小时或每日的流量上限，超过后自动降速。

反吸血保护#

集成 PeerBanHelper，自动封禁使用吸血客户端的 Peer。支持 BTN 云端规则和迅雷限制策略。

Telegram 通知#

所有关键事件都可以推送到 Telegram：

新种子下载完成
种子被删除（附带原因）
空间告警
每日统计摘要（可自定义推送时间）

Docker 部署#

Yaml 文件#

1
services:
2
  backend:
3
    image: ghcr.io/yuri-nagasaki/anibt-speed-backend:latest
4
    container_name: anibt-speed-backend
5
    environment:
6
      - SECRET_KEY=${SECRET_KEY:-change-me}
7
      - ADMIN_PASSWORD=${ADMIN_PASSWORD:-admin}
8
      - TZ=Asia/Shanghai
9
    volumes:
10
      - ./backend/data:/app/data
11
    networks:
12
      - anibt
13
    restart: unless-stopped
14

15
  frontend:
16
    image: ghcr.io/yuri-nagasaki/anibt-speed-frontend:latest
17
    container_name: anibt-speed-frontend
18
    ports:
19
      - "127.0.0.1:6868:6868"
20
    depends_on:
21
      - backend
22
    networks:
23
      - anibt
24
    restart: unless-stopped
25

26
  peerbanhelper:
27
    image: ghostchu/peerbanhelper:latest
28
    container_name: anibt-speed-pbh
29
    environment:
30
      - TZ=Asia/Shanghai
31
    ports:
32
      - "127.0.0.1:9898:9898"
33
    volumes:
34
      - ./peerbanhelper/data:/app/data
35
    networks:
36
      - anibt
37
    restart: unless-stopped
38

39
networks:
40
  anibt:
41
    driver: bridge

部署教程#

环境要求#

Docker + Docker Compose
Git
一个或多个已运行的 qBittorrent 实例

一键部署#

1
# 克隆仓库
2
git clone https://github.com/Yuri-NagaSaki/AniBT-Speed.git
3
cd AniBT-Speed
4

5
# 一键部署（从 GHCR 拉取预构建镜像）
6
chmod +x deploy.sh
7
./deploy.sh

部署脚本会自动：

检查 Docker 等依赖
生成 .env 文件（含随机 SECRET_KEY）
拉取镜像并启动服务
验证所有服务运行状态

TIP
如果需要本地构建镜像，使用 BUILD_LOCAL=1 ./deploy.sh

初始配置#

部署完成后：

打开 http://你的服务器IP:6868，使用 .env 中的密码登录
进入「实例管理」，添加你的 qBittorrent 实例
进入「RSS 管理」，添加 RSS 订阅源
（可选）配置 Telegram 通知
（可选）访问 http://127.0.0.1:9898 配置 PeerBanHelper

默认密码为 admin，请在 .env 文件中修改 ADMIN_PASSWORD 后重启服务。

健康检查#

项目自带 26 项健康检查脚本：

1
chmod +x test.sh
2
./test.sh

检查项覆盖容器状态、网络隔离、API 端点、端口暴露、内部连通性、时区配置和数据持久化。

总结#

AniBT-Speed 的目标是让做种管理从手动操作变为自动化策略驱动。所有参数都通过 Web UI 配置，策略调整无需重启服务，适合需要管理大量种子的 PT/BT 用户。

如果你也在用 qBittorrent 做种并且对自动化管理有需求，欢迎试用和反馈。

AniBT-Speed：构建自己的 BT 做种加速管理平台

问题背景#

项目定位#

核心功能#

智能空间管理#

RSS 订阅与负载均衡#

智能队列管理#

速率限制#

反吸血保护#

Telegram 通知#

Docker 部署#

Yaml 文件#

部署教程#

环境要求#

一键部署#

初始配置#

健康检查#

总结#