qBittorrent 在我的 NAS 里只负责合法公开资料和自有文件任务，先把工作区分清，再谈速度和自动化。

\n
我不把 qBittorrent 当成什么都往里丢的杂物篮。它在家里的定位很窄：Linux ISO、开源项目镜像、公开授权数据集，以及我自己有权保存和分发的工作文件。定位窄一点，反而好维护。目录怎么分、权限给谁、Web UI 能从哪里进、速度限制怎么设，都会围绕这个边界来做。

先把工作区分成三层

我会在宿主机上先建好 incomplete、complete、archive 三层目录，再映射进容器。incomplete 只放还没完成的任务，方便一眼看出哪些文件不能拿去归档；complete 是任务完成后的暂存区，还需要校验体积、文件名和来源说明；archive 才是确认后的长期目录。这样做的好处是排障时不会混：任务还在跑，就看 incomplete；任务完成但找不到，就看 complete；长期保留空间上涨，就看 archive。

我不喜欢让应用自己临时创建一堆深层目录。NAS 上的共享目录经常还会被备份任务、文件管理器或其他容器访问，目录名越稳定，越不容易在半年后看不懂。当一份 Linux ISO 或开源镜像被放进 archive，我希望它已经脱离下载器的工作状态，可以按普通资料来备份和清理。

权限比页面状态更重要

qBittorrent 页面显示“完成”不代表文件已经落在正确位置。容器内的 /downloads 最终对应宿主机哪个目录，要用 docker inspect 看 Mounts，而不是凭页面路径猜。PUID、PGID、目录属主和组权限要对得上，尤其是 NAS 共享目录启用了 ACL 时，ls -ldn 看到的数字身份比图形界面更可靠。

我会在上线前做一个小任务测试：先写入 incomplete，再移动到 complete，最后手工复制到 archive。三步都能成功，才说明容器用户和宿主机目录之间没有明显权限问题。如果只测 Web UI 能打开，很容易漏掉“页面正常但文件无法移动”的情况。

Web UI 只能走受控入口

qBittorrent 的 Web UI 是管理入口，不是普通展示页面。我不会把它直接暴露在外部网络上，也不会保留默认密码。更稳妥的方式是只允许局域网或统一受控入口访问，并把管理密码放进密码库。恢复配置、重建容器、切换镜像之后，第一件事就是重新确认账号、会话和访问范围。

日志也要留够。失败登录、异常任务、保存路径错误，都可能只在日志里有完整线索。家庭服务器不是企业安全系统，但至少要能回答三个问题：谁在什么时间访问过管理页，任务为什么失败，文件最终写到了哪里。

限速是为了保护整台机器

下载器最容易让人误判，因为它一旦跑满，看起来只是网络忙，实际可能把 NAS 的磁盘写入、校验、缩略图生成和数据库响应一起拖慢。我会设置全局速度上限，再按时间段设置更保守的计划限速。白天家里有人用云文件、照片同步或远程桌面时，qBittorrent 不应该抢满带宽和磁盘。

限速还包括连接数。连接数太高时，低配 NAS 的 CPU 和内存压力会先上来，随后日志变慢、Web UI 卡住，最后才表现成任务速度下降。我宁愿让公开镜像任务多跑一会儿，也不希望它影响同机的数据库、相册和备份。

磁盘占用要按目录看

磁盘报警时，我不会只看 qBittorrent 页面里的任务大小。未完成文件、预分配空间、重复任务、旧的临时文件都会占空间。最直接的检查是按目录统计：

docker compose config
docker inspect qbittorrent --format '{{json .Mounts}}'
du -sh /srv/public-files/*
find /srv/public-files -maxdepth 2 -type d -exec ls -ldn {} \;
docker compose logs --tail=120 qbittorrent

如果 incomplete 很大，先判断是任务还在跑，还是失败后没有清理；如果 complete 很大，说明校验和归档动作没有及时跟上；如果 archive 过快增长，就要重新看保留周期。这个工作区不追求自动化越多越好，先让每个目录的含义稳定，后面的清理规则才有意义。

我的最终原则很简单：qBittorrent 负责把合法公开资料和自有文件放进可检查的工作区，不负责替我决定长期保存策略。目录清楚、权限清楚、入口收紧、速度可控，才是它在家庭服务器里长期安静运行的前提。