2026-07-15 进阶技巧 预计阅读 9 分钟

Clash 自定义规则语法与匹配优先级全解析

逐条拆解 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 等规则类型的语法与匹配顺序,说明规则自上而下命中即停的原则,并给出编写自定义分流规则时避免互相覆盖的排序建议。

规则(rules)是 Clash 配置里决定“这个连接走哪个代理”的核心模块。很多人第一次自己改配置文件时,把规则随手堆在一起,结果发现某条规则明明写对了却从来没生效——原因几乎总是匹配顺序出了问题。这篇笔记按规则类型逐条拆解语法,讲清楚匹配引擎从上到下命中即停的工作方式,并给出一套实用的排序思路,帮助在自定义分流规则时避免规则互相覆盖。

规则的基本结构与执行方式

Clash 配置文件里的 rules 是一个列表,每一行对应一条规则,格式统一为三段式:

RULE-TYPE,VALUE,PROXY

第一段是规则类型,第二段是匹配值(部分规则类型没有这一段,比如 MATCH),第三段是命中后使用的代理或代理组名称。理解这套系统最关键的一点是:Clash 在处理每一个新连接时,会按照规则列表从上到下逐条检测,一旦某条规则命中,就立即采用对应的代理并停止继续往下匹配。后面即便还有能匹配上的规则,也不会再被检查。

这个“命中即停”原则决定了规则的排列顺序本身就是逻辑的一部分,而不只是排版好看。写规则时要始终记住:越靠前的规则优先级越高,越具体、越例外的判断应该放在越靠前的位置,笼统的、兜底性质的规则应该放在最后。

规则列表末尾通常都会有一条 MATCH,PROXY 作为兜底规则,用于处理前面所有规则都没能命中的连接。这条规则理论上必须放在整个列表的最后一行,否则它后面的规则永远不会被执行到。

常见规则类型逐条拆解

下面按使用频率从高到低,说明几种最常用的规则类型的语法和匹配逻辑。

DOMAIN:精确域名匹配

DOMAIN 只匹配完全一致的域名,不做任何模糊或子域名扩展。

DOMAIN,ads.example.com,REJECT
DOMAIN,api.example.com,Proxy

上面第一条规则只会拦截 ads.example.com 这一个确切地址,像 cdn.ads.example.comexample.com 都不会被这条规则命中。适合用于精确屏蔽或精确放行某个具体接口地址。

DOMAIN-SUFFIX:域名后缀匹配

DOMAIN-SUFFIX 匹配指定后缀及其所有子域名,是日常写分流规则时用得最多的类型。

DOMAIN-SUFFIX,youtube.com,Proxy
DOMAIN-SUFFIX,cn,DIRECT

第一条规则会同时命中 youtube.comwww.youtube.commusic.youtube.com 等所有以该后缀结尾的域名。第二条则会把所有以 .cn 结尾的域名直接连接,不走任何代理。这个类型覆盖面广,写自定义规则时最先想到的通常就是它。

DOMAIN-KEYWORD:域名关键词匹配

DOMAIN-KEYWORD 只要域名字符串里包含指定关键词就会命中,不区分关键词出现的位置。

DOMAIN-KEYWORD,google,Proxy

这条规则会命中 www.google.com,也会命中 googleapis.comgooglevideo.com 等任何包含 google 字符串的域名。这个类型匹配范围最宽,写的时候要注意误伤——比如关键词 ad 就可能连带命中大量与广告无关但域名里恰好带 ad 字母组合的正常站点,建议尽量用更完整的关键词或改用 DOMAIN-SUFFIX

IP-CIDR 与 IP-CIDR6:按 IP 段匹配

IP-CIDR 使用 CIDR 表示法匹配一段 IPv4 地址,IP-CIDR6 对应 IPv6。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

这两条常见于放行局域网内网段,让访问路由器、NAS、局域网设备等流量不经过代理。末尾的 no-resolve 参数很关键:它告诉 Clash 不要对这条规则尝试反向 DNS 解析,直接按目标 IP 判断,这样可以避免对域名类规则做多余的解析开销,也能防止一些边缘情况下的误判。

需要注意的是,IP 类规则默认只对连接的目标地址是 IP 的情况生效;如果连接是通过域名发起、Clash 还没有解析出目标 IP,这类规则通常不会在域名阶段命中,而是要等 DNS 解析完成后才能参与匹配,这也是为什么很多人建议把域名类规则尽量写在前面处理。

GEOIP:按国家/地区 IP 库匹配

GEOIP 依据内置或外部加载的 IP 地理位置数据库,判断目标 IP 所属的国家或地区。

GEOIP,CN,DIRECT
GEOIP,JP,Proxy

第一条规则会让所有解析归属为中国大陆的 IP 直连,第二条让归属日本的 IP 走名为 Proxy 的代理组。GEOIP 规则依赖的地理数据库有更新周期,极少数边缘 IP 段可能出现归属判断滞后的情况,遇到明显误判时可以配合具体的 IP-CIDR 规则单独修正。

GEOSITE:按域名分类集合匹配

GEOSITE(在部分内核如 mihomo 中支持)使用预先分类好的域名规则集,一条规则就能覆盖某一类服务下的大量域名,比如流媒体、社交平台等,避免手写成百上千条 DOMAIN-SUFFIX

GEOSITE,netflix,Proxy
GEOSITE,cn,DIRECT

使用这类规则前需要确认客户端已经下载并加载了对应的规则集文件,否则规则会因为找不到分类数据而无法生效。

PROCESS-NAME 与 MATCH

PROCESS-NAME 按发起连接的进程名做匹配,适合给某个具体应用单独指定代理策略,常见于桌面端场景。MATCH 则不带匹配值,代表“以上都不满足时统一如何处理”,永远作为规则列表的最后一行使用。

PROCESS-NAME,Steam.exe,Proxy
MATCH,DIRECT

匹配优先级与命中即停原则

把前面各类规则放进同一份配置后,真正决定行为的是它们的排列顺序,而不是类型本身的“权重”。Clash 并不会因为一条规则是 DOMAIN 就自动优先于排在它前面的 DOMAIN-KEYWORD——顺序完全由列表中的物理位置决定。

看一个容易踩坑的例子:

DOMAIN-KEYWORD,youtube,Proxy
DOMAIN-SUFFIX,youtube.com,DIRECT

本意可能是想让 YouTube 走代理,但特定的子域名(比如某个直连可用的静态资源域)直接连接。可是因为 DOMAIN-KEYWORD 那条规则排在前面,只要域名里带 youtube 字符串就会先被它命中并走代理,后面那条更精确的 DOMAIN-SUFFIX 规则永远没有机会被执行到。要让例外规则生效,必须把它调整到更宽泛的规则之前:

DOMAIN-SUFFIX,youtube.com,DIRECT
DOMAIN-KEYWORD,youtube,Proxy

调整后,精确的域名后缀规则先被检测,命中就直连并停止匹配;只有不满足这条精确规则的其余含 youtube 关键词的域名,才会继续往下走到关键词规则并使用代理。

写规则时如果发现某条明明格式没错却“从不生效”,第一时间要检查的不是语法本身,而是它前面有没有一条更宽泛的规则已经把同样的流量拦截并命中了。

编写自定义规则的排序建议

结合上面的原则,整理一套实用的排序思路,可以显著减少规则互相覆盖导致的调试成本。

  1. 局域网与内网地址放最前:用 IP-CIDR 配合 no-resolve 放行私有网段,避免任何后续规则误把内网流量送进代理。
  2. 精确例外规则紧随其后:凡是需要“大类走代理、个别子项直连”或反过来的场景,把针对具体域名的 DOMAINDOMAIN-SUFFIX 例外规则排在对应大类规则之前。
  3. 分类规则集居中:GEOSITE、常见的广告或隐私拦截规则集放在例外规则之后、宽泛关键词规则之前,让分类库先处理好大部分常规域名。
  4. 宽泛的关键词匹配靠后:DOMAIN-KEYWORD 命中范围最广,容易造成误判,应该放在所有更精确规则都判断过一遍之后才轮到它。
  5. 地区与 IP 归属规则次之:GEOIP 一般用来处理域名规则没能覆盖、且已经解析出具体 IP 的连接,通常排在域名类规则之后。
  6. MATCH 兜底规则放最后一行:所有未被前面规则命中的连接,最终交给这一条统一处理,通常指向默认代理组或者直连,视网络策略而定。

按这个顺序整理后的一份简化示例:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
DOMAIN-SUFFIX,cn-cdn.example.com,DIRECT
GEOSITE,cn,DIRECT
GEOSITE,geolocation-!cn,Proxy
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
MATCH,Proxy

这份示例的逻辑读下来是连贯的:先处理内网,再处理明确要直连的特定 CDN 域名,接着让分类规则集分别处理国内和境外站点的大多数域名,再用关键词规则拦掉零散的广告域名,GEOIP 兜住前面域名规则没处理到但已经能判断归属的 IP,最后 MATCH 收尾,把剩下所有连接送去代理组。

常见错误与排查思路

整理几个实际调试规则时最常遇到的情况,便于快速定位问题。

  • 规则永远不生效:优先检查它前面是否存在范围更宽的规则已经先命中;可以临时把这条规则挪到列表最上面测试,确认语法本身没问题后再考虑排序调整。
  • MATCH 后面还有规则:这些规则永远不会被执行,需要把它们移到 MATCH 之前。
  • IP 类规则对域名连接不生效:检查客户端的 DNS 与解析模式设置,确认连接在匹配阶段已经拿到了目标 IP,必要时改用对应的域名类规则代替。
  • 关键词规则误伤过多域名:把关键词换成更完整的字符串,或改用 DOMAIN-SUFFIX 限定具体后缀,减少无关命中。
  • 规则集加载失败导致分类规则整体不生效:确认对应的规则集文件已经正确下载到本地并在配置里正确引用路径,网络问题或路径写错都会导致这一整块规则失效。

修改规则后,建议先在小范围内测试单条新增或调整的规则,确认命中结果符合预期,再继续叠加下一条,避免一次性改动过多导致排查困难。多数客户端在保存配置后会自动重新加载规则,如果没有观察到预期效果,也可以尝试手动触发一次配置重载来排除缓存问题。

把频繁变动的自定义例外规则集中放在文件靠前的位置维护,把稳定不变的分类规则集和兜底规则留在后面,日后调整时只需要关注开头一小段,能大幅降低维护成本。

获取 Clash 客户端

理解规则语法后,可以在实际客户端中导入配置并逐条验证效果。

下载客户端