AniBT-Speed：构建自己的 BT 做种加速管理平台
问题背景
最近在弄BT做种，本来想偷懒的，但是发现由于BT的RSS数量过多且如果发布旧种无人做种的情况下会一直占着队列导致新的反而无法下载（设置了最大例如8个同时下载）。
项目定位
AniBT-Speed 参考了 PBH-BTN/SwarmAccelerator 的设计理念，但从实现层面完全重写，目标是提供一个：
- 前端可配置的管理面板，所有策略参数通过 Web UI 调整，无需编辑配置文件
- 多实例架构，支持同时管理多个 qBittorrent 实例并做负载均衡
- 一键部署，Docker Compose 启动即用
核心功能
智能空间管理
做种最头疼的问题之一就是磁盘空间。AniBT-Speed 实现了基于时间和分享率的智能删除策略：
空间告警阈值: 85%（触发清理）保护时间窗口: 8 小时（新种子强制保留）分界时间: 12 小时
删除优先级: - 添加不满 8h → 强制保护，不删除 - 8h ~ 12h → 优先删除高分享率的（已经做够了） - 超过 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 采用负载均衡算法自动选择：
score = active_torrents * 1.0 + upload_speed_mbps * 0.3 + paused_torrents * 0.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 文件
services: backend: image: ghcr.io/yuri-nagasaki/anibt-speed-backend:latest container_name: anibt-speed-backend environment: - SECRET_KEY=${SECRET_KEY:-change-me} - ADMIN_PASSWORD=${ADMIN_PASSWORD:-admin} - TZ=Asia/Shanghai volumes: - ./backend/data:/app/data networks: - anibt restart: unless-stopped
frontend: image: ghcr.io/yuri-nagasaki/anibt-speed-frontend:latest container_name: anibt-speed-frontend ports: - "127.0.0.1:6868:6868" depends_on: - backend networks: - anibt restart: unless-stopped
peerbanhelper: image: ghostchu/peerbanhelper:latest container_name: anibt-speed-pbh environment: - TZ=Asia/Shanghai ports: - "127.0.0.1:9898:9898" volumes: - ./peerbanhelper/data:/app/data networks: - anibt restart: unless-stopped
networks: anibt: driver: bridge部署教程
环境要求
- Docker + Docker Compose
- Git
- 一个或多个已运行的 qBittorrent 实例
一键部署
# 克隆仓库git clone https://github.com/Yuri-NagaSaki/AniBT-Speed.gitcd AniBT-Speed
# 一键部署（从 GHCR 拉取预构建镜像）chmod +x deploy.sh./deploy.sh部署脚本会自动：
- 检查 Docker 等依赖
- 生成
.env文件（含随机 SECRET_KEY） - 拉取镜像并启动服务
- 验证所有服务运行状态
初始配置
部署完成后：
- 打开
http://你的服务器IP:6868，使用.env中的密码登录 - 进入「实例管理」，添加你的 qBittorrent 实例
- 进入「RSS 管理」，添加 RSS 订阅源
- （可选）配置 Telegram 通知
- （可选）访问
http://127.0.0.1:9898配置 PeerBanHelper
健康检查
项目自带 26 项健康检查脚本：
chmod +x test.sh./test.sh检查项覆盖容器状态、网络隔离、API 端点、端口暴露、内部连通性、时区配置和数据持久化。
总结
AniBT-Speed 的目标是让做种管理从手动操作变为自动化策略驱动。所有参数都通过 Web UI 配置，策略调整无需重启服务，适合需要管理大量种子的 PT/BT 用户。
如果你也在用 qBittorrent 做种并且对自动化管理有需求，欢迎试用和反馈。
分享文章
生成精美分享图或复制链接，与更多人分享本文。
继续阅读
换条路线
从其他文章中稳定抽取
最后更新于 ，距今已过 172 天
部分内容可能已过时
评论