有时候分流的依据不是「访问哪个域名」,而是「哪个程序在访问」。比如:只让某个开发工具走代理,或者禁止 BT 客户端走代理。
这就要用进程规则。
前置条件:开启 find-process-mode
这是最常见的「规则写了不生效」的原因。
find-process-mode: strict三种取值:
| 值 | 行为 | 开销 |
|---|---|---|
off | 完全不查进程,进程规则全部失效 | 无 |
strict(推荐) | 只在有进程规则时才查 | 低 |
always | 每个连接都查,日志里能看到进程名 | 较高 |
设成 always 的好处是连接页的「进程」列始终有数据,排查时很方便;代价是每个连接都要查一次系统进程表。
基本写法
rules:
- PROCESS-NAME,Telegram.exe,🚀 节点选择
- PROCESS-NAME,qbittorrent.exe,DIRECT
- PROCESS-PATH,/usr/local/bin/curl,🚀 节点选择PROCESS-NAME vs PROCESS-PATH
Mihomo 还支持 PROCESS-NAME-REGEX 和 PROCESS-PATH-REGEX:
- PROCESS-NAME-REGEX,(?i)^(chrome|msedge)\.exe$,🚀 节点选择
- PROCESS-PATH-REGEX,(?i).*\\JetBrains\\.*,🚀 节点选择怎么查进程名
方法一:连接页直接看(最快)
把 find-process-mode 设成 always,打开 Clash Verge 的 连接 页,让那个程序联一次网,「进程」列里显示的就是准确的进程名。
这是最可靠的方法——不用猜,直接抄。
方法二:任务管理器 / 活动监视器
Windows:任务管理器 → 详细信息标签页,「名称」列就是进程名。
macOS:活动监视器 → 双击进程 → 看「进程名称」。
Linux:ps -e -o comm= 列出所有进程名。
方法三:命令行
# Windows:列出所有正在联网的进程
Get-NetTCPConnection -State Established |
Select-Object -Property OwningProcess -Unique |
ForEach-Object { (Get-Process -Id $_.OwningProcess).ProcessName }# macOS / Linux
lsof -i -P -n | awk '{print $1}' | sort -u实用场景
一、BT / PT 客户端强制直连
很多订阅服务的条款禁止 BT 流量,走代理可能导致封号。同时 BT 走代理也确实浪费流量。
prepend-rules:
- PROCESS-NAME,qbittorrent.exe,DIRECT
- PROCESS-NAME,Transmission.exe,DIRECT
- PROCESS-NAME,aria2c.exe,DIRECT
- PROCESS-NAME,BitComet.exe,DIRECT
- PROCESS-NAME,uTorrent.exe,DIRECT
- PROCESS-NAME,deluge.exe,DIRECT配合端口规则双保险:
- DST-PORT,6881-6889,DIRECT二、开发工具走代理
prepend-rules:
- PROCESS-NAME,git.exe,🚀 节点选择
- PROCESS-NAME,node.exe,🚀 节点选择
- PROCESS-NAME,python.exe,🚀 节点选择
- PROCESS-NAME,docker.exe,🚀 节点选择
- PROCESS-NAME,go.exe,🚀 节点选择三、游戏平台走特定节点
prepend-proxy-groups:
- name: "🎮 游戏"
type: fallback
include-all: true
filter: "(?i)IPLC|专线|游戏|game"
interval: 300
prepend-rules:
- PROCESS-NAME,steam.exe,🎮 游戏
- PROCESS-NAME,Battle.net.exe,🎮 游戏
- PROCESS-NAME,EpicGamesLauncher.exe,🎮 游戏四、国内软件强制直连
某些国产软件走代理会出问题(地区限制、风控):
prepend-rules:
- PROCESS-NAME,WeChat.exe,DIRECT
- PROCESS-NAME,DingTalk.exe,DIRECT
- PROCESS-NAME,QQ.exe,DIRECT
- PROCESS-NAME,cloudmusic.exe,DIRECT
- PROCESS-NAME,BaiduNetdisk.exe,DIRECT五、和其他条件组合
只有某个程序访问某个网段时才走代理:
- AND,((PROCESS-NAME,Telegram.exe),(IP-CIDR,91.108.4.0/22)),🚀 节点选择某个程序访问境外时走代理,访问国内直连:
- AND,((PROCESS-NAME,chrome.exe),(GEOIP,CN)),DIRECT
- PROCESS-NAME,chrome.exe,🚀 节点选择注意顺序:更具体的组合规则要放在单一规则前面。
性能考量
进程规则比域名规则贵得多。每次匹配都要:
优化建议:
各平台的支持情况
| 平台 | 支持 | 备注 |
|---|---|---|
| Windows | ✅ 完整 | 需要 exe 名,注意大小写 |
| macOS | ✅ 完整 | 可能需要额外权限 |
| Linux | ✅ 完整 | 需要读 /proc 权限 |
| Android | ⚠️ 部分 | 用「分应用代理」更合适 |
| 软路由/网关 | ❌ | 流量来自其他设备,无本机进程 |
Android 上不要用进程规则——CMFA 和 FlClash 都提供了图形化的「分应用代理」,按包名选择,比写规则准确也省事。
排查:规则不生效
最快的验证方法:把 find-process-mode 设成 always,打开连接页,让程序联网,看「进程」列。
- 列是空的 → 内核查不到进程,检查权限
- 列有值但和你写的规则不一致 → 照着列里显示的改规则
- 列有值且一致,但「规则」列显示命中了别的规则 → 规则顺序问题,用
prepend-rules提前
小结
find-process-mode: strict是前置条件,不开一切白搭- 进程名从连接页抄,别靠猜
- 系统代理模式下命令行工具的流量到不了内核,进程规则只在 TUN 下对它们有效
- 网关场景用 SRC-IP-CIDR,进程规则在那里无效
- 进程规则开销较大,放靠后位置,能用域名规则就别用它
相关文档
十几种规则类型的语法、匹配逻辑与性能开销对照表,讲清楚 no-resolve 的作用、规则顺序为什么决定一切,以及怎么用连接页反查命中了哪条规则。
用外部规则集替代几百条手写规则。讲清楚 domain/ipcidr/classical 三种 behavior 的差异、text 与 yaml 格式、更新间隔怎么设,以及规则集不生效时怎么查。