搜索意图：进程级规则解决的是什么
域名级规则擅长处理「访问某个网站一律走某策略组」；但当同一台机器上多个应用并行联网、而你只想让其中少数几个走代理时，仅靠 DOMAIN-SUFFIX 往往不够精细，尤其遇到同一浏览器里既有国内后台又有海外前台、或游戏启动器与反作弊模块拆分进程的情况。反过来，有些桌面软件硬编码直连、不读取系统代理，系统设置里「HTTP 代理」对它形同虚设；这时若你已启用 TUN 或等价的全局捕获，让流量先进内核，再由 PROCESS-NAME 把该进程单独导向代理策略组，通常比反复改 hosts 或全局「开全局」更干净。
本文默认你使用的是基于 Meta 内核的图形客户端或自托管 Mihomo，并已能正常导入订阅与策略组。若尚未完成基础安装，可先对照 Windows 安装与订阅导入 与 macOS 上系统代理与钥匙串排查 把客户端跑稳，再回到进程规则，以免把「起不来」与「规则不命中」混为一谈。
与域名规则的关系：互补而非替代
PROCESS-NAME 与 DOMAIN / GEOIP 等规则处在同一条 rules 链路上，仍然遵循自上而下首次命中。实务上常见组合是：先用进程规则把「明确要代理或明确要直连」的应用钉死，再用域名与国内 IP 规则处理剩余流量。不要把进程规则当成「可以不管 DNS」的银弹：若 DNS 与 FakeIP 路径和规则决策不一致，仍会出现「日志里进程对了、解析却跑偏」的现象，这时需要回到 Meta 内核 DNS 防泄漏指南 对齐解析链。
与「全局模式」相比，进程级方案的目标不是把所有流量一把梭到代理，而是在规则模式下尽量收窄代理面，降低无关业务经隧道的合规与稳定性风险。与仅开 mixed-port 让应用手动填本地端口相比，进程规则通常依赖客户端能拿到五元组之外的进程元数据，因此与是否启用 TUN、以及操作系统上流量如何被重定向进内核密切相关。
前置条件：TUN、权限与「能看见进程」
在 Windows 与 macOS 上，图形客户端若已按文档开启 TUN 模式，连接日志里往往能看到进程名或路径字段，这才是写 PROCESS-NAME 的可靠依据。请不要凭印象手写 chrome.exe 大小写或带空格的可执行名而不核对日志：不同渠道安装的浏览器、游戏平台（如独立启动器与主程序）可能对应不同进程名。若你暂时不能开 TUN，仅依赖系统代理端口，部分应用流量可能根本不会经过内核，进程规则自然永远不会命中。
TUN 的驱动、权限与与其它虚拟网卡软件的冲突，在 Clash Verge Rev TUN 模式完整指南 中已有逐步说明；本文只强调与进程规则强相关的结论：先确认日志里已经出现进程字段，再写规则。企业环境若禁止内核扩展或过滤驱动，请先评估政策，不要为绕过限制而硬开高风险配置。
提示：在 WSL2 里跑的 Linux 进程，从 Windows 宿主视角看网络路径与纯 Win32 应用不同；若你要为开发工具链分流，请同时阅读 WSL2 与 Windows Clash 代理，避免把「宿主机进程规则」误套在子系统流量上。
1规则类型速览：PROCESS-NAME 与路径类
Meta 系规则中，与「谁发起的连接」直接相关的常见类型包括：PROCESS-NAME（可执行文件名）、PROCESS-PATH（完整路径，精确匹配）以及带关键词或通配的路径匹配变体（具体关键字以你当前内核版本文档为准）。对大多数用户，PROCESS-NAME 最简单：在 Windows 上多为 xxx.exe，在 macOS 上常见为无后缀的 Chrome、Steam 等，但仍以客户端连接面板或日志字符串为准，而不是任务管理器里看到的「标题」。
路径类规则适合同一可执行名多实例、或需要限定到某个安装目录的场景；代价是 YAML 更长、对升级路径更敏感。无论哪种类型，右侧第三个字段必须是配置里已存在的策略组名或内置策略（如 DIRECT、REJECT），拼写与大小写需与 proxy-groups 中定义完全一致，否则内核会直接报错拒绝加载。
2逐步配置：策略组命名与 rules 顺序
建议先固定两个策略组语义：一个用于「仅少数应用走代理」（下文示例称 SELECT_PROXY），以及一个用于默认直连（可直接用内置 DIRECT，或自建 FINAL_DIRECT 以便日后扩展）。进程相关条目应放在足够靠前的位置，避免被宽泛的 GEOIP,CN,DIRECT 或远程规则集里的通配条目提前吃掉。与此同时，不要把 MATCH 随意提前：它一旦命中就会终结整条规则链。
下面是一段骨架示意，其中的策略组名、进程名与顺序请按你的订阅与日志改写；注释仅用于说明字段含义。
# Skeleton — replace group names and process identifiers using YOUR client logs
proxy-groups:
- name: SELECT_PROXY
type: select
proxies:
- NODE_A
- NODE_B
- DIRECT
rules:
# Put process rules BEFORE broad GEOIP / provider rules that might win earlier
- PROCESS-NAME,chrome.exe,SELECT_PROXY
- PROCESS-NAME,Steam.exe,SELECT_PROXY
- PROCESS-NAME,Google Chrome,SELECT_PROXY
- GEOIP,CN,DIRECT
- MATCH,SELECT_PROXY
若你希望「默认直连、仅列出进程走代理」，可把 MATCH 指向 DIRECT，并确保所有需要代理的进程都写在 MATCH 之前；若相反希望「默认走代理、仅列出国内或信任软件直连」，则把进程直连规则放在前部、MATCH 指向代理组。两种模式没有绝对优劣，关键是与团队或个人的合规预期一致，并能从日志验证。
3Windows：exe 名、大小写与服务子进程
在 Windows 上，绝大多数用户级应用都会以 .exe 结尾出现在日志中。常见误区是把安装目录里的快捷方式名当成进程名，或忽略游戏反作弊、启动器拉起的子进程：实际对外连接可能由 GameClient.exe 发起，也可能由 Launcher.exe 或更新模块发起。若你只给其中一个写了 PROCESS-NAME，就会表现为「主界面能玩、下载补丁却直连失败」等割裂现象。排错时应对照一次完整启动周期内的连接日志，把出现的多个 .exe 逐一评估是否需要纳入同一策略组。
关于大小写：Windows 文件系统对大小写不敏感，但 YAML 中的规则仍建议与日志中字符串逐字一致，避免在不同客户端移植时踩到大小写敏感环境。若日志里出现带路径的字段而文件名不足以区分，可改用 PROCESS-PATH 精确到安装根目录。对来自 Microsoft Store 的 UWP 应用，进程模型更复杂，可结合 UWP 与 Loopback 相关排查 理解流量如何离开沙箱。
4macOS：Bundle 路径、签名与多副本
在 macOS 上，图形应用通常位于 /Applications/….app/Contents/MacOS/ 下的可执行文件；同一浏览器若存在多个渠道安装（官网 dmg、企业包、测试通道），路径可能不同，因此不要复制网上一条路径就当永久真理。更稳妥的流程是：在问题复现时打开连接详情，复制日志给出的进程名或路径，再粘贴进规则；版本升级后若路径变化，记得同步更新 YAML 或使用更宽松的匹配方式（在确认副作用可控的前提下）。
macOS 对内核扩展与网络扩展有额外授权步骤；若系统代理已开但进程规则不生效，先排除 钥匙串、Helper 与网络扩展 是否拦截了客户端行为，再判断是否为「未开 TUN 导致流量未进内核」而非规则语法错误。
5常见踩坑清单
- 规则顺序： 进程规则写在过低的位置，被
GEOIP或远程集里的宽泛条目抢先匹配。 - 策略组名写错： 与
proxy-groups不一致导致配置无法加载，或静默回退到默认（视客户端校验严格程度而定）。 - 只开系统代理不开 TUN： 目标进程流量未进入内核，进程元数据缺失，规则永远不触发。
- 子进程遗漏： 游戏、安装器、云同步组件多进程并行，只匹配主程序名不够。
- 与 DNS 打架： FakeIP、DoH 与规则链不对齐时，表现为「命中了进程规则但仍访问异常」，需回到 DNS 文系统排查。
排查顺序建议
建议固定顺序以减少无效折腾：① 在客户端连接日志中确认目标连接是否带有进程字段；若没有，先回到 TUN / 权限。② 核对命中的第一条 rules 是否真的是你写的 PROCESS-NAME，而不是更靠前的其它类型规则。③ 若命中正确但访问仍异常，再检查策略组当前节点、UDP/QUIC 与 DNS 是否与 DNS 指南 一致。多数「规则写了像没写」的现象落在前两步。
若你希望把进程规则与远程规则集长期共存，推荐把「个人进程覆写」放在单独文件里，通过 rule-providers 或客户端的「本地覆写 / Merge」机制注入，避免手工改巨型 YAML 时合并冲突；规则集维护思路也可对照 ACL4SSR 与 Loyalsoldier 对比 选型。
合规提醒：请仅在法律与网络使用政策允许的范围内使用代理与加密隧道；企业或校园网络可能禁止擅自绕行，请遵守当地规定。
关于下载：开源内核与客户端的源码、变更记录可在 GitHub 查阅；日常获取安装包请优先使用 本站下载页，与仓库 Release 页面区分使用场景。
小结
Clash Meta / Mihomo 下的 PROCESS-NAME 与路径类规则，解决的是「同一台机器里，不同软件应有不同出口」的细粒度诉求：先把能看见进程的链路跑通（通常配合 TUN），再按日志填写名称或路径，并把相关规则放在不会被宽泛条目抢先的顺序上，最后与 DNS、策略组选路一起验收。相比「全局 / 规则模式」二选一的粗放切换，进程级写法更贴近真实桌面使用习惯，也更利于把代理面控制在真正需要的应用上。
相比在多个单点工具之间来回改系统设置，在同一套 Meta 内核客户端里维护订阅、覆写与进程规则，长期可维护性通常更好；当你把本文与站内 TUN、DNS、Windows / macOS 客户端教程串联阅读后，多数「只有某个软件不听话」的问题都能收敛到具体一层，而不是停留在模糊的网络故障描述上。