76 lines
2.7 KiB
Markdown
Executable File
76 lines
2.7 KiB
Markdown
Executable File
# 群晖Docker中qbittorrent流量路由配置指南
|
||
|
||
# 核心结论
|
||
|
||
**不推荐用 ****`PROCESS-NAME`**** 给群晖 Docker 内的 qb 做分流，大概率无效；优先用【源 IP 规则 SRC\-IP\-CIDR】，稳定可靠。**
|
||
|
||
## 为什么 Docker 容器的 qb，PROCESS\-NAME 不好用
|
||
|
||
1. Docker 有独立 **PID Namespace**。容器里面的 qb 进程，在宿主机（群晖）内核视角里，进程名识别会混乱。
|
||
|
||
2. Mihomo 的 `PROCESS-NAME` 只能**识别宿主机上原生运行的进程**；局域网 / 容器出来的数据包，内核无法拿到容器内部的进程名称。
|
||
|
||
3. 就算你开了 `find-process-mode: always`，TUN 模式下也很难稳定捕获容器内进程，经常匹配失败，属于坑。
|
||
|
||
> PROCESS\-NAME 适合：Windows、宿主机直接跑的程序；**不适合 Docker 容器内服务**。
|
||
>
|
||
>
|
||
|
||
## ✅ 推荐方案：给 qb 容器固定静态 IP，Mihomo 写 SRC\-IP\-CIDR 规则
|
||
|
||
1. 给 qb 容器分配**固定静态 IP**（自定义 bridge 网桥，不要默认 bridge）
|
||
例：`192.168.1.100`
|
||
|
||
2. 在 mihomo 规则文件，**放在规则靠前位置（优先级高）**
|
||
|
||
```yaml
|
||
# qBittorrent容器全部流量直连，不走代理
|
||
- SRC-IP-CIDR,192.168.1.100/32,DIRECT
|
||
```
|
||
|
||
3. 后面保留你原来的其他规则、最后 MATCH 兜底。
|
||
|
||
- 效果：只要源 IP 是 qb 容器，**所有流量（Tracker、Peer、DHT UDP）全部 DIRECT 直连**，完全不进代理。
|
||
|
||
## 如果你只是想要：Tracker 走代理，Peer 直连
|
||
|
||
那就**不要在 mihomo 全局拦截 qb**，保留 qb 容器流量正常走 mihomo 规则，**在 qb 客户端内设置**：
|
||
|
||
- 填写 SOCKS5，**取消勾选【使用代理服务器进行用户连接】**
|
||
|
||
- Tracker 走代理，Peer/DHT 直接本地出口。
|
||
|
||
> 这种方式不需要修改 mihomo 任何针对 qb 的规则，是更经典的 bt 分流方案。
|
||
>
|
||
>
|
||
|
||
## 补充：如果你硬要尝试 PROCESS\-NAME（不推荐）
|
||
|
||
需要满足全部条件：
|
||
|
||
1. mihomo 开启 TUN
|
||
|
||
2. `find-process-mode: always`
|
||
|
||
3. qb 容器使用 `--pid=host` 共享宿主机 PID 命名空间（**有安全风险，不建议**）
|
||
|
||
4. 找到宿主机视角下 qb 的进程名，写`PROCESS-NAME,qbittorrent-nox,DIRECT`
|
||
|
||
## 两种方案对比
|
||
|
||
1. **SRC\-IP\-CIDR（推荐）**：稳定、无坑、不需要 TUN、不需要特权参数，群晖 Docker 首选。
|
||
|
||
2. **PROCESS\-NAME**：容器场景不稳定，依赖 TUN\+pid=host，容易失效。
|
||
|
||
> ⚠️法律提示：未经批准使用翻墙工具访问境外互联网属于违规行为，以上仅为网络路由技术原理讲解。
|
||
>
|
||
>
|
||
|
||
你打算：
|
||
A\. qb**全部流量都直连**，Tracker 也不走代理；
|
||
还是
|
||
B\. Tracker 走代理，Peer/DHT 直连？
|
||
我直接给你对应完整 yaml 片段。
|
||
|
||
> （注：部分内容由豆包工作 AI 生成）
|