你以为只有一个下载器，其实有三个

在 NAS 上排查"我下的东西去哪了"这类问题，有一半时间浪费在一个前提错误上：你以为是同一个下载器，其实是好几套互不相干的。

我这边实际情况：

1. 应用中心装的 qBittorrent        → Web UI :8085，下载到 /vol1/@appshare/qBittorrent/Download
2. NAS 自带的"下载中心"            → 每个用户一个 qBittorrent 实例，数据在系统目录
3. 迅雷                            → 自己的沙盒 /vol1/@appshare/xunlei/downloads

三套，三个界面，三个下载目录，任务列表完全不共享。在 A 里加的任务，B 里查不到，而且不会出现在 A 的目录里。

怎么区分它们

看进程和监听端口：

ss -ltnp | grep -Ei 'qbit|8085|25383'
ps aux | grep -Ei 'qbittorrent|aria2|xunlei' | grep -v grep

看数据目录：

# 应用中心的 qBittorrent：配置和任务在应用目录里
ls /vol1/@appdata/qBittorrent/
# 系统自带的下载中心：按用户分目录
ls /usr/trim/var/downloadcenter/*/qbt 2>/dev/null

看任务备份目录里有没有种子：

ls <qbt配置目录>/BT_backup/ | wc -l

空 = 这套里没有活任务，或者元数据从来没拿到（磁力卡 metaDL 那篇）。

为什么这会造成误判

三个典型场景，我都踩过：

1. "我明明加了任务，怎么没在列表里"

因为你加了 A，现在看的是 B。两套的 Web UI 端口不同（8085 vs 系统给的另一个端口），书签开错很常见。

2. "下载完了，但目录是空的"

任务在 A 里完成，文件落在 A 的共享目录（@appshare/...），而你在翻 B 的下载目录。

3. "这个种子明明有速度，为什么那套显示 0"

同一个资源在两套里各建一次是常见操作，两套的 peer 状态独立。看起来"一个快一个死"，其实是两个独立 swarm 快照。

更麻烦的一种：沙盒下载器不让选目录

有的下载器（尤其是应用中心里的"绿色版"/客户端版）不能把文件存到任意路径，只能存在它自己的沙盒目录里。

表现：界面里"保存路径"那一栏是灰的，或者选了别的目录但文件还是落在沙盒。

这时候的正确做法不是硬改配置，而是加一个搬运脚本：

# 每 5 分钟检查：出现正式扩展名的文件 → 说明下载完成 → 搬进媒体库
find /vol1/@appshare/<app>/downloads -name '*.mkv' ! -name '*.xltd' -mmin +1 | while read -r f; do
  mv "$f" /media/movies/
done

⚠️ 判断"完成"的关键是临时后缀消失：

xxx.mkv.!qB     ← qBittorrent 下载中
xxx.xltd        ← 迅雷下载中
xxx.mkv         ← 完成

只匹配 *.mkv 还不够——很多下载器会提前创建目标文件。所以要么排除临时后缀，要么判断"文件大小连续两次轮询不变"。

结论：先定位，再操作

排查下载问题时，我把顺序固定成：

1. 这个任务在哪一套里？（端口 + 进程 + BT_backup）
2. 它会落到哪个目录？（那套自己的配置，不是通用约定）
3. 有没有我额外造的搬运脚本在跑？（crontab -l、systemctl list-timers）

这三步做完，再谈"下载慢/失败"。跳过这三步，容易在一个根本不存在的任务上折腾半小时。

一句话版本：NAS 上的下载器常常不止一套，任务列表和下载目录互不相通。先用端口 + 进程 + BT_backup 定位"这个任务到底属于谁"，再动手。