1 为什么要先把 TUN、进程语义与 PROCESS-NAME 分开想
TUN 做的是把符合条件的三层路由流量引进用户态内核里做策略；而 PROCESS-NAME（以及同属进程族的其他规则前缀）吃的是「这一条连接在操作系统眼里更像是谁发起的」。两件事相关，但并非自动等价：你可以在 TUN 下只看 IP、域名就能把包送出去；只有当你当真依赖进程匹配做放行、分应用出口或局域网例外时，才让 find-process-mode 成为你的前置开关旋钮。
许多读者在安装图形客户端后直接抄社区规则：列表上半段 GEOIP/DNS 类规则跑得欢，一看到 PROCESS-NAME 就像失效——往往不是规则写错了单词，而是链路里根本没拿到进程上下文，或拿到的名字和你抄的条目不是同一粒度（示例：更新器子进程顶着另一个可执行文件名、浏览器把出口委托给常驻网络服务组件）。这也是为什么我们会把本篇与《Clash Verge Rev TUN 模式完全指南》并列：先有稳定的 tun/stack，再讨论谁在走这条栈。
2 find-process-mode 三档：按需、全开与彻底关闭
在 Mihomo 通用YAML 顶层，`find-process-mode` 的常见合法取值是三档字面量：strict（大多数发行版的默认语义）、always、以及表示关闭匹配的 "off"（请务必加双引号）。粗粒度理解：strict 让内核按需为需要进程语义的路径做解析工作，从而在「确实写了进程规则」与「大部分时间不想为无关连接付 CPU」之间折衷；always 则更积极地尝试给更多连接挂载进程上下文，适合你在排障窗口里对比「到底是不是解析力度不够」——代价通常是更高的后台开销与更嘈杂的观测；off 则等价于关掉这条能力，等价于宣告PROCESS-NAME 一类规则别想稳定吃红利，典型场景是不需要进程维度的网关设备或你希望策略完全由 IP/DNS/SNI 决定。
由于不同内核小版本对内部节流与回填时序的实现细节会持续迭代，本文刻意不把「strict 在省电上具体省百分之几」写成硬数字——那是实验室指标而不是读者 yaml 要能背下来的常量。实战中你只要记住：strict 是桌面长期驻留的更省心默认盘，always 是短时试验盘，off 是给「明确不需要进程」的机器用的刹车。
顺带区分：它和「跳过本地」「auto-route」不是一张表上的同一个键
Tun 小节里你还有 stack、auto-route、绕过私有地址、bypass gateway 等平台相关选项；它们决定了路由表怎么走，并不自动等同于进程字段如何从内核模块冒泡到你的规则引擎。别把「我本机局域网想直连」与「我本机 QQ 名叫什么」两件事混在同一个 troubleshooting 话术里——前者看路由与 SKIP 规则位置，后者看 find-process-mode 是否与连接视图对齐。
3 YAML 放哪、off 为何要加引号
极简骨架如下：与其它顶层键并列即可；若你希望临时对比行为，可把 always 与调高日志级别组合使用几分钟，再在确认后回到 strict。记得把网关型场景里刻意的关闭写成带引号的 "off"，否则部分 YAML 实现会把裸露的 off 吃进布尔语义，传递到内核就出现「无效的 find-process-mode」一类报错——这也是 OpenClash / 合并器生态里老生常谈的坑。
mode: rule
ipv6: true
find-process-mode: strict
# Gateway profile without process-aware rules — quote "off".
# find-process-mode: "off"
tun:
enable: true
stack: system
auto-route: true
strict-route: true
dns:
enable: true
enhanced-mode: fake-ip
proxies:
- name: "local-out"
type: direct
proxy-groups:
- name: FINAL
type: select
proxies:
- local-out
rules:
- PROCESS-NAME,SomeApp,DIRECT
- MATCH,DIRECTon/off 视作布尔字面量——合并配置或远端 provider 下发的片段尤其容易静默踩雷。写上 find-process-mode: "off" 是唯一稳妥的明文关闭写法。
如果你在图形界面里勾选「禁用进程嗅探」「关闭 PID 映射」一类的开关，却仍看到合并结果里出现一个奇怪的布尔字段，十有八九是 UI 导出器与 YAML 语义未对齐——此时回到磁盘上的生效配置全文检索 find-process-mode，比在社区帖子里猜玄学更快。
4 为何规则里明明命中 PROCESS-NAME，体验却不对
第一组原因和写法直接相关：Mihomo期望的进程 token 多数是不带路径的可执行文件名或与平台一致的短名——你在任务管理器里复制成带盘符的路径、或只看到服务宿主进程名（如svchost.exe）而没命中真实业务 dllhost，都会造成「看起来差一点」。第二组原因是实际发起者不是你的目标 GUI：安装器后台、杀毒更新通道、electron helper、沙箱网关进程会顶替名字，于是你在YAML里写 Spotify，列表里却总看到另一个小写随机名——这不是 find-mode 独享的问题，而是你抄错了要写进规则的那个字符串。
第三组原因在于TUN 栈对某些协议/metadata 不完整：例如 icmp、极少数仅内核态见过的控制面报文并不会天然带着「某一个用户双击的 exe」这种故事；再如某些远程桌面串流把流量打散到驱动层，你在面板截图里看见的进程可能固定为会话宿主。遇到这种「永远不像应用名」的连接，应考虑回落到DOMAIN / IP-CIDR / GEOIP 组合拳，而不要在一个错误维度上追加更多 PROCESS-*。
第四组原因在于模式设成了 off 却仍保留进程规则：此时规则条目「语法存在」但实际匹配阶段缺失字段——症状像随机直连/随机走默认组，看起来像「玄学命中」，本质是链路缺元数据。
5 Linux 与 Windows：权限、tun.stack 与同机观感
Linux headless systemd 场景请参考站内《Ubuntu 24 LTS Mihomo systemd 常驻》与 broader《Linux Mihomo systemd 实操》：它们解决的是二进制落位、Capability、开机顺序与日志落盘。tun fd 起不来表现为接口缺失或启动直接退出，而不会在你已经能翻墙的情况下才把进程名列随机清空——所以当你遇到「能上但进程不对劲」优先怀疑模式和规则抄写，遇到「上不了」才去翻特权与 nft 编排。
Windows 上常见组合是 MihomoParty / Clash Verge Rev / 其它壳 + Wintun：给一次管理员授权或装好驱动组件后，tun/stack 才能接住系统路由重写。此时 find-process-mode 依旧在用户态YAML里配置，区别在于你是否与UAC、安全软件钩子争用进程打开事件。若只允许「以服务身份」跑核心，可把 GUI 视作纯下发器——记得核对服务账户看到的世界与交互式会话是否同款。
移动端与容器中运行 Mihomo 时还经常出现：TUN 在，但宿主 PID 视图与业务进程不在同一 cgroup——那是另一个话题的超集（例如要在宿主机路由层完成进程追踪），本文不深展，只在读者心里埋一个锚：不是每一台设备安装包都能把桌面 Windows 的规则原封不动搬进 Termux Docker OpenWrt 三条线路。
6 放行、直连与本机局域网：规则和模式如何叠
当你想用 PROCESS-NAME,x,DIRECT 放行下载器、局域网数据库客户端或国内 IM，一条经验是把这类规则放在 GEOIP MATCH 洪流之前可读的位置，并使用连接面板确认的同名。若再配合 strict-route、局域网 bypass 等平台开关，要确保「没被 auto-route / 防火墙」另一条旁路送回代理——否则会看到「YAML 说它直连，tracert 却像绕地球」的矛盾体验。
「放行本地」若仅指127.0.0.0/8与 RFC1918——那是路由与 skip 的范畴；若是「放行某个 exe」——才轮到 find-process-mode x PROCESS-NAME。混在一起谈容易让新手误删整个进程匹配能力又抱怨规则无效。
7 验证：连接面板抄写、短时 always、与日志共读
上线改动的最小闭环：(1) 导出当前磁盘生效配置检索 find-process-mode；(2) 在单机只开一个目标应用制造流量，截取连接条目中的进程名列；(3) 校对 PROCESS-NAME 字面量是否与列一致（大小写在部分平台宽松，不要赌运气，直接照抄）；(4) 若仍异常，切换到 always 短窗口复检——若切换到 always 字段立刻对齐，则说明此前要么模式被设为 "off" / 等价误解析，要么是strict 路径与你的流量类型不匹配需要升级内核或改写非进程兜底；(5) 把日志级别抬到能观察策略命中的档位，复核是不是规则排序先被另一条 DOMAIN 抢走。
这套流程也和《Meta 内核 DNS 防泄漏配置》可以并行：`fake-ip + redir-host` 解决的是名字如何进内核；find-process-mode解决的是会话名字如何与用户态二进制对齐——二者叠在一起才让「谁在访问哪一个域名」在仪表盘上读来像因果关系而不是随机噪声。
8 常见问题（速查）
问：我只用域名分流也需要开进程匹配吗？ 不需要。除非你明确要使用 PROCESS-* 族规则或对进程上下文有观测诉求，可把 find-process-mode 保持在默认 strict 或按需"off"，而不是盲信「开总比关好」。
问：服务端代理（例如链路上还有一层 SOCKS 出口）会破坏进程视图吗？ Mihomo 自己当然知道本地哪个进程撞到入站——链条远端的服务器只看到上游隧道，与你的 PC 进程名没有关系；混淆往往来自多层客户端嵌套时要记得「看的是哪一个 tun 持有者」那一层。
问：能不能写「正则」匹配进程路径？ 请以你所用内核版本的文档支持的规则前缀为准；社区配方若用了扩展语法，请先对照官方 changelog，避免把整个规则段导入成silent no-op。
9 总结、竞品对照与自然下载引导
回顾一下：find-process-mode 是 Mihomo 在TUN 栈之上决定「要花多大力气挂载进程匹配元数据」的顶层开关：strict 适合大多数桌面长尾；always 用来做短时实测；"off" 则让你彻底断开进程能力与 PROCESS-NAME 的生态位。真正把规则写对的人，会先抄连接视图里的字面量再回到 YAML 排序，而不是在论坛背别人的 exe 文件名。
许多「纯一键」闭源壳要么把YAML细节藏进专有数据库，让你在升级后根本不知道进程匹配被静默关掉；要么在合并层反复触发 YAML 布尔误解析你却看不到差异 diff。开源路线里直接用 Clash Meta 文档字段说话，再配合图形界面做可视化 diff，才能把每一次「玄学命中」拉回到可追溯的配置变更上。
如果你希望继续用可视化方式驾驭 TUN、进程规则与健康检查面板，不妨试试围绕 Mihomo 活跃的 Clash Verge Rev：它把运行时连接、YAML 导出与内核版本切换放在同一工作台，尤其适合今天这种「短时改 always、再回看 strict」的试错节奏。觉得这类透明工具链更符合你的运维习惯的话，可从本站下载页选择合适的平台包，把这版 find-process-mode 的结论落在长期可维护的环境里。
