qBittorrent 在 Windows 上绕过 Clash：用 PROCESS-NAME 写直连规则

为什么「BT/PT 不该走代理」是常见诉求

做种与下载时，客户端会维持大量并发连接，总字节数往往远高于浏览网页。若这些连接全部走代理出口，你会遇到三类问题：第一，流量与连接数迅速吃掉套餐或单 IP 的公平使用阈值，账单与限速随之而来；第二，延迟与吞吐并不总是受益，跨境代理对「海量小连接」的抖动更敏感，反而不如本地运营商对 P2P 友好；第三，滥用投诉——部分数据中心对 BitTorrent 特征极其敏感，一旦源 IP 被标记，解封成本很高。

PT 场景还有一层「站规」：许多站点要求汇报与流量行为符合其脚本检测逻辑。虽然技术上有「只让浏览器走代理、客户端直连」的拆法，但是否允许必须阅读各站规则，本文只讲Clash侧怎么把 qBittorrent 从代理链里摘出来，不讨论如何规避站点限制。

另一类人诉求相反：希望日常浏览走代理，而 BT 必须直连。核心矛盾是一样的——你需要一种分流规则粒度，能稳定绑定到「这个进程发出的连接」，而不是去穷举对端域名或 IP 段。

为什么单靠域名规则常常跟不住 BT

在 Steam 或固定 API 场景里，DOMAIN-SUFFIX 非常高效：主机名集合相对稳定。BT 则不同：对端 IP 与主机名高度分散，Tracker、DHT、PEX 与真实 payload 连接混在一起；你即使维护一长串 DOMAIN-KEYWORD，也会遇到「日志里全是 IP、没有 SNI」或「规则集更新滞后」的情况。把大段 BT 相关 IP-CIDR 全写进配置，可维护性又很差。

因此，在 Windows 桌面环境下，把 qBittorrent 的可执行映像名作为匹配键，通常比继续堆域名更省心。站内《Steam 与 Epic 分流》展示了游戏平台如何用域名拆职责；BT 客户端则更适合用「进程」这一侧做锚点，与前者形成互补。

PROCESS-NAME 是什么，适用哪种内核

PROCESS-NAME 属于进程级匹配：当连接由指定映像名发起时，直接命中对应策略（例如 DIRECT 或自定义策略组）。在 mihomo（Clash Meta）系内核与多数基于它的 GUI 客户端中，这条规则类型已经相当常用。若你仍在极旧内核上，请先对照《Meta 内核升级》确认版本，再复现本文示例。

与「应用内 SOCKS 代理」不同：PROCESS-NAME 发生在内核分流层，统一由 Clash 决策出口；应用本身可以继续使用「无代理」模式，由系统或 TUN 把流量导入内核。这样浏览器与其他软件仍可按你的 rules 走代理，而 qBittorrent 单独直连。

Windows 上建议的接管方式：TUN 与规则协同

要让 PROCESS-NAME 生效，前提是内核能看到连接与进程关联。实践里，TUN 虚拟网卡是最省心的全局接管手段之一：系统内大部分应用的 IP 层流量会进入 Clash 决策路径。若你坚持只用系统代理，请确认 qBittorrent 是否真的会跟随系统代理——多数默认配置不会。

开启 TUN 后，建议配合TUN 专文检查驱动权限、UAC 与「绕过中国大陆」等规则是否把 BT 误伤。若你同时在做局域网共享，拓扑与防火墙端口可参考《局域网共享 Clash》，避免手机与 PC 双重 NAT 让日志更难读。

DNS 模式（fake-ip 与 redir-host）会影响你「在日志里看到的远程地址形态」，但不改变「进程名匹配」的本质。若日志里大量出现解析异常，可并行阅读站内 DNS 专文，但不要把 DNS 问题误判为 PROCESS-NAME 写错。

可复制示例：把 qBittorrent 放进 DIRECT

下面是一段最小示意，请插入到你自己的 rules: 列表靠前位置（具体插入点见下一节）。策略名 DIRECT 为内置符号，表示直连；若你希望进自定义策略组，把末尾词改成你的组名即可。

rules:
  # BT client on Windows: match by image name
  - PROCESS-NAME,qbittorrent.exe,DIRECT
  # Optional: portable build may still be qbittorrent.exe; verify in Task Manager
  # ... your DOMAIN / GEOIP / MATCH rules follow ...

若你使用其他客户端，把第二列换成该进程在「任务管理器 → 详细信息」中的「名称」列字符串。部分壳程序或启动器会显示不同映像名，一切以系统任务管理器为准，不要凭安装目录名猜测。

少数发行版可能带版本后缀或不同打包名（极少见）。最稳妥流程是：下载任务跑起来 → 打开任务管理器 → 复制「名称」列原文 → 粘贴进 YAML。这样可同时排除「大小写不一致」和「实际不是主进程」两类问题。

规则顺序：PROCESS-NAME 应该插在哪里

Clash 系规则普遍遵循「从上到下，先命中先返回」。因此，PROCESS-NAME 应放在会「抢走 BT」的宽泛规则之前。典型反例是：很长的 GEOIP,CN,DIRECT 或 IP-CIDR 大段写在前面，而你的 BT 对端恰好落在这些段内——此时即使后面写了 PROCESS-NAME，也永远轮不到它。

更合理的习惯是：把「明确希望直连的进程」放在列表前部，把「按地区或域名大块分流」放在中部，把 MATCH 或最终默认组放在最后。若你使用 Rule Providers 合并远端规则集，注意合并后的实际顺序：GUI 有时会把订阅规则与自定义规则分段拼接，调试时以「连接面板里显示的命中规则序号」为准。

若同一进程同时需要例外（例如只允许某个域名走代理），应拆成更细的进程加域名组合策略——这已超出入门篇幅，但请记住：越具体的条件越应靠前。

常见坑：大小写、便携版、路径空格与多进程

进程名大小写

Windows 文件系统对大小写不敏感，但规则匹配仍建议与任务管理器显示完全一致。若你从论坛抄了 QBittorrent.exe 而实际是 qbittorrent.exe，部分内核在内部比较时可能因实现细节产生差异。养成「从任务管理器复制」的习惯，可以一次消掉九成争议。

便携版与安装路径含空格

PROCESS-NAME 匹配的是映像名，而不是 C:\Program Files\... 完整路径，因此「路径里有空格」本身不会让这条规则失效——真正失效的原因通常是流量未进内核或顺序被其他规则抢占。若你将来使用基于路径的规则类型（视内核版本而定），再需要关注引号与转义；对入门场景，优先用进程名即可。

子进程与辅助进程

某些客户端会拉起 helper 或更新器进程。若日志显示部分连接来自 xxx-helper.exe 而不是 qbittorrent.exe，你需要为 helper 单独补一行，或改用更上层的策略。排查时请在连接日志里看「进程」列，而不是只看软件窗口标题。

qBittorrent 自带代理设置要不要填

当你已经用 TUN 或系统级方式把流量交给 Clash 时，一般建议把 qBittorrent「工具 → 选项 → 连接」里的 HTTP/SOCKS 代理留空，避免「应用代理」与「内核分流」叠成双跳。若你刻意使用「应用直连、仅浏览器走系统代理」的经典架构，则应在应用内明确关闭代理，只依赖 PROCESS-NAME 与 TUN 的组合，否则容易出现一侧直连一侧代理的割裂，PT 汇报 IP 也会更难解释。

对监听端口、UPnP/NAT-PMP 与「绑定到特定网卡」等高级选项，若你启用了 TUN，请阅读你所用客户端文档，确认与虚拟网卡路由是否冲突。此类问题表现为「有元数据无速度」或「仅 IPv6 通」，与 PROCESS-NAME 命中与否无关，需要并行排查网络栈。

用连接日志验证：命中了哪条规则

改完 YAML 后不要凭感觉认为「应该好了」。请打开连接日志，筛选来自 qBittorrent 的记录，核对两点：第一，策略列是否显示为 DIRECT（或你指定的直连组）；第二，命中规则名或序号是否正是你写的 PROCESS-NAME 行。若仍显示走某个代理组，回到「顺序」与「接管模式」两步重新查。

高峰时段日志刷屏很快，可以先暂停其他大流量应用，只保留一个测试种子，降低噪声。对 PT 用户，建议使用体积小的免费合法种子做连通性验证，避免在排错阶段触发站点脚本。

反过来：只想代理浏览器时怎么思考

有人不需要全局 TUN，只希望浏览器走代理，其它软件全部直连。这种架构下，qBittorrent 默认就不会走系统代理，其实「无需 PROCESS-NAME」也能直连。但一旦你把系统代理或 TUN 打开得过大，就又需要进程级例外把 BT 摘出来——本文写法正是服务这一场景。

若你使用「规则模式」而非全局，记得检查订阅自带的 MATCH 默认出口：有时 BT 会被送进「自动选择」组而不是 DIRECT，表象仍是「走了代理」。解决仍是顺序与默认策略，而不是单纯加域名。

现象对照表：先怀疑哪一层

常见问题（速答）

PROCESS-NAME 里到底写不带后缀行不行？

建议与任务管理器「名称」列完全一致，Windows 上几乎总是带 .exe。若无效，以日志识别名为准。

路径带空格要不要加引号？

仅写 PROCESS-NAME 时不需要路径，因此也不涉及引号。只有当你改写到包含路径的规则类型时，才需要阅读对应内核文档的转义说明。

和「绕过中国大陆」类规则冲突怎么办？

把进程直连行放在会误判的那类规则之前，或临时关闭订阅集对比日志。核心是「谁先匹配谁赢」。

能否让 PT 只 Tracker 走代理、Payload 直连？

技术上可以拆得很细，但 PT 站规未必允许，且维护成本高。一般用户更现实的目标是「整进程直连或整进程走组」，不要在未读站规前过度设计。

合规与责任边界

请遵守当地法律法规与版权方要求。BT 与 PT 本身是中性的分发技术，但具体资源是否合法、站点是否授权你使用其规则之外的出口组合，需要你自己判断。本文仅描述 Clash 在 Windows 上的分流规则写法，不构成任何法律或站点政策建议。

写在最后

当你已经习惯用一套「很宽」的 Clash 配置解决日常上网时，别忘了 BT 与 PT 是大连接数、大流量、强对端分散的特殊 workload。用 PROCESS-NAME 把 qBittorrent 从代理链里摘出来，往往比继续堆域名更干净，也更利于对照日志排错。把规则放在正确顺序、确认 TUN 或系统接管真的覆盖到进程，再清掉应用内重复代理，三件事做对，九成场景就能稳定 直连。

相比在论坛里复制一长串神秘域名，基于进程的分流可读性和可迁移性都更好：换 Tracker、换对端 IP，你不必跟着改表。若你愿意把规则集与自定义片段分层维护，长期成本也会更低。

全平台安装包与免费订阅入口请使用本站下载中心；更多专栏文章见技术专栏。

若你还希望把 Steam、Epic 等大平台 CDN 与社区拆开，可继续阅读《Steam 与 Epic 分流》，把「进程级」与「域名级」两套思路组合进自己的运维习惯里。