Clash 自定义规则怎么写：规则类型、自上而下匹配顺序与 MATCH 兜底

规则生效前提：规则模式、连接接管与配置落盘

Clash 自定义规则的任务，是为已经进入内核的连接选择出口。规则写得正确，不代表所有软件流量都会经过它：系统代理通常只影响遵循代理设置的应用；TUN 可以接管更多流量，但仍受路由、权限和排除项影响。排查时先在客户端的「连接」页面确认能看到目标请求，再检查命中的规则。

本文以 Clash 常见规则语法为基础，涉及进程识别时以 Clash Meta（mihomo）为主要参考。不同内核与系统支持范围不同，不能把某个客户端提供的编辑界面当成内核能力清单。先在客户端的内核信息或启动日志中确认实际运行的内核，再使用对应功能。

把运行模式切到「规则」，配置文件中对应 mode: rule。全局模式不会按这里的普通分流规则选择出口。
确认当前启用的是正在编辑的配置，而不是同名的另一份订阅。
备份原配置，在客户端提供的配置检查功能中验证 YAML，再重新加载。
关闭目标应用的旧连接并重新发起请求。已建立连接通常不会因为规则更新就自动换出口。

规则基础语法：类型、匹配内容与策略名称

多数规则写成 类型,匹配内容,策略，其中策略既可以是内置的 DIRECT、REJECT，也可以是配置中已经定义的代理节点或代理组名称。MATCH 不需要匹配内容，写作 MATCH,策略。规则字段使用英文逗号，整条规则作为 YAML 列表中的一个字符串。

规则类型	示例	匹配范围
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	精确匹配这个域名
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	根域名及其子域名
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,REJECT`	域名中包含指定字符串
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	目标 IPv4 地址属于此网段
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	目标 IPv6 地址属于此网段
`PROCESS-NAME`	`PROCESS-NAME,curl.exe,DIRECT`	识别到的进程名相符
`MATCH`	`MATCH,DIRECT`	接住前面没有匹配到的连接

代理组名称必须真实存在

PROXY 不是自动存在的“代理总开关”。如果配置没有名为 PROXY 的节点或组，引用它就可能在加载时出现找不到代理的错误。同样，节点选择 与 节点选择 2 是两个名称，不能只凭显示效果猜名字。

下面这段仅演示规则列表。它假定原配置已经定义了名为「节点选择」的代理组；不满足这个条件时，应改成现有策略名，而不是直接粘贴后等待自动生成。

rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,节点选择"
  - "MATCH,节点选择"

规则中的域名不带 https://，也不带路径和端口。希望只处理 https://example.com/docs 中的 /docs 路径，不能靠 DOMAIN 实现：这里做的是连接层分流，不是 HTTP 路径路由。

自上而下匹配：具体例外放前面，宽泛规则放后面

普通规则按列表顺序检查，首条命中就决定策略，不会继续向下寻找“更精确”的规则。系统不会自动把 DOMAIN 排到 DOMAIN-SUFFIX 前面，也不会根据网段长短自动重排。因此，顺序本身就是配置逻辑的一部分。

rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "MATCH,DIRECT"

api.example.com：第一条命中，走 DIRECT，不会再被第二条拒绝。
www.example.com：第一条不匹配，第二条命中，走 REJECT。
example.com：也会被第二条匹配，后缀规则包含根域名本身。
notexample.com：不属于 example.com 的域名层级，最终走第三条。

如果交换前两条，api.example.com 也会被拒绝。修复这种问题不需要增加重复规则，只要把例外移到宽泛规则之前。常见组织方式是：明确的业务例外、按需设置的局域网直连、分类规则集、地区 IP 规则，最后才是兜底。但这不是强制排序，业务例外是否高于局域网策略，应由实际需求决定。

关键词规则容易扩大命中范围

DOMAIN-KEYWORD,example 会匹配域名中的字符串，而不是域名层级；它可能覆盖 notexample.com。想给某个站点及子域名分流，通常先考虑 DOMAIN-SUFFIX。不要为了少写几行，就把短关键词规则摆到列表最前面，容易把原本不相关的服务一起带走。

IP-CIDR 与 no-resolve：限制主动解析，不是关闭 DNS

IP-CIDR 检查的是目标地址是否属于某个网段。请求携带域名时，内核可能需要先取得目标 IP，才能判断 IP 规则。为规则添加 no-resolve，表示不要为了评估这条规则而主动触发域名解析；它不是“跳过 IP 匹配”，更不是“这条连接永远不使用 DNS”。

rules:
  - "IP-CIDR,10.0.0.0/8,DIRECT,no-resolve"
  - "IP-CIDR,172.16.0.0/12,DIRECT,no-resolve"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "IP-CIDR6,fc00::/7,DIRECT,no-resolve"
  - "MATCH,DIRECT"

上面列出了三个常用 IPv4 私有网段与 IPv6 唯一本地地址范围，是局域网规则示例，不是完整的特殊用途地址清单。如果连接本来就是访问 192.168.1.1，目标 IP 已经明确，带 no-resolve 的规则仍然能够匹配。

域名访问与 IP 访问要分别验证

访问 192.168.1.1 能直连，不代表访问一个解析到该地址的域名也一定命中同一条规则。如果内核尚未掌握真实目标地址，no-resolve 会影响是否为 IP 规则主动解析。已经可用的目标 IP、DNS 缓存及 Fake-IP 映射等状态，也会影响实际判断，应以连接详情为准。

PROCESS-NAME：进程规则的权限与平台边界

进程规则适合“某个程序固定走一个出口”的需求。例如在 Windows 上，PROCESS-NAME,curl.exe,DIRECT 可以针对被内核识别为 curl.exe 的连接。名称要以连接详情中实际显示的进程名为准，不要使用桌面快捷方式名称或窗口标题代替。

确认系统支持：进程发现依赖内核、操作系统及运行权限。mihomo 中的 find-process-mode 会影响进程查找行为；若配置为 off，不能指望进程规则正常完成识别。
确认流量来源：路由器转发的另一台设备的流量，通常无法在路由器上得到远端应用的本地进程名。此时可考虑源地址规则，而不是强套进程名。
确认顺序：希望进程规则覆盖普通网站分流，就应放在相关域名规则之前；若只作为补充，则放在这些规则之后、MATCH 之前。
确认辅助进程：一个应用可能由多个进程联网。浏览器内核、更新器和主程序不一定显示同一个名称，需要逐条观察实际连接。

Android 客户端里的按应用代理或应用排除列表，往往属于 VPN 接管范围设置，不能直接等同于桌面平台的 PROCESS-NAME。流量若已被应用排除，就不会进入内核供普通规则匹配。

MATCH 兜底：最后一条决定未分类流量的去向

MATCH 不带域名或网段条件，会接住走到这里的连接。它应放在普通规则列表末尾；放到开头后，后面的普通规则就没有匹配机会。通常保留一条明确兜底即可，多写几条不会形成故障转移。

mode: rule
rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "MATCH,DIRECT"

这是一段仅使用内置策略的语法演示：指定域名拒绝，其他流量直连。它不是通用代理方案。如果需要未分类流量走代理，应把最后一行的 DIRECT 改为已有代理组名称，并确认该组当前选中了需要的出口。

兜底策略没有统一答案。默认代理能覆盖未归类的境外服务，但可能让本地服务绕路；默认直连可减少误代理，却需要为目标服务补充规则。先确定默认行为，再补例外，远比反复切换全局模式更容易定位问题。

验证与排错：从运行配置查到新连接

规则检修要留下一条完整证据链：配置是否加载、请求是否进入内核、命中哪条规则、最终使用哪个出口。只看网页是否打开，很难区分 DNS、规则与节点故障。

检查最终配置：确认只有一个预期的 rules: 顶层键，列表缩进一致，不使用 Tab。找到新增规则的实际位置，尤其检查它是否被追加在 MATCH 后面。
检查加载日志：若提示策略不存在，逐字核对代理组名称；若提示规则类型不支持，核对内核功能，不要靠调整缩进掩盖能力差异。
发起新请求：先关闭原连接，再访问测试目标。在「连接」中查看域名、目标 IP、规则类型和代理链。连接详情字段名称因客户端不同而异。
分离代理入口问题：使用显式代理请求，可以排除应用不遵循系统代理的因素；仍需确认监听端口确实属于当前内核。

curl -I --proxy http://127.0.0.1:7890 https://example.com

这里假设本机 HTTP 或混合代理端口为 7890。实际 mixed-port 如果是 7897，命令也必须同步修改。这个测试检查显式 HTTP 代理路径，不能单独证明 TUN 接管正常；在前面的拒绝示例中，访问该域名失败反而符合规则预期，应同时查看命中记录。

三个常见症状的处理顺序

规则保存了却没效果：先查当前配置和最终列表，再查运行模式，最后关闭旧连接重试。不要立即增加重复条目。
域名规则始终不命中：查看内核是否拿到了域名信息。仅有目标 IP、且没有可用域名映射或嗅探结果时，不能要求域名规则凭空识别站点。
命中代理组但出口不对：检查组内当前选择及代理链。规则决定交给哪个策略，代理组继续决定具体节点，两层都要查。

稳定的修改节奏是一次只改一类规则，加载检查后用新连接复测。精确规则在前、宽泛规则在后、MATCH 收尾，再配合可持久保存的覆写机制，才能避免订阅一更新就把刚修好的线路接回原样。