99吧机场

站长推荐

IPLC专线+BGP中转，不限使用设备数量，价格亲民，性价比拉满！

→

FlyBit机场

折扣优惠

IPLC专线+中转,所有线路都是1倍率，用多少算多少，很实在！

→

很多人使用 Clash 时，分流的第一反应是“按网站域名设置”：视频网站走代理、国内网站直连、广告域名拦截。可实际使用电脑时，需求往往更具体：希望浏览器走代理，但游戏启动器保持直连；让某个开发工具使用代理，而下载器不受影响；或者为不同应用指定不同的代理组。

这类需求通常被称为按应用分流或按进程分流。它看起来比域名规则更直观，但背后的工作机制也更复杂。尤其在 Windows、macOS 与 Linux 上，客户端是否支持、是否必须开启 TUN 模式、应用是否会派生子进程，都会影响最终结果。理解这些边界，才能在规则不符合预期时快速定位问题。

一、域名分流与进程分流，到底差在哪里？

普通的域名分流，判断依据是一次连接要访问的目标。例如访问 example.com 时，Clash 根据域名、目标 IP、端口、网络协议等条件，决定连接走代理还是直连。

而进程分流增加了另一个判断条件：这条连接由哪个本地程序发起。例如：

• 浏览器进程发起的连接，交给“代理选择”组；
• 某个游戏客户端进程发起的连接，强制直连；
• 指定开发工具进程发起的连接，交给一个单独的节点组；
• 其他未命中的程序，仍按原有域名规则处理。

从使用体验看，进程规则更接近“给应用单独设网络出口”。但要注意，它不是在应用内部做设置，而是代理内核或系统网络层尝试识别连接的来源。因此，它通常比域名规则更依赖客户端能力和系统权限。

二、为什么按进程分流通常需要 TUN 模式？

在传统“系统代理”模式下，操作系统会把 HTTP 或 SOCKS 代理地址告诉支持代理的应用。浏览器、部分桌面软件会主动把请求交给 Clash 的本地代理端口；但对 Clash 而言，这些请求到达端口后，未必总能可靠地还原“究竟是哪一个本地进程发起的”。

TUN 模式则不同。它会创建一个虚拟网络接口，并把符合条件的系统流量导入代理内核处理。由于流量在更靠近系统网络栈的位置被接管，部分 Clash Meta 内核客户端可以结合系统提供的信息，识别连接对应的进程路径或进程名。

这也是为什么不少客户端会在进程规则旁提示：

• 需要启用 TUN；
• 需要开启“严格路由”“增强模式”或类似选项；
• 可能要求管理员权限；
• 仅在特定操作系统上可用。

名称会因客户端不同而变化，但核心原则一致：**进程规则需要足够的流量接管能力与进程识别能力。**如果只是开启系统代理，即使配置文件写对了，规则也可能完全不命中。

三、先确认：你的客户端和系统是否真的支持进程规则

不要一上来就复制规则。先在客户端的内核、设置或文档页面确认以下事项。

1. 是否使用支持相关字段的内核

目前许多基于 Clash Meta（也常被称为 Mihomo）内核的客户端支持进程相关规则，但“客户端界面支持”不等于“当前运行的内核支持”。如果软件允许切换内核，或使用的是较旧版本，字段可能无法识别、被忽略，甚至导致配置加载失败。

2. 当前平台是否支持

进程识别高度依赖操作系统提供的接口。Windows、macOS、Linux 的实现方式不同，支持程度也并不完全一致。移动系统由于应用沙箱和权限模型更严格，通常不适合期待像桌面系统那样稳定的进程名匹配。

因此，本文的思路主要适用于桌面端。手机上若要实现不同应用走不同网络，更常见的方式是使用客户端提供的“按应用代理”“应用绕过”功能；它与 Clash 配置中的进程规则不是完全同一层面的能力。

3. TUN 是否正常工作

如果客户端显示 TUN 已开启，但规则仍不命中，需要进一步检查虚拟网卡、权限授权和系统安全软件拦截情况。某些安全软件、企业终端管理工具或其他 VPN 客户端，可能改变路由表、过滤网络驱动，进而使流量没有按预期进入 Clash。

四、常见规则字段：PROCESS-NAME 与 PROCESS-PATH

不同内核版本和客户端对规则能力的呈现可能有差异。下面以常见思路说明，实际写入前仍应以自己所用客户端的内核文档和配置校验结果为准。

1. 按进程名匹配：PROCESS-NAME

进程名一般是可执行文件名，例如 Windows 上常见的 app.exe，macOS 或 Linux 上可能没有 .exe 后缀。概念上的写法类似：

rules:
  - PROCESS-NAME,example.exe,PROXY
  - PROCESS-NAME,downloader.exe,DIRECT

含义是：来自 example.exe 的连接交给 PROXY 代理组，来自 downloader.exe 的连接直接连接。

它的优点是书写简单，适合普通软件；不足是重名程序可能存在歧义，且软件升级后主程序名称、后台组件名称可能改变。

2. 按完整路径匹配：PROCESS-PATH

路径匹配比进程名更精确，概念写法如下：

rules:
  - PROCESS-PATH,C:\Apps\Example\example.exe,PROXY

它适合以下情况：

• 同名可执行文件较多；
• 希望明确限定某一个安装位置的程序；
• 需要区分稳定版、测试版或便携版软件。

但路径规则也更容易因软件更新、安装目录变化、用户名变化而失效。尤其是安装在用户目录下的软件，路径中可能包含账户名；迁移电脑或新建账户后，原有配置需要修改。

3. 规则顺序仍然非常重要

Clash 规则通常按从上到下的顺序匹配，命中后即停止继续判断。因此，进程规则要放在你希望它优先处理的位置。

例如，你希望某下载工具无论访问什么域名都直连，那么它的 PROCESS-NAME 规则应放在通用的“国外域名走代理”规则之前。否则，连接可能先被域名规则命中，后面的进程规则根本没有执行机会。

一个较清晰的顺序可以是：

1. 必须优先处理的局域网、公司内网规则；
2. 必须按应用指定出口的进程规则；
3. 广告拦截或安全策略规则；
4. 域名规则集、地区规则集；
5. 最后的兜底规则 MATCH。

五、如何找到真正需要匹配的进程？

“我明明写了浏览器规则，为什么没有效果？”常见原因不是语法，而是实际发起网络连接的并非你以为的那个程序。

以桌面应用为例，一个看似单独的软件，可能同时包含：主界面进程、渲染进程、自动更新程序、后台服务、辅助程序和崩溃上报组件。某些应用启动链接时还会调用系统默认浏览器；某些下载功能则交给独立后台服务处理。

在 Windows 上，可以通过任务管理器查看“详细信息”页，确认可执行文件名；如需进一步确认安装位置，可打开文件所在位置。macOS 可以在“活动监视器”中查看进程；Linux 用户则可借助系统任务管理器或命令行工具查看进程与路径。

更可靠的方法是结合 Clash 的连接页面或日志：

1. 暂时只运行目标应用，减少干扰；
2. 在 Clash 中查看新出现的连接；
3. 观察连接是否显示进程信息、目标域名与命中规则；
4. 修改规则后重新发起一次新的连接，而不是只刷新旧页面；
5. 对比修改前后的命中结果。

如果日志中完全没有进程信息，优先检查 TUN 和权限，而不是反复改进程名。

六、一个实用配置思路：先做“例外”，再保留原有域名分流

按进程分流最稳妥的用法，通常不是把所有软件都逐个列出来，而是只处理少数确有需求的“例外应用”。

例如，你原本已有较成熟的域名分流规则：国内服务直连，特定国际服务走代理，其余流量交给默认策略。现在只希望某个下载器始终直连，那么只需在规则靠前位置增加该下载器的进程规则即可。这样做有三个好处：

• 不会破坏已经可用的域名分流结构；
• 规则数量少，迁移与维护更轻松；
• 软件改名、路径变动时，排查范围明确。

示意结构如下：

rules:
  # 局域网和本地地址优先直连
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 特定应用例外处理
  - PROCESS-NAME,downloader.exe,DIRECT
  - PROCESS-NAME,work-tool.exe,WORK-PROXY

  # 保留原来的域名分流
  - RULE-SET,domestic,DIRECT
  - RULE-SET,global,PROXY
  - MATCH,PROXY

其中 DIRECT、WORK-PROXY、PROXY 都必须是配置中真实存在的策略组或策略名称。不要照抄示例名称后直接保存，否则会因找不到目标策略而报错或出现异常行为。

如果你通过订阅获取配置，建议优先使用客户端的“覆写”“混入”“扩展脚本”或“本地规则”功能加入自定义规则，而不是直接编辑订阅原文件。订阅更新后原文件往往会被重新生成，手动修改容易丢失。

七、进程规则不生效时，按这个顺序排查

1. 确认流量是否进入 Clash

先检查 TUN 是否启用、虚拟网卡是否正常、客户端是否取得必要权限。若应用流量根本没有进入 Clash，任何规则都无从谈起。

2. 检查规则是否位于更宽泛规则之前

尤其要检查前面是否已有 DOMAIN-SUFFIX、GEOSITE、IP-CIDR 或 MATCH 命中。MATCH 一般应放在最后，放在中间会让后续规则全部失效。

3. 核对进程名、后缀和路径格式

Windows 下要特别留意 .exe 是否遗漏；路径中的反斜杠在 YAML 语境下也要注意格式。建议先使用进程名做简单验证，确认可以命中后，再决定是否有必要换成更严格的路径规则。

4. 识别子进程与后台服务

如果主程序规则无效，检查它是否启动了独立的后台进程。浏览器类、Electron 类和游戏平台类应用尤其常见多进程结构。你看到的界面进程不一定承担网络请求。

5. 关闭其他 VPN、代理扩展或网络加速工具

多个网络接管工具同时运行，可能造成流量绕过、重复代理或路由竞争。排查阶段建议只保留一个代理客户端，并暂时关闭浏览器代理扩展，减少变量。

6. 用新连接验证，而非依赖已有连接

长连接、下载任务、实时通信连接在规则修改前就已建立，通常不会自动切换出口。关闭并重新打开目标应用，或主动重新发起请求，才能观察新规则的结果。

八、哪些场景不建议过度依赖按进程分流？

进程规则很方便，但不应把它当成万能方案。

第一，进程名可能被软件更新改变，导致规则在未来静默失效。第二，多进程软件可能需要维护多个规则。第三，某些应用通过驱动、系统服务或容器环境发起流量，普通用户不容易准确识别来源。第四，不同平台的识别可靠性不同，跨设备复制配置时未必能获得相同效果。

如果你的目标本质上是“某个网站走不同节点”，域名规则通常更稳定；如果目标是“整个设备临时全部使用某个出口”，切换全局策略可能更直接；只有在“同一台电脑上的不同应用需要不同网络策略”时，进程分流才最有价值。

九、总结：把进程分流当成精细化工具，而不是基础规则的替代品

Clash 的按进程分流，解决的是域名规则难以表达的本地应用差异化需求。它通常需要兼容的内核、正常工作的 TUN 模式与足够的系统权限；规则还必须放在合适顺序，并准确匹配真实发起连接的进程。

配置时建议从一个明确的小目标开始：先让一个应用强制直连或走指定策略组，再通过连接日志确认是否命中。确认机制正常后，才逐步增加其他例外规则。保留原有域名分流作为主体，用进程规则处理少量特殊应用，通常比“给每个软件都写一条规则”更稳定、更容易维护。