为什么要在 Windows 上按进程分流

很多用户并不想要「整台电脑所有流量都进代理」：办公时段希望浏览器与 IM 直连或走企业出口，游戏时段又希望启动器或某款网游走低延迟节点；开发机则可能只想让 git.exe、容器 CLI 走特定策略。纯域名/IP规则能覆盖绝大多数网站访问，但一旦多个场景混在同一浏览器里，域名维度就显得粗。此时在 Clash Meta（Mihomo） 里使用 PROCESS-NAME，把发起连接的进程（通常表现为 .exe 文件名）写进规则，就能与域名分流互补。开始前建议先扫一眼 Clash 规则分流最佳实践，弄清「从上到下匹配、命中即停」的总原则，再读本文的进程维度，避免两条体系互相打架。

与 Android 上系统级的「分应用代理」不同，Windows 桌面需要在内核能识别流量归属进程的前提下，PROCESS-NAME 才有稳定意义；实践中多数场景会配合 TUN 或等价的全局接管能力。概念上可先读 Clash TUN 模式深度解析，理解虚拟网卡如何把应用流量交给 Mihomo，再往下看具体规则写法。

前置：Mihomo、TUN 与桌面客户端

本文规则语法以 Mihomo（Clash Meta） 为准；请确认客户端已切换到 Meta 系内核，且订阅与基础策略能正常连通。若你刚装机，可按 Windows 11 上 Clash Verge Rev：订阅导入与 TUN 实测步骤 把安装、订阅与 TUN 开关跑通一遍，再叠加进程规则，排障会简单很多。仅依赖「系统代理」时，部分程序并不把流量交给 Clash，日志里也可能看不到完整进程信息，容易误判「规则没生效」。

若退出代理后浏览器「上不了网」、或 TUN 与其它软件冲突，可对照 退出 Clash 后无法上网：系统代理与 TUN 残留 清理系统代理与路由，避免在调试进程规则时被残留配置干扰。

ℹ 合规提示：请仅在你有权使用的网络环境与设备上配置代理与分流；本文仅作技术说明，不鼓励规避所在单位或服务商的合理网络策略。

PROCESS-NAME 规则怎么写

在 Mihomo 的 rules 中，一条进程规则通常形如：类型、进程名、策略或策略组名。Windows 上进程名一般写可执行文件名（含 .exe 后缀），例如 chrome.exe、steam.exe，大小写建议与任务管理器「详细信息」里一致。策略目标可以是 DIRECT、REJECT，或是你在 proxy-groups 里定义的策略组名称（如「游戏」「办公」）。下面是一段示意配置，仅演示结构；请把策略组名换成你订阅里真实存在的名称。 

rules:
  - PROCESS-NAME,steam.exe,GAME
  - PROCESS-NAME,LeagueClient.exe,DIRECT
  - PROCESS-NAME,Code.exe,OFFICE
  - DOMAIN-SUFFIX,steamstatic.com,GAME
  - MATCH,DEFAULT

第一列固定为 PROCESS-NAME；第二列是进程名；第三列是出口。若某程序会拉起子进程（更新器、反作弊、启动器），实际发起连接的可能不是你以为的那个 exe，需要以日志里的进程名为准，下文「实测」一节会写怎么核对。

规则顺序：谁先匹配谁生效

Mihomo 对 rules 自上而下只命中第一条符合条件的规则，这与 规则分流最佳实践 中的描述一致。把 PROCESS-NAME 放在太靠后时，可能已被前面的 DOMAIN-SUFFIX、GEOIP 抢走；放在太靠前时，又会覆盖你对某些域名的精细意图。常见做法是：先写更具体的进程规则，再写较宽的域名或 GEOIP，最后用 MATCH 兜底。

若你把延迟测速、故障转移交给策略组，可先读 Clash 策略组与延迟测速：url-test 和 fallback 实配步骤，保证进程规则指向的策略组本身可用，否则会出现「规则命中了，但策略组里全是超时节点」的现象。

⚠ 注意：不要在未看清顺序的情况下复制大段规则集。一次只加一两行 PROCESS-NAME，重载配置后用日志验证，比一次性合并多个来源的 YAML 更安全。

实测：从任务管理器到连接日志

第一步：在 Windows「任务管理器 → 详细信息」中找到目标程序的 .exe 名称，注意同一软件多开或32/64 位不同可执行文件时可能有两个名字。第二步：在配置中添加上述 PROCESS-NAME 行，保存并重载配置（图形客户端一般有「重载配置」或等价按钮）。第三步：打开客户端的连接日志或「最近连接」面板，只访问该程序相关的网络活动，观察每条连接旁是否出现你期望的进程名与策略命中结果。若进程名与任务管理器不一致，以日志为准改规则。

对游戏与 UDP，还可结合 Steam 与游戏 UDP：Clash TUN 分流实测，把传输层特性（UDP、端口）与进程规则一起考虑，避免只改进程却忽略协议。

若你在 WSL 里跑 Linux 程序、而希望 Windows 侧 Clash 统一分流，网络路径会更绕，可另读 WSL2 与 Windows 宿主机 Clash 代理，不要把 WSL 内进程名误当成 Windows 进程名来写规则。

常见坑：UWP、子进程与多开

Microsoft Store / UWP 应用常跑在应用容器里，任务管理器里的映像名称可能不直观，有时需要看「设置 → 应用 → 高级选项」或借助资源监视器确认实际进程。启动器与游戏本体可能是两个 exe：只给其中一个写 PROCESS-NAME 时，另一个仍可能走默认策略。浏览器所有标签共用同一进程名（如 chrome.exe），若要对「某个站点」细分，仍需回到域名规则，进程规则只能做到「整个浏览器进程」级别。

移动端「按应用」的体验可参考 Clash Meta for Android 分应用代理，与 Windows 的 PROCESS-NAME 思路相似，但系统接口不同，不要混用配置片段。

与域名分流、策略组配合

实际使用中，推荐「域名/IP 规则解决站点与地区，进程规则解决具体软件」：例如让某 IDE 或包管理器整体走代理，同时用域名规则把常见国内站点留在直连。策略组名称保持简短、可维护，并避免与订阅里自带的组名冲突。若团队内多人共用一份配置，建议在注释（英文）中标明每条进程规则的负责人与用途，方便后续删减。

相比全局开关，精细分流能减轻「一开代理全家桶都变慢」的体感；与纯域名方案相比，进程维度又能在同一浏览器无法拆开的场景下，把不同软件划到不同出口。把 Mihomo 升级到当前主线、保持 TUN 与规则可读可改，长期维护成本会远低于堆叠多个互不知情的第三方「加速器」。

结语

在 Windows 上用好 Clash Meta 的进程分流，核心是四件事：确认内核与 TUN 工作正常、用任务管理器与日志对齐 exe 名称、把 PROCESS-NAME 放在合理的规则顺序里、与域名规则及策略组配合而不是互相覆盖。做到这四点，你就可以让指定游戏、办公或开发工具走独立出口，而不必把整台机器绑在「全局代理」上。

相比在论坛里搜零散字段，按上述顺序自测一遍，大部分「写了却不生效」的问题都能定位到顺序、进程名或 TUN 未接管。客户端安装与更新仍建议以本站 下载页 为主入口，避免误装停更版本。

→ 立即免费下载 Clash，开启流畅上网新体验，在 Windows 上配合 Meta 内核与图形客户端完成进程级分流与日志核对，把「只代理几款软件」真正落到实处。