QBittorrent

为什么要多开 一台服务器上只跑一个 qBittorrent，种子攒多了问题就来了：WebUI 越来越卡，单个进程到瓶颈后所有种子一起受影响，一个实例出问题还会全军覆没。把种子拆到多个独立实例里，每个实例有自己的进程、配置、下载目录和端口，负载和风险都分开，管理起来也更清楚。 手动多开本身不难，无非是复制 systemd 服务、给每个实例建独立 profile、再逐个改端口。但每换一台机器就要把这套流程重搓一遍，容易漏步骤、撞端口，所以我把它做成了脚本：more-qb。 more-qb 是什么 more-qb 是一个针对 [email protected] 的 qBittorrent 多实例脚本。它基于上游 RinehartZ/seedbox-tools 的 more_qb.sh 适配而来：保留上游的主体逻辑，只修改了原服务文件路径、服务名称和相关提示，适配我自己的服务命名。 适用环境 先说清楚，它不是通用的服务自动识别器，环境要对得上： 模板服务 /etc/systemd/system/[email protected] 已存在 模板中设置了 User=shoo，原实例是 [email protected] 原配置在 /home/shoo/.config/qBittorrent/qBittorrent.conf 一行命令 在目标 Linux 服务器上以 root 执行，无需登录 GitHub： wget -O more_qb.sh https://raw.githubusercontent.com/ihanr/more-qb/main/more_qb.sh && bash more_qb.sh -n 2 -w 9091 -b 23334 三个参数： -n：新增实例的个数。示例里是 2，就是新增 qb2、qb3 -w：起始 WebUI 端口。示例从 9091 开始，依次是 9091、9092 -b：起始 BT 端口。示例从 23334 开始，依次是 23334、23335；SSL 端口自动按 BT 端口 +1000 算，即 24334、24335 不传参数时脚本的默认值是 -n 3 -w 8081 -b 23334，建议还是显式传参，自己心里有数。 ...

一台服务器可以运行多个 qBittorrent-nox，用于按任务用途分别管理种子。关键是让每个实例拥有自己的配置、运行用户、管理端口和下载目录。 本文以 Debian 12 为示例，手动部署两个全新实例，不依赖第三方一键脚本。命令按系统软件源安装的 qBittorrent-nox 设计；不同发行版、软件版本与既有部署可能需要调整。这是一份依据官方文档整理的部署教程，没有使用某台生产服务器的实测结果。 如果已经有符合特定服务结构的主实例，也可以参考本站的 more-qb 脚本介绍。那篇文章使用同一用户和独立 profile；本文使用不同 Linux 用户，适合从头部署，两套方案不要混着执行。 1. 先规划实例 本文使用以下参数，端口均为示例： 项目 实例一 实例二 Linux 用户 qbt1 qbt2 用户家目录 /var/lib/qbt1 /var/lib/qbt2 WebUI 端口 8082 8083 BT 监听端口 23334 23335 下载目录 /mnt/qbt1 /mnt/qbt2 systemd 服务 [email protected] [email protected] WebUI 端口用于浏览器管理，BT 端口用于与其他客户端传输数据。 改了 WebUI 端口，不代表 BT 端口也变了。 多实例仍共享服务器的 CPU、内存、磁盘和网络带宽。它方便拆分任务，但不会凭空增加磁盘性能，也不保证上传更快。 2. 检查环境并安装 以下服务器命令以 root 执行；普通用户可先使用 sudo -i。不要把服务器命令粘贴进博客编辑器。 先查看环境： cat /etc/os-release findmnt -T /mnt df -hT /mnt getent passwd qbt1 qbt2 ss -lntup | grep -E ':(8082|8083|23334|23335)([[:space:]]|$)' getent 和端口筛选没有输出，分别表示未找到这两个用户、未找到这些端口的监听记录；这两项查询可能返回非零退出码，并不代表系统异常。若已经存在同名用户、实例目录、服务文件，或示例端口已占用，先换一套名称与端口，不要覆盖旧配置。 ...