qBittorrent WebUI真正方便的不是下载：而是让长期任务和电脑彻底解耦

qBittorrent WebUI真正方便的不是下载：而是让长期任务和电脑彻底解耦

前言

BT下载真正让人觉得麻烦的地方，往往不是“不会下载”，而是任务只能绑在一台电脑上：大文件要跑几个小时，电脑关机就得停；人在外面想补一个磁力链接、看一下进度，还得等回家再操作。对于本来就7×24小时在线的NAS，这类长期下载任务其实更适合交给服务器来跑。

这次我在飞牛NAS上部署的是qBittorrent WebUI。先通过SSH确认Docker环境，再用Docker Compose启动lscr.io/linuxserver/qbittorrent:latest，把配置目录和下载目录分别挂载出来，并把WebUI放到8860端口。

页面跑通以后，我继续完成首次登录、修改默认密码、Tracker配置、界面语言调整，并实际通过URL和种子文件添加下载任务。也就是说，这篇验证的不只是“容器Up了”，而是WebUI确实能承担远程管理下载任务这件事。

最后再把8860提供给外部设备访问，从随机公网入口切换到二级子域名。整篇重点是把飞牛NAS → qBittorrent → WebUI → 下载任务 → 外部管理这条链跑通，同时把目录、替代WebUI路径和公网管理面的安全边界讲清楚。

这类方案真正适合NAS的地方，也不是“下载软件装在哪”，而是把长时间任务和自己的电脑解耦。电脑关机以后NAS继续跑，真正需要操作时再从浏览器进入管理页面，这才是WebUI比桌面客户端更有价值的地方。

1 qBittorrent和WebUI分别是什么

qBittorrent本体负责：

• BT协议；
• 磁力链接；
• torrent种子；
• 下载队列；
• 上传与做种；
• RSS等下载功能。

WebUI负责：

在浏览器里操作qBittorrent。

所以更准确的理解是：

qBittorrent是下载引擎，WebUI是它的网页控制台。

把它部署到NAS以后，真正的价值不是“换了一个下载软件”，而是：

下载任务可以长期跑在NAS上，管理入口则放进浏览器。

2 这套方案更适合什么场景

比较适合：

• NAS或家庭服务器长期在线；
• 经常下载Linux镜像、开源软件、公开发行资源等合法内容；
• 希望电脑关机以后下载任务继续；
• 想从手机或另一台电脑管理任务；
• 不想把下载进度绑在单台PC上。

使用BT/P2P时仍然需要遵守资源本身的版权和所在地区规则。

3 先在飞牛NAS开启SSH

进入设置开启SSH：

继续：

连接页面：

后面的Docker部署都从终端完成。

4 检查Docker环境

执行：

docker -v
systemctl status -v

页面：

这里真正需要确认的是：

后面的Docker Compose能够正常启动。

5 创建配置和下载目录

执行：

mkdir -p /docker/qbittorrent/config
mkdir -p /docker/qbittorrent/downloads
cd qbittorrent/

页面：

这里创建了：

• /docker/qbittorrent/config
• /docker/qbittorrent/downloads

分别用于：

• qBittorrent配置；
• 下载文件。

6 这里有一个目录切换细节要注意

前面创建的是：

/docker/qbittorrent/…

但命令最后写的是：

cd qbittorrent/

代码保持不改。

如果当前终端并不在/docker目录下，这条命令可能进不到刚刚创建的目录。

实际执行时应该确认：

当前工作目录和目标目录是否一致。

7 创建docker-compose.yml

执行：

vi docker-compose.yml

继续写入：

services:
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
environment:
– PUID=1000
– PGID=1000
– TZ=Asia/Shanghai
– WEBUI_PORT=8860
volumes:
– ./config:/config
– ./downloads:/downloads
ports:
– "8860:8860"
– "6881:6881"
– "6881:6881/udp"
restart: unless-stopped

页面：

这里几个关键参数是：

• 镜像：lscr.io/linuxserver/qbittorrent:latest
• 容器名：qbittorrent
• PUID：1000
• PGID：1000
• 时区：Asia/Shanghai
• WebUI端口：8860
• BT TCP/UDP端口：6881
• 配置目录：./config:/config
• 下载目录：./downloads:/downloads

8 PUID和PGID不能只照抄

本文使用：

PUID=1000

PGID=1000

它们决定容器以哪个用户和用户组身份访问宿主机目录。

如果下载目录出现：

• 无法写入；
• 权限不足；
• 文件属主异常；

就应该优先检查：

NAS实际用户UID/GID是否和1000一致。

9 启动qBittorrent

执行：

docker-compose up -d

页面：

然后检查容器状态：

docker ps

页面：

看到容器正常运行以后，再继续找首次登录信息。

10 从日志里查看初始密码

执行：

docker logs qbittorrent

页面：

LinuxServer版本的qBittorrent首次启动时，可以从日志里查看临时登录密码。

这一步不要跳过。

11 浏览器进入WebUI

本文配置的WebUI端口是：

8860

访问：

http://NAS_IP:8860

页面：

这里材料文字里写成了：

http://极空间IP:8860

但整篇部署环境是飞牛NAS。

所以更准确地理解为：

填写当前实际NAS的局域网IP。

不要被“极空间”这个名称残留影响。

12 使用日志里的密码登录

登录页面：

进入首页：

做到这里，可以确认：

飞牛NAS → Docker → qBittorrent → WebUI 8860

已经跑通。

13 登录以后第一件事：改密码

设置页面：

首次日志里拿到的密码只适合初始化。

尤其后面如果还要远程访问WebUI，更应该先：

修改管理员密码。

14 Tracker设置属于可选优化

进入BitTorrent设置：

本文展示了：

Automatically append trackers from URL to new downloads

也就是：

新任务自动从URL追加Tracker。

继续填入示例Tracker地址：

这里要注意：

• Tracker是否可用会变化；
• 第三方Tracker列表由外部维护；
• 并不是添加得越多下载就一定越快。

这类配置更适合作为：

连接发现的可选补充。

15 下载速度不只由Tracker决定

BT下载速度还会受：

• 种子健康度；
• Peer数量；
• 做种者上传速度；
• 本地网络；
• 端口可达性；
• 磁盘写入能力；
• ISP网络状况；

共同影响。

所以不能把“追加Tracker”写成：

一定能高速下载。

16 材料还展示了替代WebUI设置

页面：

这里勾选：

Use alternative WebUI

并指定：

/docker/qbittorrent/webui

但当前Compose只挂载：

• ./config:/config
• ./downloads:/downloads

并没有展示：

/docker/qbittorrent/webui

这个目录如何进入容器。

所以这里需要特别注意。

17 替代WebUI路径必须以容器内真实路径为准

qBittorrent设置里的路径，是：

容器内部能看到的路径。

如果宿主机存在：

/docker/qbittorrent/webui

但没有通过Volume挂载进容器，qBittorrent未必能直接访问。

因此如果启用替代WebUI后页面异常，优先检查：

• WebUI文件是否真的存在；
• 容器内是否能看到该目录；
• Compose是否需要增加对应Volume；
• 设置中的路径是否和容器内路径一致。

本文不把这一步写成已经完整验证成功的第三方WebUI方案。

18 界面语言也可以调整

进入Behavior页面：

材料把用户界面语言调整为：

简体中文。

这一步只影响管理界面显示，不影响BT任务本身。

第二部分：真正添加下载任务

19 通过URL添加任务

点击WebUI左上角的URL下载入口：

这里可以输入：

• 磁力链接；
• torrent直链；
• 哈希值。

材料里能看到Ubuntu镜像任务正在获取元数据。

这类公开Linux发行版镜像也是更适合作为BT测试的内容。

20 也可以导入torrent文件

页面：

继续：

选择种子文件以后即可创建下载任务。

21 WebUI的价值在这里才真正体现出来

任务加入以后：

继续查看：

这时候真正形成的是：

浏览器 → qBittorrent WebUI → NAS下载目录

电脑只是管理端。

实际下载任务运行在NAS上的qBittorrent容器里。

22 下载目录就是后续容量管理重点

Compose里挂载：

./downloads:/downloads

所以真正长期使用时要关心：

• 下载目录对应哪个NAS存储空间；
• 空间是否足够；
• 文件权限是否正常；
• 是否需要单独分类；
• 是否有定期清理策略。

BT任务本身正常，不代表NAS磁盘空间永远够用。

23 WebUI远程管理和BT传输端口要分开

本文涉及两类端口：

WebUI

8860

用途：

浏览器管理页面。

BT TCP/UDP

6881

用途：

BT连接。

后面的cpolar只映射：

8860

也就是：

远程管理WebUI。

并没有把6881通过同一条HTTP隧道处理。

第三部分：从外部设备管理下载任务

24 为什么需要远程WebUI

qBittorrent放到NAS以后，下载任务本身已经可以长期运行。

远程管理解决的是：

• 人在外面添加任务；
• 查看进度；
• 暂停或恢复；
• 调整下载任务；
• 检查状态。

这比远程控制整个NAS桌面更轻量。

25 安装cpolar

执行：

sudo curl https://get.cpolar.sh | sh

页面：

继续检查服务：

sudo systemctl status cpolar

页面：

确认服务正常以后，再进入Web管理页面。

26 打开cpolar Web UI

通过：

主机IP:9200

进入：

登录后创建qBittorrent对应的HTTP隧道。

27 给8860创建随机公网入口

本次参数：

• 隧道名称：qBittorrent
• 协议：HTTP
• 本地地址：8860
• 域名类型：随机域名
• 地区：China Top

页面：

这里映射的是：

qBittorrent WebUI。

28 查看公网地址

在线隧道列表：

从外部浏览器访问：

能够正常打开以后，可以确认：

外部浏览器 → 公网地址 → NAS:8860 → qBittorrent WebUI

已经跑通。

29 WebUI公网开放以后，安全要求会明显提高

WebUI不仅能“看下载进度”。

它还可以：

• 添加任务；
• 删除任务；
• 修改设置；
• 查看下载文件；
• 调整路径和队列。

所以长期远程管理时至少要注意：

• 修改默认密码；
• 使用强密码；
• 不公开公网地址；
• 不把管理链接发到群里；
• 定期检查登录和服务状态。

30 不要把管理WebUI和下载资源公开分享混在一起

cpolar这里解决的是：

自己远程管理qBittorrent。

它不等于：

• 对外提供文件下载站；
• 向陌生人开放BT管理权限；
• 公开共享NAS文件。

这三件事的权限边界完全不同。

31 随机地址先用来验证链路

随机域名适合：

• 临时访问；
• 测试公网链路；
• 偶尔远程管理。

如果只是确认人在外面能打开WebUI，到这里已经够用。

32 需要长期收藏再配置二级子域名

预留页面：

本次示例名称：

qBittorrent

页面：

实际名称以自己账号最终保留结果为准。

33 编辑qBittorrent隧道

回到隧道列表：

把域名类型改成：

二级子域名

填写保留成功的名称：

34 查看长期访问入口

在线隧道列表：

最后从外部浏览器访问：

能够正常进入WebUI以后，长期入口完成。

35 二级子域名解决的是入口稳定，不是永久有效

更准确地说：

在账号、隧道和NAS服务都正常的前提下，访问入口不再按随机方式变化。

它仍然依赖：

• NAS在线；
• qBittorrent容器运行；
• cpolar服务运行；
• 隧道配置正常；
• 账号状态正常。

所以不把它写成：

永久不会变化、永远不会失效。

36 这套方案真正适合什么人

比较适合：

• 已经有NAS或家庭服务器；
• 下载任务经常需要长时间运行；
• 想把下载和电脑开关机解耦；
• 希望手机、电脑都能管理任务；
• 能自己处理目录权限和磁盘空间；
• 只下载和分享自己有权使用的内容。

如果只是偶尔下载一个小文件，直接用桌面版qBittorrent可能反而更省事。

37 最后把完整技术链重新看一遍

运行环境：

飞牛NAS + Docker

镜像：

lscr.io/linuxserver/qbittorrent:latest

配置目录：

./config:/config

下载目录：

./downloads:/downloads

WebUI：

8860

BT连接：

6881 TCP/UDP

首次登录：

docker logs qbittorrent

本地使用：

改密码 → Tracker → 语言 → URL任务 → torrent文件

远程管理：

cpolar → WebUI 8860

长期入口：

二级子域名

实际完成：

• SSH；
• Docker检查；
• 配置目录；
• 下载目录；
• Docker Compose；
• 容器启动；
• docker ps；
• 日志查看初始密码；
• WebUI登录；
• 修改密码；
• Tracker设置；
• 替代WebUI入口；
• 中文界面；
• URL任务；
• torrent文件任务；
• cpolar安装；
• 8860公网访问；
• 二级子域名；
• 外部设备管理。

这样qBittorrent真正从一个桌面下载软件，变成了一个长期运行在NAS上、通过浏览器管理下载任务的服务。

总结

这次真正跑通的是一条完整的qBittorrent WebUI使用链：先在飞牛NAS上创建配置和下载目录，通过Docker Compose启动lscr.io/linuxserver/qbittorrent:latest，再从日志里拿到首次密码，进入8860管理页面并修改账号密码。

功能验证没有停在“WebUI能打开”。后面继续配置Tracker、界面语言，并实际通过URL和torrent文件加入下载任务，确认NAS上的qBittorrent确实能够承担长期下载和网页管理。这里也要区分WebUI的8860和BT连接使用的6881，它们用途不同。

这篇还有两个值得注意的配置细节：部署目录创建在/docker/qbittorrent，但后面写成cd qbittorrent/，执行时要确认当前所在目录；另外替代WebUI指定/docker/qbittorrent/webui，但Compose没有展示对应Volume挂载，如果启用后异常，应先检查容器内是否真正存在这个路径。

远程部分最后开放的是qBittorrent管理页面，不是公开文件站。人在外面可以继续添加、暂停和查看任务，但WebUI本身拥有较高操作权限，因此管理员密码和公网地址都不适合公开分享。二级子域名解决的是入口稳定，不代表服务永久在线或天然安全。