Clash Verge 如何为不同应用设置独立的分流规则？

一、先厘清：Clash Verge 应用分流分的是什么

在搜索引擎里敲下「Clash Verge 应用分流」的人，多半撞上的是同一个具体困境：某个软件必须走代理，另一个必须走直连，可它们访问的域名却高度重叠，用域名规则或规则集根本切不开。要解决它，第一步不是急着写规则，而是先搞清楚 Clash 的判定模型——判定模型决定了哪些手段有效、哪些只是徒劳。

Clash 系客户端处理一条新连接时，做的事情其实非常克制：先取出这条连接的特征，再从 rules 列表的第一条开始逐条比对，命中即停，然后按该条规则指向的策略组决定出口。所谓「特征」有两个来源：一是连接的「去向」——目标域名、目标 IP、地理库归类；二是连接的「来路」——究竟是哪个进程发起了这条连接。前者对应域名规则，后者就是本文所说的应用分流。

域名规则解决「网站」，进程规则解决「软件」

两者是互补关系，而不是替代关系。示例：某网盘客户端与浏览器都会访问同一家 CDN 的域名，你希望网盘走直连省流量、浏览器走代理。域名规则在这里无能为力，因为目标完全一致；一条按进程匹配的规则，却能把两者干净地分开。

反过来说，如果两个软件的流量目标本来就泾渭分明——比如一个只访问内网地址、一个只访问境外站点——那么用域名或 IP 规则显然更划算：它跨平台、可复用、不依赖进程识别能力，维护成本也更低。所以判断顺序应当固定下来：能用目标特征解决的场景，不要动用进程特征。这条顺序看似保守，实则是把后续的排查成本提前省掉了。

客户端与内核的分工

Clash Verge 是图形化客户端，负责配置管理、流量接管与界面呈现；真正执行匹配计算的是它调用的内核。截至当前的最新版本，Clash Verge 系列通常以 mihomo（由 Clash.Meta 分支延续而来的内核）作为内置内核。这意味着：你能不能写 PROCESS-NAME 这类规则，取决于内核能力，而不是界面上的开关。也正因如此，换客户端或换内核时，规则语法大体保持一致，真正会变的往往只是配置的存放位置与加载方式。

二、平台边界：哪些系统真的能做进程级分流

动手配置之前，先确认自己的平台有没有这条路可走。桌面系统允许客户端查询进程信息，移动系统出于沙盒限制通常不提供同等能力。这一条差异，决定了你在不同设备上要用完全不同的做法，也决定了后面的配置步骤是否值得展开。

平台	常见客户端形态	进程级分流可行性	说明
Windows	Clash Verge 系列	通常可行	需注意可执行文件名的完整写法
macOS	Clash Verge 系列	通常可行	路径形态与 Windows 差异较大
Linux	Clash Verge 系列	通常可行	需留意权限与 TUN 的授权方式
Android	多为其它 Clash 内核客户端	通常走分应用代理	按包名整体放行或绕过，而非规则匹配
iOS	第三方网络客户端	通常不可行	沙盒限制，一般无法获知发起进程

表中最值得留意的是最后两行。iOS 上的网络客户端受系统沙盒限制，一般无法得知发起连接的是哪个 App；Android 虽然允许通过 privacy toolService 实现分应用代理，但那是「整包放行或整包绕过」，而不是规则列表里的一行文本匹配。所以严格来说，移动端的应用分流通常由客户端的一个开关完成，而非由 rules 段落完成。

这也解释了为什么网上关于「按应用分流」的教程常常互相矛盾：一部分人在讲桌面端的进程规则，另一部分人在讲移动端的分应用开关，两者名字相近，机制却完全不同。把平台先钉死，后面的步骤才不会有歧义；否则你会在一堆看似冲突的结论里反复打转。

三、决策树：三个问题决定要不要写进程规则

在动手改配置之前，按顺序问自己三个问题。任意一个答「否」，就应该换方案，而不是硬写规则。

1. 能否用域名或 IP 规则解决？如果目标应用的流量目标足够独特，用域名后缀或规则集更省事，也不会因为应用改名、换目录而失效。
2. 发起连接的是不是稳定的同一个进程？现代桌面应用常为多进程架构——浏览器按标签页拆分进程、Electron 应用区分渲染与更新进程、带自动更新模块的软件会另起子进程。你必须能指认出「真正发起网络请求的那一个」。
3. 能否接受 TUN 模式的代价？若目标应用不遵循系统代理设置，进程规则往往要配合 TUN 才能完整生效，而 TUN 需要更高的系统权限。

三问全部通过，再进入配置环节；否则沿用规则集方案，或者改用移动端的分应用开关，都是更理性的选择。判断的价值不在于多写几条规则，而在于避免把时间花在一个注定不生效的方向上——毕竟排查一条「永远不会命中」的规则，消耗的耐心往往比写十条规则还多。

四、前置准备：内核能力、接管模式与权限

确认内核与规则支持

最可靠的方法不是查资料，而是做一次最小验证：在配置里临时加一条进程规则，指向任意一个你常用的应用，保存并触发重载。如果内核不支持该规则类型，加载日志通常会出现与该规则类型相关的错误或警告；若加载干净通过，就说明能力具备。验证完成后，把这条测试规则删掉或改写成正式规则，别让它留在配置里变成下一次排查的干扰项。

系统代理与 TUN 的成本差异

接管模式直接决定进程分流能否成功。系统代理模式改动小、通常不需要管理员权限，但它只对「愿意读取系统代理设置」的应用有效；经验性观察，一部分应用会自行处理网络栈，或直接使用自有协议与端口，从而绕过该设置。TUN 模式在网络层接管，覆盖面更广，代价是需要安装虚拟网卡并授予较高权限，部分系统上首次启用需要重启，退出异常时还可能残留网卡条目。

因此一个务实的推进顺序是：先开系统代理试一次，用连接页面确认目标应用的流量有没有被捕获；若压根抓不到，再切到 TUN。不要一上来就上 TUN，那等于把权限成本提前支付了，却未必买到对应的收益。

五、最短可达路径：把一条进程规则写进去

桌面端（Windows / macOS / Linux）

桌面端的操作路径大同小异，核心是找到「当前生效的那份配置文件」并编辑它。下面这条路径只求最短可用，不涉及任何扩展写法：

1. 打开客户端的配置文件（Profiles）页面，确认哪张卡片处于选中状态——只有被选中的那份配置在生效。
2. 在该卡片上找到编辑入口（通常是卡片上的编辑图标，或右键菜单中的编辑文件项；不同版本的入口位置可能不同）。
3. 在文件的 rules: 段落中插入进程规则。注意 YAML 用两个空格缩进，并且规则自上而下生效。
4. 保存。多数版本保存后会自动重载；若没有生效，重新点击该卡片使其重新加载。
5. 切到连接（Connections）页面，触发目标应用的网络行为，观察这条连接命中的规则。

失败分支与回退

写入规则后最常见的两个失败分支：一是保存时提示 YAML 语法错误，通常由缩进不一致或缺少冒号引起，此时客户端的表现是配置加载失败；二是加载失败后客户端静默退回上一份可用配置，界面上看起来「一切正常」，实际改动根本没进去。前者靠日志里的错误行定位，后者靠日志加配置文件内容核对确认。无论哪种，最快的回退方式都是把新加的那几行整段删掉，先恢复到可用状态，再逐条加回去试——一次只加一条，问题出现在哪一步会一目了然。

用扩展或合并配置避免被覆盖

Clash Verge 系列提供了在订阅配置之外追加自定义内容的能力，常见的叫法是合并配置（Merge）与脚本（Script），具体名称与入口以你所装版本为准。把进程规则写在扩展层里，订阅更新时就只会替换基础配置，你的自定义部分会被重新合并进去。这是长期维护唯一省心的做法，也能让「配置是谁改的、为什么这么改」变得可追溯。

一份可参考的规则片段

rules:
  # 按进程名：让某个即时通讯工具走代理
  - PROCESS-NAME,ExampleChat.exe,PROXY
  # 按完整路径：某个绿色版工具走直连
  - PROCESS-PATH,/opt/example/example-bin,DIRECT
  # 正则：匹配同一厂商的一组子进程
  - PROCESS-NAME-REGEX,(?i)example-updater,REJECT
  # 其余规则保持原样
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这段片段演示了三件事：进程规则必须出现在兜底规则之前；策略名要与 proxy-groups 中定义的名字完全一致；注释用 # 开头，方便日后回忆当初为什么写这一条。示例中的进程名与路径均为占位，请替换为你自己通过连接页面确认过的真实标识。

六、三种粒度：进程名、进程路径与正则怎么选

进程匹配的方式不止一种，选哪一种，取决于你愿意为「精确」付出多少维护成本。粒度越细，命中越准，但被一次应用更新悄悄打回原形的概率也越高。

• 进程名（PROCESS-NAME）：只比对可执行文件名，不关心它装在哪个目录。优点是应用升级、换安装位置后依然有效；缺点是无法区分同名进程。经验性观察，Windows 平台上通常需要写全带扩展名的文件名，具体以内核文档与实际验证为准。
• 进程路径（PROCESS-PATH）：比对完整路径，精确度最高，也最脆弱。应用升级换了目录、或你更换了安装盘，规则就会静默失效——它不会报错，只会不命中，这是最难排查的一类问题。
• 正则变体：mihomo 内核提供进程名与路径的正则形式，用于匹配「同一厂商的一组进程」。它适合处理多进程架构的软件，代价是每次匹配都要走正则引擎，规则数量应当保持克制。

选择的经验法则很简单：默认用进程名，只有确实遇到同名冲突时才升级到路径或正则。宁可在冲突时多写一条规则，也不要把可维护性一次性透支掉。

七、规则顺序：九成「规则没生效」都出在这里

规则匹配是自上而下、首条命中即止。这意味着规则在列表里的位置，比规则本身的写法更能决定结果。同一个进程，在规则列表里的不同位置，会得到完全不同的出口。

最常见的两种失误：把进程规则写在地理库规则（例如 GEOIP,CN,DIRECT）或兜底规则（MATCH）之后，导致它永远轮不到被匹配；以及，写下了一个在 proxy-groups 里并不存在的策略名，配置加载直接失败，客户端退回上一份配置，而你看到的现象却是「改了跟没改一样」。

因此每次改动后，都要去日志里确认两件事：配置是否成功加载、目标连接命中的是哪一条规则。这两条信息足以覆盖绝大多数排查场景，也应当成为固定动作。

八、性能与成本：规则规模的边界在哪里

把「性能」这个词用在这里，需要先明确它测的是什么。规则匹配发生在每一次新建连接上，属于纯 CPU 的字符串比对；而用户真正感知到的，是网页打开的等待时间、视频的缓冲速度。这两者之间隔着好几个数量级，所以绝大多数人的规则数量根本触不到性能天花板。

经验性观察：规则条数从几百条增长到数千条时，单条连接的匹配耗时会呈现可测量的增长，但相对于网络往返时间，通常仍可忽略。真正随规模线性上升的是维护成本——规则越多越细，越容易互相遮挡，越难定位一条连接究竟命中了谁。这属于定性趋势，具体幅度因设备与配置而异。

进程类规则还额外带来一项开销：内核需要向系统查询发起连接的进程身份。在 TUN 模式下，这个查询发生在连接建立路径上。经验性观察，在普通桌面使用强度下不构成可感知的延迟；但如果规则列表里塞进了上百条进程规则，仍值得做一次对照测试，而不是凭印象判断。

可复现的测量方法：

1. 固定一个任务（例如同一个文件下载、或同一段测速流程），记录改动前客户端的资源占用峰值与任务完成时长。
2. 加入或移除一批进程规则后，重复同一任务，对比两次结果。注意关闭日志的调试级别——调试日志本身的开销会污染结论。
3. 在连接页面观察一段时间内的连接总数与规则命中分布，判断改动是否真的触达了预期流量。

九、验证与观测：三个可复现的检查动作

写完规则不等于生效。下面三个动作彼此独立，建议按顺序执行，任何一个环节对不上，都能快速缩小问题范围。

动作一，看连接。打开连接页面，触发目标应用的网络行为，在列表中找到对应条目，查看它命中的规则与出口链路。这是最直接的一条证据，也是判断「规则有没有轮到」的唯一方式。

动作二，看日志。把日志级别临时调到 info 或 debug，再触发一次请求。自定义规则命中时，日志行里会出现你写下的规则内容（日志格式随内核版本可能略有差异）。确认完毕记得把级别调回去，避免长时间高频写日志。

动作三，反向确认进程名。这一步最容易被忽略，却最省事：先在连接页面里观察目标应用实际显示的进程标识，再照着它去写规则，而不是凭记忆或猜测。在 Windows 上，这一步能一次性解决「到底要不要带扩展名」的疑问——连接页看到什么，就写什么。

十、故障排查：现象、原因、验证与处置

把排查路径固定成表格，可以避免每次出问题都重新推演一遍。

现象	可能原因	验证方式	处置
目标应用仍走直连	连接先命中了更靠上的规则；或应用绕过系统代理	连接页面查看该连接命中的规则名	把进程规则上移；确认是否需切到 TUN
保存后客户端毫无变化	配置加载失败并回退；或未激活该配置	日志中的错误行；配置文件页面的选中状态	修正 YAML 缩进与策略名拼写
规则用了一段时间后失效	订阅更新覆盖；或应用更换了安装目录	核对当前配置文件中是否还包含该行	改用扩展层；把路径规则换成进程名
Windows 上进程规则不匹配	进程名缺少扩展名；或发起请求的是另一个子进程	连接页面中该连接的进程标识	按实际显示的标识改写；或用正则覆盖子进程

这张表里的每一行，验证方式都指向同一个地方：连接页面与日志。养成「改完必看这两处」的习惯，比记住任何单一技巧都管用。

十一、适用与不适用场景清单

把边界写清楚，比多给十条规则更有价值。下面按「值得做」和「不值得做」两侧分别列出准入条件。

适合用进程规则的场景：桌面环境下，少量关键应用的流量目标与其它应用高度重叠；某个应用需要走与全局默认不同的出口；你能明确指出发起连接的那一个可执行文件；以及，你愿意为这几条规则单独维护一份扩展配置。

不适合的场景：iOS 等沙盒严格的移动系统，通常无法按进程识别，应改用客户端本身的分应用能力；Android 的分应用代理本身就是按应用放行或绕过的机制，不必绕道去写规则；应用的网络请求由多个不同进程共同发起、而你无法收敛到少数几个；所在环境不允许安装虚拟网卡或授予较高权限。

还有一类容易被忽略的情况：规则的所有权。如果你的配置来自第三方订阅，直接改动可能在后续维护中造成冲突，此时更合适的位置是扩展层。规则放在哪里，本身就是一种成本决策。

十二、最佳实践检查表

下面这份清单可以直接当作改动前后的对照表，逐条打勾即可。它的作用不是让你写更多规则，而是确保每一次改动都可验证、可回退、可长期维护。

• 先尝试域名或规则集方案，确认确实切不开再动进程规则。
• 默认使用进程名匹配，仅在遇到同名冲突时升级到路径或正则。
• 进程规则一律放在地理库规则与兜底规则之前。
• 自定义内容写在扩展层，不直接改订阅配置本体。
• 每条规则加一行注释，写明它为什么存在。
• 改完必查连接页面与日志，确认命中情况。
• 进程规则总量保持精简，定期清理已卸载应用的条目。
• 做性能对照测试时，先关闭调试级别日志。
• 保留一份改动前的配置备份，便于整段回退。

十三、常见问题

十四、小结与下一步

回到最初的问题：Clash Verge 的应用分流，本质上是把「连接由谁发起」纳入规则判定。它擅长处理域名规则切不开的局面，但代价是平台受限、依赖进程识别，并且往往需要配合 TUN 才能覆盖不读系统代理的应用。是否值得，就看域名规则是否真的无能为力。

如果决定要做，建议的行动顺序是：先用连接页面确认目标应用的进程标识，写一条进程名规则放在规则列表前部，开启系统代理验证；抓不到流量再切 TUN；长期使用则把规则迁到扩展配置里，避免订阅更新时被覆盖。每改一次，都回到连接页面与日志确认一遍——这两处始终是最可靠的判断依据。

至于后续的走向，基于公开信息只能做经验性判断：内核侧的进程识别能力与客户端的扩展配置机制，通常比界面上的开关更值得留意——前者决定规则能不能写，后者决定规则能不能留住。示例：在下一次升级客户端前，可以先翻一翻该版本的发布说明，看其中是否提到内核版本或配置合并方式的变化，再决定要不要调整现有写法；若说明中未涉及相关内容，维持现状即可。具体差异仍以你所装版本的加载日志与实际表现为准。