Clash 自定义规则怎么写:DOMAIN、IP-CIDR 语法与匹配优先级详解

一、规则条目的基本结构

Clash 的分流能力建立在一条条规则之上,配置文件里 rules: 字段下的每一行都是一条独立规则。规则的通用格式是三段式,用英文逗号分隔:

TYPE,ARGUMENT,POLICY

TYPE 表示匹配依据的类型,例如域名、IP 段或进程名;ARGUMENT 是具体的匹配值;POLICY 是命中后要走的策略,可以是某个代理节点名、某个策略组名,也可以是内置的 DIRECT(直连)或 REJECT(拒绝)。部分规则类型还支持第四段可选参数,最常见的是 no-resolve,用于告诉核心在匹配 IP 类规则时不要先做 DNS 解析,避免不必要的查询延迟或隐私泄露。一条完整的规则示例:

DOMAIN-SUFFIX,example.com,Proxy
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

理解这套三段式(加可选第四段)结构,是看懂后面所有规则类型的前提。

二、常用规则类型逐一拆解

Clash 内核(包括 Clash Meta / mihomo 分支)支持的规则类型不少,但日常配置里高频出现的其实集中在以下几类,按匹配对象可以分成域名类、IP 类、地理位置类和进程/端口类四组。

1. 域名类规则

• DOMAIN:精确匹配完整域名,例如 DOMAIN,www.example.com,Proxy 只对这一个域名生效,子域名或其他前缀不会被命中。
• DOMAIN-SUFFIX:匹配域名后缀,写法为 DOMAIN-SUFFIX,example.com,Proxy,会同时命中 example.com 本身以及 www.example.com、api.example.com 等任意子域名,是最常用的一类域名规则。
• DOMAIN-KEYWORD:只要域名中包含指定关键字就命中,例如 DOMAIN-KEYWORD,google,Proxy 会匹配任何含有 "google" 字样的域名,匹配范围较宽,使用时要留意误伤同名字符串的其他域名。
• DOMAIN-REGEX:用正则表达式匹配域名,适合需要精细控制、又不想逐条罗列的场景,但书写和调试成本更高,建议只在前三种类型无法满足需求时使用。

2. IP 与网段类规则

• IP-CIDR:按 IPv4 CIDR 网段匹配,例如 IP-CIDR,10.0.0.0/8,DIRECT 表示这整个私有网段都走直连。
• IP-CIDR6:语法与 IP-CIDR 一致,专用于 IPv6 网段。
• IP-SUFFIX:按 IP 地址后缀片段匹配,使用场景相对小众,多见于特定内网划分。
• SRC-IP-CIDR:按发起请求的源 IP 网段匹配,常用于给局域网内某些设备单独指定策略,而不是按目标地址区分。

IP 类规则通常会搭配 no-resolve 参数使用,尤其是直连规则,因为直连流量本身不需要额外的解析开销。

3. 地理位置类规则

• GEOIP:根据目标 IP 所属国家或地区判断,例如 GEOIP,CN,DIRECT 表示识别为中国大陆 IP 的流量走直连。这类规则依赖一份 IP 地理数据库,判断精度受数据库更新程度影响。
• SRC-GEOIP:与 GEOIP 类似,但判断依据是请求发起方的地理位置而非目标地址。

4. 进程与端口类规则

• PROCESS-NAME:按发起连接的进程名匹配,例如 PROCESS-NAME,com.example.app,Proxy,适合给单个应用单独定制策略,常见于移动端配置。
• PROCESS-PATH:按进程的完整可执行文件路径匹配,精度比 PROCESS-NAME 更高,但配置也更繁琐。
• DST-PORT / SRC-PORT:按目标端口或源端口匹配,常用于把某些端口(如邮件、游戏专用端口)固定走某条线路。

5. 规则集与兜底

• RULE-SET:引用一份外部规则集文件,把一大批同类规则打包管理,便于订阅式更新,避免手工维护成百上千条明细规则。
• MATCH:兜底规则,不需要参数,任何未被前面规则命中的流量最终都会落到这一条上,格式为 MATCH,POLICY。

三、匹配优先级:自上而下,一击即中

理解 Clash 规则最关键的一点是:规则匹配严格按照 rules: 列表里从上到下的顺序逐条判断,一旦某条规则命中,立刻按该规则的策略处理,后面的规则不再继续检查。这意味着规则的先后位置本身就是一种优先级设定,和规则类型本身没有天然的高低之分——写在前面的类型,不管是 DOMAIN 还是 GEOIP,只要先被检查到并命中,就会先生效。

举一个容易踩坑的例子:

GEOIP,CN,DIRECT
DOMAIN-SUFFIX,example.com,Proxy

如果 example.com 所在服务器的 IP 恰好被地理数据库识别为中国大陆 IP,上面这份配置会在第一条 GEOIP 规则处就把流量导向直连,第二条针对该域名的代理规则永远不会被执行到。想让某个特定域名始终走代理,就必须把这条域名规则放在 GEOIP 之前:

DOMAIN-SUFFIX,example.com,Proxy
GEOIP,CN,DIRECT

这个顺序问题在规则条目较多的配置里非常常见,排查“某个网站明明配了代理却没走代理”的问题时,第一件事就应该去检查有没有更靠前的宽泛规则把它拦截了。

四、GEOIP 与 MATCH 的位置讲究

GEOIP 规则和 MATCH 兜底规则的摆放位置,是整份规则列表里最值得单独强调的两处。

GEOIP 应该放在细分规则之后

GEOIP 判断的是目标 IP 归属的国家或地区,覆盖面很大,一条 GEOIP,CN,DIRECT 可能会覆盖成千上万个具体域名。如果放在规则列表靠前的位置,很容易把本该走代理的特定服务也一并直连掉。稳妥的做法是先把需要精确控制的域名、应用、端口规则写在前面,把 GEOIP 类规则放在这些细分规则之后、兜底规则之前,让它承担“大多数没被特别标注的本地流量直连”这一角色。

MATCH 必须放在整份列表的最后一行

MATCH 是兜底规则,顾名思义要接住所有前面规则都没处理到的流量。它不需要参数,格式固定为 MATCH,POLICY,常见写法是 MATCH,Proxy 或 MATCH,DIRECT,取决于站点的分流策略偏好。这条规则如果不放在最后,会导致它前面本该被具体规则处理的流量提前被兜底策略接管,后面写的所有细分规则形同虚设。可以理解为:MATCH 一旦出现,它之后的规则永远不会被执行到,所以它只能、也必须是最后一条。

五、可直接套用的排序建议

结合上面的机制,一份结构清晰的规则列表通常遵循“先精确、后宽泛,最后兜底”的排列思路,大致分五层:

1. 局域网与私有地址直连:如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve,避免内网流量绕道代理。
2. 特殊应用与端口的定向规则:如需要单独控制的 PROCESS-NAME、DST-PORT 规则。
3. 需要重点关注的域名规则:常用服务的 DOMAIN-SUFFIX、DOMAIN 规则,明确指向代理或直连。
4. 规则集与地理位置规则:RULE-SET 引用的大批量规则,以及 GEOIP 兜底本地流量。
5. 最终兜底:一行 MATCH,决定所有未命中流量的默认去向。

一份精简示例大致是这样:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
PROCESS-NAME,com.example.updater,DIRECT
DOMAIN-SUFFIX,example.com,Proxy
DOMAIN-KEYWORD,ads,REJECT
RULE-SET,proxy-list,Proxy
GEOIP,CN,DIRECT
MATCH,Proxy

需要说明的是,规则集(RULE-SET)本身也是按其内部条目顺序参与整体匹配的,把它插入到列表中的位置同样遵循“前面已有更精确规则拦截,后面才轮到它”的原则。如果同时引用多个规则集,也建议把范围更窄、更需要优先生效的规则集放在范围更宽的规则集前面。

六、常见排序失误自查

在实际使用中,规则不生效的原因绝大多数不是语法写错,而是顺序问题。整理几个最容易出现的情况:

• 把 GEOIP,CN,DIRECT 写在所有域名规则之前,导致落在中国大陆 IP 段上的目标服务全部被直连拦截。
• DOMAIN-KEYWORD 关键字过于宽泛且排在前面,误伤了原本应该走代理的其他域名。
• MATCH 之后又追加了几条规则,这些规则永远不会被执行,属于无效配置。
• 把本该直连的局域网网段规则放在最后,导致这部分流量先被前面某条宽泛的代理规则接管,访问内网设备变慢。

排查这类问题时,与其反复检查单条规则的语法是否正确,更有效的方式是把整份 rules: 列表打印出来,按顺序在心里模拟一遍匹配过程,通常很快就能定位到是哪一条位置靠前的规则抢先命中了。