一、PROCESS-NAME 到底在匹配什么
在 Mihomo 文档语义下，PROCESS-NAME 一类规则依赖内核在发起连接时拿到的本机进程标识：常见实现里，这是可执行文件路径或文件名（取决于规则写法与内核版本），而不是窗口标题、也不是远程服务器的进程名。若你心里的「进程名」是任务管理器里看到的简短名字，而规则里写成了带盘符的整段路径，或反之只写了 app.exe 但实际连接来自 Update.exe 子进程，就会出现策略永远不命中的错觉。
因此排查的第一步永远是：用资源管理器或任务管理器记下真实映像路径，再用同一台机器上「当前生效的」配置对照——订阅合并、Profile 多文件、GUI 的「覆写」都可能让编辑器里看到的内容与实际运行内核加载的 rules 不一致。若客户端支持查看最终合并后的规则列表或导出运行配置，优先以那份为准。
二、常见表现：为什么像「规则没写」
典型的用户描述包括：浏览器里按域名分流正常，唯独某桌面软件始终直连；或策略组明明选了代理节点，日志里该会话仍是 DIRECT。这类现象往往被误认为是「节点坏了」，但若 PROCESS-NAME 根本没匹配上，后续策略组再漂亮也不会被引用。
另一类困惑来自混淆规则类型：有的用户把进程写在 script、自定义规则集或仅 GUI 的「应用规则」里，却期待与顶栏 rules: 行为完全一致——不同客户端对「应用级」与「内核 rules」的注入顺序并不相同。必要时请回到 官方与站内文档，确认你所在客户端将进程规则送进了内核最终参与匹配的那一层。
三、路径与大小写：只写 exe 还是全路径
仅文件名与完整路径的差异
在 Windows 上，很多示例只写 chrome.exe 或 game.exe，这在「匹配逻辑按仅文件名比较」时够用；若你拷贝了带盘符、带空格的路径，却多写了引号或混用了正斜杠，或路径层级与真实安装位置不一致（例如微软商店版应用装在 WindowsApps 受保护目录），规则就会静默失败。建议做法：从任务管理器「打开文件所在位置」复制路径，先尝试与教程一致的短文件名形式，再尝试规范化后的全路径（注意反斜杠在 YAML 中是否需要转义）。
YAML 片段示意（请替换组名与路径）
# Example — adjust proxy group names and paths for your environment
rules:
- PROCESS-NAME,AnyDesk.exe,PROXY_GROUP
- PROCESS-NAME,"C:\Program Files\App\client.exe",PROXY_GROUP
- GEOIP,CN,DIRECT
- MATCH,DEFAULT_GROUP部分版本对大小写敏感与否取决于实现；Windows 文件系统通常不区分大小写，但规则字符串若区分大小写，仍建议与磁盘上实际拼写保持一致，避免跨平台配置习惯带来的隐性差异。
四、权限与运行方式：管理员、服务与沙盒
PROCESS-NAME 需要内核或助手进程观察到「是谁发起了连接」。若 Clash 主体以普通用户运行，而目标程序以管理员权限提升运行，在部分系统上会出现进程信息不完整或无法关联的情况，表现为规则随机失效或始终不命中。反过来，若托盘里的 GUI 能拉起内核，但你用计划任务在 SYSTEM 账户下跑另一份核心，二者看到的进程命名空间也不一致。
建议排查顺序：将客户端与目标软件放在同一运行上下文下测试——例如都「以管理员身份运行」或都保持标准用户，并关闭一轮测试中的沙盒、容器化启动器。企业环境里若安全软件注入驱动拦截 API，也可能让进程名字段异常；这类问题超出应用层配置范畴，需要与安全策略协同处理。
五、接管栈：TUN、系统代理与「看不见进程」
仅有系统代理（HTTP/SOCKS）时，许多 Win32 程序根本不读系统代理，而是直接出局；此时流量可能不会以你想象的方式进入 Clash，自然也就谈不上 PROCESS-NAME。相对地，TUN 模式从路由层接管，更可能让「不感知代理」的应用也进入内核——但 TUN 会触动路由表与防火墙，需按 专文 逐步验证。
若你「开了 TUN 仍不走进程规则」，接着要核对：WFP 驱动是否加载成功、是否有绕过列表把目标网段直接 DIRECT，以及客户端是否把本机回环或局域网排除在捕获之外——这些都会让日志里的最后一跳与 GUI 观感不一致。
六、规则顺序与策略组：别被 MATCH 截胡
Clash 系规则通常是自上而下第一个命中即停止。若靠前已有 GEOIP,CN,DIRECT、大段 DOMAIN-SUFFIX 或订阅自带的「全量直连 / 全量代理」兜底，你的 PROCESS-NAME 可能永远执行不到。解决思路只有两种：把进程规则移到更靠前，或放宽/收窄前序规则，使其不要抢走目标流量。
另一点是策略组引用是否有效：规则里写的第三个字段必须是已存在的 policy 名；若拼写与 proxy-groups 不一致，有的内核会回落到默认行为，看起来像「规则无效」。用连接日志确认每条记录最终落在哪个策略、对应哪条规则编号（若客户端展示），比反复改 YAML 更高效。
七、子进程、启动器与自动更新
游戏平台、IM 与创意软件常见的结构是：启动器 Launcher.exe 拉起主程序 App.exe，更新模块又是第三个进程。你只对启动器写了 PROCESS-NAME，实际联网却是主程序进程，自然不会命中。类似地，Electron 应用往往是 App.exe 外壳包一层 …\App\app-版本\… 深层路径，任务管理器默认折叠了完整路径，需要展开核对。
实操建议：在产生问题连接的瞬间，用任务管理器「详细信息」排序 CPU 或网络，锁定哪一个 PID 在对外 connect，把该 PID 对应映像写入规则；必要时用客户端自带的「按进程抓连接」视图交叉验证。
八、快查表与建议操作顺序
| 现象或疑问 | 优先核对 |
|---|---|
| 域名规则正常，进程规则永远 DIRECT | 真实映像名 / 路径、子进程；规则是否排在更泛化规则之后；内核是否加载了含该条的配置 |
| 仅特定软件不命中 | 该软件是否读系统代理；是否需 TUN；是否有管理员权限落差 |
| 时而生效时而不生效 | 自动更新换了路径；多副本安装；UAC 提升与否；多个 Clash 实例 |
| 开了 TUN 仍异常 | 路由 / 防火墙；绕过列表；与《TUN 排障》对照 |
推荐操作顺序：确认最终配置已重载 → 用日志锁定进程映像 → 调整路径写法与规则序位 → 统一权限与运行方式 → 再决定系统代理 / TUN。保持一次只改一个变量，否则复盘困难。
九、小结
PROCESS-NAME 是 Windows 上极实用的进程级分流手段，但它不是「写了就一定生效」的魔法条——必须与真实进程路径、运行权限、规则顺序和流量接管模式对齐。相比只堆域名列表，它更适合那些主机名多变、或 P2P / 长尾连接密集的程序；但若跳过日志核对，很容易在路径或子进程上栽跟头。把本文与 Steam、Discord 等场景文一起读，可以在不重复的前提下补全 UDP、NAT 与游戏侧细节。
在需要长期维护一套可读规则与稳定内核的用户场景中，Clash 生态仍提供从 Mihomo 到多款 GUI 的一致路径。若你尚未安装或希望统一入口获取客户端与教程，可从本站开始部署，再按本文步骤逐项验证进程规则是否真正命中。