Clash 自定义规则语法详解：匹配类型、排列顺序与优先级

Clash 规则匹配模型

Clash 的规则系统用于回答一个具体问题：当前连接应交给哪个策略组、代理节点或内置动作处理。连接进入内核后，规则会按照配置文件中出现的顺序从上到下检查；第一条满足条件的规则立即生效，后面的规则不再参与本次连接。它不是把所有匹配结果汇总后再比较“精确度”，也不会自动让域名规则高于 IP 规则。

一条常见规则由规则类型、匹配内容和目标策略三部分构成，各字段使用英文逗号分隔。例如：

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Final

DOMAIN、DOMAIN-SUFFIX 和 IP-CIDR 是规则类型；域名或网段是匹配内容；DIRECT、Proxy 与 Final 是处理目标。目标名称必须与配置中的代理组名称完全一致，包括大小写、空格和符号。DIRECT 表示直接连接，REJECT 表示拒绝连接，代理组名称则表示让该组决定最终使用的节点。

规则一般处理连接的元数据，例如目标域名、目标 IP、端口、网络类型和发起进程。它不会读取网页正文来判断网站类别。若一个应用在同一页面中访问多个域名，主页面、图片、视频、接口和统计请求可能分别命中不同规则，因此判断规则是否生效时要查看具体连接，而不能只看地址栏中的主域名。

域名匹配语法：精确、后缀与关键字

DOMAIN：只匹配完整域名

DOMAIN 适合处理一个明确的主机名。以下规则会匹配 api.example.com，但不会匹配 www.example.com、v2.api.example.com 或其他子域名：

- DOMAIN,api.example.com,Proxy

当某个接口必须单独分流，而同一主域名下的其他服务需要保持原策略时，精确域名规则最合适。实际连接中的域名比较通常不区分字母大小写，但建议统一写成小写，便于审阅、搜索和去重。

DOMAIN-SUFFIX：匹配主域及其子域

DOMAIN-SUFFIX 是自定义规则中使用频率较高的类型。下面的规则可以覆盖 example.com、www.example.com 和 cdn.media.example.com：

- DOMAIN-SUFFIX,example.com,Proxy

后缀值通常直接填写域名，不必在前面增加点号或通配符。写成 *.example.com 可能无法得到预期结果，因为规则类型本身已经表达了后缀匹配逻辑。需要排除某个子域时，应把例外规则放在通用后缀规则之前：

- DOMAIN,internal.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,Proxy

DOMAIN-KEYWORD：匹配域名中的片段

DOMAIN-KEYWORD 会检查域名中是否包含指定文本。例如 DOMAIN-KEYWORD,example,Proxy 不仅可能匹配 example.com，也可能匹配 example-cdn.net 和 notexample.org。它覆盖面较宽，适合域名结构频繁变化但具有稳定命名片段的服务，不适合用来替代所有后缀规则。

关键字越短，误匹配概率越高。调试时如果发现无关网站走了代理，应优先检查靠前的 DOMAIN-KEYWORD 规则。对于已经知道完整主域的场景，应优先使用 DOMAIN 或 DOMAIN-SUFFIX。

GEOSITE：按域名分类集合匹配

Clash Meta，也就是目前常见的 mihomo 内核，支持通过 GEOSITE 使用预先整理的域名分类数据。例如：

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT

GEOSITE 的可用分类取决于客户端附带或下载的 GeoSite 数据文件。分类名称不存在、数据库没有更新或客户端使用的内核不支持该规则时，配置可能报错或无法按预期匹配。因此，从其他配置复制规则前，应先确认当前客户端内核类型和数据文件来源。

IP、端口与网络类型规则

IP-CIDR 与 IP-CIDR6

IP-CIDR 使用 CIDR 网段匹配 IPv4 目标地址，IP-CIDR6 用于 IPv6。斜杠后的数字表示网络前缀长度。单个 IPv4 地址可写成 /32，单个 IPv6 地址可写成 /128：

- IP-CIDR,203.0.113.8/32,Proxy,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR6,2001:db8::/32,Proxy,no-resolve

当连接最初提供的是域名时，部分 IP 类规则可能触发域名解析，以便取得目标 IP 后继续判断。规则末尾的 no-resolve 表示不要为了检查这条 IP 规则而额外解析域名。局域网保留地址、已知服务器地址等不需要域名补充解析的规则，通常可以添加该参数，减少不必要的 DNS 查询。

no-resolve 不代表关闭整个 Clash 的 DNS 功能，也不会阻止应用自身产生 DNS 请求。它只影响当前规则在匹配过程中是否主动把域名解析为 IP。若规则依赖解析后的地址范围，就不应机械地添加此参数。

GEOIP：按 IP 数据库分类

GEOIP 根据目标 IP 在地理数据库中的分类进行匹配，常见写法是：

- GEOIP,CN,DIRECT,no-resolve

这类规则的结果取决于 GeoIP 或 GeoData 数据库内容。IP 地址归属会变化，云服务和内容分发网络也可能跨地区调度，因此 GEOIP 更适合作为接近末尾的范围规则，而不是覆盖所有精确域名例外。需要固定处理方式的服务，应把明确的域名或 IP 规则放在它前面。

端口与协议

mihomo 支持通过 DST-PORT、SRC-PORT 和 NETWORK 等类型进一步限制连接。目标端口规则适合处理服务端端口，源端口则针对本机连接使用的端口。网络类型通常写为 tcp 或 udp：

- DST-PORT,22,SSH
- DST-PORT,3478-3481,Realtime
- NETWORK,udp,UDP-Policy

仅按端口分流容易影响其他使用相同端口的程序。例如 HTTPS 普遍使用 443 端口，把全部 443 流量交给某个固定策略通常过于宽泛。更稳妥的方式是结合域名、进程或逻辑规则缩小范围，并在修改后观察连接列表。

进程规则与逻辑组合

PROCESS-NAME 与 PROCESS-PATH

PROCESS-NAME 按发起连接的可执行文件名称匹配，适合让某个应用整体使用特定策略。例如 Windows 程序名通常包含扩展名：

- PROCESS-NAME,example.exe,Application-Proxy
- PROCESS-NAME,curl,DIRECT

PROCESS-PATH 可以匹配完整程序路径，在同名可执行文件较多时更精确。不过，路径写法受操作系统和内核实现影响，Windows 路径中的反斜杠、空格与 YAML 引号都需要正确处理。应用升级后安装目录改变，也可能导致旧路径规则失效。

进程识别能力与平台、运行权限和流量接管方式有关。某些系统只能在特定权限下取得进程信息，部分转发链路也可能无法还原原始进程。出现进程规则不生效时，应先在客户端连接详情中确认是否显示进程名称，而不是反复调整规则文字。

AND、OR 与 NOT

mihomo 支持逻辑规则，可组合多个条件。例如只让某个应用访问特定域名时使用代理：

- AND,((PROCESS-NAME,example.exe),(DOMAIN-SUFFIX,example.com)),Proxy
- OR,((DST-PORT,80),(DST-PORT,443)),Web
- NOT,((NETWORK,udp)),TCP-Policy

逻辑规则适合表达明确的交集、并集和排除条件，但嵌套括号较多时维护成本会迅速上升。不同内核版本对逻辑规则及子规则类型的支持范围可能不同。保存后若客户端提示解析失败，应对照当前 mihomo 文档检查括号、逗号和支持的规则类型。

排列顺序与规则优先级

Clash 的核心优先级原则是“先匹配先停止”。规则类型本身没有统一的隐藏权重。即使后面存在更精确的 DOMAIN，只要前面的 DOMAIN-SUFFIX、GEOSITE 或其他宽范围规则已经命中，后面的精确规则就不会执行。

实用的排列方法是把例外放在前面、范围规则放在中间、兜底放在最后：

1. 局域网地址、内部域名和必须直连的例外。
2. 需要固定代理或固定拒绝的精确域名。
3. 特定应用、端口及逻辑组合规则。
4. 域名后缀、规则集、GEOSITE 与 GEOIP 等范围规则。
5. MATCH 兜底规则。

rules:
  - DOMAIN,login.internal.example,DIRECT
  - DOMAIN,api.example.com,Service-Proxy
  - PROCESS-NAME,example.exe,Application-Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

在这段配置中，api.example.com 会先命中精确域名规则，不会落到后面的 example.com 后缀规则。其他属于该后缀的域名会交给 Proxy。未被前面任何规则处理的连接最终交给 Final。

MATCH 是无条件兜底，应放在规则列表最后。部分旧配置会使用 FINAL 表达类似目的，但实际支持情况取决于内核。对于 mihomo 配置，优先按照当前内核文档使用 MATCH。如果把兜底规则放在中间，其后的规则将永远没有匹配机会。

规则目标指向代理组时，规则只决定“进入哪个组”，节点选择仍由代理组类型决定。例如手动选择组会采用用户当前选择的节点，自动测速组会根据组内测试结果选择。排查线路时，需要区分“规则命中了错误的组”和“组内选中了不合适的节点”这两个问题。

订阅规则覆盖与持久化修改

订阅配置通常由服务端生成。直接在客户端编辑订阅展开后的 YAML，短时间内可以生效，但下一次更新订阅时，这些改动可能被新配置替换。需要长期保留的自定义规则，应使用客户端提供的覆写、配置合并、扩展脚本或本地配置功能。

不同客户端对合并功能的命名不同，但目标通常分为三类：

• 前置规则：插入订阅规则列表开头，适合添加高优先级例外。
• 后置规则：追加到列表末尾，但如果订阅已经包含 MATCH，追加内容可能永远无法命中。
• 整体替换：用自定义列表替换订阅中的全部规则，需要自行保留必要的局域网、DNS、直连和兜底逻辑。

因此，“追加一条规则”不一定等于“提高优先级”。如果目标是覆盖订阅已有结果，新规则必须出现在相关宽范围规则和最终兜底之前。使用图形客户端时，应查看合并后的实际配置或运行配置，而不只看覆写编辑框中的顺序。

RULE-SET 与 rule-providers

当规则数量较多时，可以通过 rule-providers 引用规则集，再在主规则列表中使用 RULE-SET。规则提供器负责载入规则内容，RULE-SET 出现在主列表中的位置仍决定它的优先级：

rule-providers:
  private-services:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-services.yaml
    url: https://rules.example.com/private-services.yaml
    interval: 86400

rules:
  - DOMAIN,exception.example.com,DIRECT
  - RULE-SET,private-services,Proxy
  - MATCH,Final

behavior 应与规则集内容一致。常见行为包括 domain、ipcidr 和 classical。域名行为适合域名集合，IP 行为适合网段集合，经典行为可以容纳带类型的完整规则载荷。规则文件的具体格式还与 format 以及内核版本有关，不能把完整的主配置 rules 段直接当作任意格式的规则提供器文件。

远程规则集加载失败时，应确认 URL 可访问、文件格式正确、保存路径可写，并检查客户端日志。若关键分流依赖远程规则集，建议保留合理的最终兜底，避免规则集暂时不可用时连接没有明确去向。

规则不生效的排查顺序

规则问题适合从运行结果反推，而不是一次性改动大量内容。以下顺序可以区分语法、顺序、解析和客户端能力问题。

1. 确认当前配置已启用。客户端可能同时保存多个配置文件。修改后要执行保存、重新加载或切换配置，并确认运行中的配置就是刚才编辑的版本。
2. 查看连接详情。记录目标域名、目标 IP、网络类型、进程名称、命中的规则和最终策略组。连接列表显示的是内核实际判断，比根据网页域名猜测更可靠。
3. 检查更靠前的宽范围规则。重点搜索 DOMAIN-KEYWORD、DOMAIN-SUFFIX、GEOSITE、GEOIP、RULE-SET 和 MATCH。
4. 检查策略名称。规则末尾的目标必须存在。组名经过重命名后，旧规则可能仍指向已经删除的名称。
5. 确认 DNS 观察结果。应用可能直接连接 IP，也可能使用缓存、加密 DNS 或自身解析机制。没有获得域名信息时，域名规则可能无法参与匹配。
6. 确认内核支持。进程、逻辑、GEOSITE 和部分端口规则依赖内核及平台能力。查看启动日志中的未知规则或配置解析提示。
7. 清理旧连接后重试。已经建立的长连接通常不会因为规则修改而立即重新匹配。关闭对应应用连接、清理客户端连接记录或重启应用后再测试。

为什么精确域名仍然没有命中

常见原因是实际请求访问了其他子域、连接详情只有 IP、精确规则位于宽范围规则之后，或修改被订阅更新覆盖。现代网站经常把登录、接口、静态资源和视频分配到不同域名。可以先在连接列表中筛选应用进程，再逐个确认目标主机。

为什么规则显示命中但访问结果没变化

命中正确只说明连接进入了指定策略。还要检查策略组当前选择、节点连通性、DNS 返回、应用缓存以及是否存在独立的 IPv6 连接。如果策略组是自动选择类型，组内节点可能在测试后发生变化；如果域名同时返回 IPv4 和 IPv6，两个连接也可能命中不同类型的规则。

最小化测试配置

复杂配置难以判断冲突来源时，可以临时增加一条足够精确的规则并放到列表最前，再让它指向一个容易识别的策略组。测试成功后逐步恢复规则顺序。不要同时修改 DNS、TUN、代理组和大量规则，否则出现变化时很难确定真正原因。

如果客户端需要通过 TUN 模式接管不遵循系统代理的应用，还应先确认 TUN 已正常启动、路由与 DNS 劫持设置符合当前平台要求。TUN 负责把流量送入内核，规则负责决定流量进入内核后的处理方式，两者处于不同环节。TUN 未接管到的连接，自然不会出现在规则匹配记录中。