按应用分流不生效？Mihomo 进程名称、识别模式与规则顺序排查

给应用写了 PROCESS-NAME 规则，连接却没走预期节点，先查四件事：请求有没有进入客户端、内核有没有识别进程、前面的规则是否先命中，以及规则指向的策略组实际选了什么。只有进程名称写对，还不足以证明按应用分流会生效。

作者：小六｜资料核对日期：2026年10月7日

按应用分流，匹配的是哪个名称？

以本机 Windows 上运行的 Mihomo 为例，PROCESS-NAME 匹配进程名称，PROCESS-PATH 匹配完整进程路径。桌面上的中文应用名称，通常不是这里需要填写的值。官方路由规则文档提供了两种写法及 Windows 示例。

应用还可能把网络工作交给另一个进程。主窗口、更新器和后台服务不一定使用同一个名称，因此应以发生连接时识别到的进程为准，不能只看你点击了哪个图标。

本文讨论的是本机进程识别。电脑通过另一台设备上的代理上网时，远端代理通常不能仅凭网络请求获知这台电脑的原始应用进程名，不应直接照搬本机规则。

触发一次目标应用的操作，观察客户端面板提供的域名、进程、命中规则和出口信息。面板没有展示某个字段时，可以参考客户端自己的诊断入口，不必假定内核已经成功识别。

进程规则只处理已进入客户端的连接。它不会主动把一个没有使用本机代理、也没有被接管的应用拉进来。这两层关系可以结合本站的分流模式与 TUN 指南理解。

Mihomo 的全局配置文档列出三种进程匹配模式：strict 为默认，由内核判断是否开启；always 强制尝试匹配；off 不匹配进程，文档推荐路由器使用这个模式。

如果当前配置是 off，当然不能期待普通进程名称规则依靠识别结果工作。但改成 always 也不是万能开关：请求来源、系统环境和可获取的信息仍然重要。

先记录原值，再在需要诊断的本机环境中做对照。若进程字段仍为空，不要继续堆叠更多进程规则；应查对应客户端与系统的说明。也不要为了试一个名称，随意让所有应用改走同一个出口。

下面是规则片段，不是完整配置。假设你的配置里已经存在名为“常用节点”的策略组，且本机连接记录确认浏览器进程是 chrome.exe：

rules:
  - DOMAIN,intranet.example,DIRECT
  - PROCESS-NAME,chrome.exe,常用节点
  - MATCH,DIRECT

intranet.example 是示意域名，须替换成自己的实际需求。“常用节点”也必须对应已有策略。Mihomo 按从上到下的顺序匹配，因此这里先保留指定域名直连，再处理该浏览器的其他连接，最后才是兜底规则。

如果把兜底 MATCH 放在进程规则上方，后面的具体规则就没有机会按预期处理这些请求。同理，较早命中的域名规则也可能影响你看到的结果。这些顺序关系见前述官方路由文档。

不要额外粘贴第二个顶层 rules，也不要直接用这三行覆盖原来的整份规则。实际调整时，应在当前客户端支持的编辑或覆写位置合并，先检查生成配置能否加载。

按进程名称分流的范围是进程，并不是单个标签页。多个请求如果被识别为同一进程，就会受到相同进程规则影响。希望不同网站走不同路径时，应优先考虑具体域名规则及其顺序，而不是为标签页寻找一个独立进程名称。

路径匹配更具体，但应用更新或换安装位置后，路径可能变化。若采用 PROCESS-PATH，求助截图也应检查是否包含你的 Windows 用户目录，避免不必要的信息暴露。

重新加载配置后，让目标应用发起新连接，记录识别进程、命中规则和最终出口。只看规则编辑器里“保存成功”不够；策略组命中正确，也还要继续看它选中的具体节点。

如果下次更新订阅后规则又丢了，可以查看本站的自定义规则覆写与备份方法。这是规则保存问题，与进程识别失败应分开处理。

你可以带上脱敏后的进程名称、预期出口与实际命中规则交流，不需要公开完整配置或订阅链接：Telegram 联系我