Clash/Mihomo 装在路由器上，PROCESS-NAME 为什么不生效？
路由器只能看到转发流量的网络信息，拿不到手机或电脑上的进程名。说明 PROCESS-NAME、find-process-mode 与按设备、域名分流的边界。
先看重点软路由上的 Mihomo 无法从转发的数据包还原手机或电脑的本地进程名；`find-process-mode: always` 也不会把缺失的信息变出来。`PROCESS-NAME` 只适合内核运行设备上能关联到本地进程的连接。路由器应按源 IP、域名、目标端口等可见信息分流；必须按应用时，把规则放到终端客户端。
你在软路由的规则里写了 PROCESS-NAME,Telegram,PROXY，手机上的 Telegram 仍然落到最后的 MATCH；把 find-process-mode 改成 always，结果也没变化。这里更可能不是进程名少写了后缀，而是规则放在了看不到终端进程的位置。
路由器能转发手机的连接，不等于能读取手机里是谁创建了连接。 进程名属于终端操作系统的本地信息，不在普通 IP 数据包里。要按手机或电脑上的具体应用分流，规则通常要由那台终端上的客户端执行。
路由器收到的是连接信息，不是进程表
以 IPv4 为例，RFC 1812 把路由器描述为执行网络层转发的设备：它检查 IP 头，决定下一跳，再把数据包发出去。源地址、目标地址和协议等网络信息会随包到达；进程名、可执行文件路径和 PID 不属于 IP 头字段。
因此，手机把一条连接交给软路由时，路由器可以区分它来自哪一个局域网地址、访问哪个目标和端口，却没有一项标准字段写着“这是 Telegram”或“这是某个游戏”。NAT 可能继续改写地址和端口，也不会补上终端进程名。
Mihomo 官方规则里的 PROCESS-NAME 与 PROCESS-PATH，匹配的是内核能够关联到连接的进程信息。内核就在电脑或 Android 设备上运行时，它有机会向本机系统查询；内核在路由器上时，查询到的也是路由器自己的进程，不是另一台设备的进程表。
always 只强制查询，不会生成远端信息
Mihomo 的 find-process-mode 有三种文档值：strict 是默认模式，由内核判断何时查询；always 强制为连接查询进程；off 不做进程匹配，官方还明确建议路由器使用 off。
这里的“强制”很容易被误读。它只改变 Mihomo 是否尝试查找，不能让路由器跨设备取得手机或电脑的本地进程名。为了补救终端规则而在软路由上改成 always，不会让 PROCESS-NAME 突然认识 LAN 设备上的应用，还可能做没有结果的额外查询。
路由器自己发起的连接是另一回事。软件更新、路由器本机服务或直接运行在路由器上的程序，进程就在同一系统里；只要当前平台和接入路径支持查找，进程规则可能匹配这类本地连接。偶尔看到一次命中，先分清它是不是路由器本机流量，不能据此推断手机应用也已被识别。
按路由器真正拥有的信息选规则
Mihomo 官方规则已经提供了不依赖终端进程的条件。选择哪一种，取决于你真正想区分什么：
| 想区分的对象 | 路由器可用的线索 | 更合适的规则方向 |
|---|---|---|
| 某台手机、电视或电脑 | 固定的局域网源地址 | SRC-IP-CIDR |
| 某个网站或服务域名 | 当前连接中已取得的域名 | DOMAIN、DOMAIN-SUFFIX 或相应 RULE-SET |
| 某类目标端口 | 目标端口与网络协议 | DST-PORT、NETWORK |
| 路由器上的本地程序 | 路由器本机进程名或路径 | PROCESS-NAME、PROCESS-PATH |
| 终端上的具体应用 | 终端本机进程或 Android 包名 | 在终端客户端做应用分流 |
源地址规则能区分设备，不能区分同一设备里的两个 App；域名规则能区分目标，不能保证一个 App 的所有请求都只访问固定域名。路由器界面把某项功能叫作“应用分流”，也可能实际使用域名、IP、端口或自有分类库，不能因此把它等同于 Mihomo 的进程规则。
域名是否已经交给规则引擎，还受 DNS、TUN 和嗅探路径影响。需要理解这一层时，可以对照域名嗅探读取的实际信息；不要为了让路由器猜应用而盲目开启更大范围的嗅探。
规则位置正确，条件才有机会命中
Mihomo 按列表从上到下匹配，靠前规则优先。进程规则写在一个已经覆盖全部流量的规则后面，即使本机进程信息可用，也轮不到它执行。MATCH 会接住所有尚未命中的请求，通常应留在末尾。
反过来，日志显示某条策略组或 MATCH，只说明这次请求最终选择了哪条路由，不证明进程查询本身成功。日志含义可参考DIRECT、REJECT 与 MATCH 的区别；判断软路由边界时，最关键的是流量由路由器本机产生，还是由 LAN 设备转发而来。
如果同一条规则在电脑客户端能命中、搬到软路由后不命中，这个对照已经很有价值：规则语法可能没有问题，变化的是内核运行位置和可见信息。继续修改大小写、通配符或 always，无法跨过这层边界。
必须按应用时，把判断放回终端
需求真的是“同一台电脑里浏览器走代理、游戏直连”时，让终端上的 Mihomo 客户端接管并执行进程规则，才有本地进程信息可用。Android 的 PROCESS-NAME 按官方文档还可以匹配包名；它仍然是 Android 设备本地的能力，不会自动传给上游路由器。
只想让一整台设备使用不同出口，则没必要引入进程匹配。为设备保留稳定的局域网地址，用源地址规则表达策略，通常更符合路由器已经掌握的信息。已有宽泛规则抢先命中时，再处理顺序；修改订阅生成的规则前，也要避免下次更新覆盖，可参考自定义规则的保留边界。
本文没有对某个 OpenWrt 插件、固件版本或图形界面做兼容性测试，也不把第三方“应用识别”功能一概视为进程匹配。结论只覆盖 Mihomo 文档中的 PROCESS-NAME、PROCESS-PATH 与 find-process-mode，以及普通 IP 转发本身不携带终端进程名这一边界。
资料来源
以下来源于 2026/8/25 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……