2026-07-02 进阶配置 预计阅读 9 分钟

Clash 自定义规则怎么写:匹配类型、语法格式与优先级详解

从 DOMAIN-SUFFIX、IP-CIDR 到 GEOSITE,逐类讲解规则的书写格式与适用场景,重点说明规则自上而下逐条匹配的优先级逻辑,以及自定义规则应插入订阅规则之前还是之后。

SEC-01

规则的基本结构与书写位置

Clash 与 mihomo 内核的分流能力全部建立在配置文件的 rules 字段之上。一条规则本质是一行文本,格式统一为「匹配类型,匹配内容,目标策略」三段式,用英文逗号分隔。以下是最常见的一条规则示例:

rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

第一段是匹配类型,决定用什么维度去判断流量;第二段是具体匹配值,比如域名后缀或 IP 段;第三段是命中后交给哪个策略组或策略处理,常见取值有 DIRECT(直连)、PROXY(走某个策略组)、REJECT(拦截)。部分匹配类型还支持第四个可选参数,例如 IP-CIDR 后面的 no-resolve 表示跳过 DNS 解析、直接按目标 IP 判断,常用于避免不必要的域名解析请求。

规则字段整体位于配置文件末尾,通常紧跟在 proxy-groups 之后。自定义规则和订阅拉取下来的规则会合并成同一个列表,合并后的顺序直接决定了分流结果,这一点在第三节会展开说明。

SEC-02

常用匹配类型逐一说明

域名类匹配

DOMAIN 精确匹配完整域名,只对完全相同的域名生效,比如 DOMAIN,api.example.com,PROXY 只拦截这一个子域名,不影响 www.example.com。

DOMAIN-SUFFIX 匹配域名后缀,是最常用的一类。DOMAIN-SUFFIX,google.com,PROXY 会同时命中 google.com、www.google.com、mail.google.com 等所有以该后缀结尾的域名,适合按整个站点划分策略。

DOMAIN-KEYWORD 匹配域名中包含的关键字,不要求位置,写法是 DOMAIN-KEYWORD,youtube,PROXY。这种匹配范围较宽,容易误伤无关域名,建议只在关键字足够独特时使用。

DOMAIN-REGEX 支持正则表达式匹配域名,适合处理有规律但无法用后缀或关键字覆盖的域名集合,书写和调试成本较高,一般项目里出现频率不高。

IP 与网段类匹配

IP-CIDR 按 IPv4 网段匹配,格式为 IP-CIDR,起始地址/掩码位数,策略,常用于放行局域网地址段,例如 IP-CIDR,10.0.0.0/8,DIRECT,no-resolve。IP-CIDR6 是对应的 IPv6 版本,写法结构一致。

GEOIP 按目标 IP 所属国家或地区判断,内核内置了 IP 地理库,写法是 GEOIP,CN,DIRECT,表示只要连接目标 IP 归属中国大陆就直连,不必逐条列举网段,维护成本远低于手写 IP-CIDR 列表。

地理与规则集类匹配

GEOSITE 是 mihomo 内核对 v2ray 规则集生态的兼容支持,按域名所属分类判断,例如 GEOSITE,cn,DIRECT 一条规则即可覆盖成百上千个中国大陆常用域名,是目前维护成本最低的域名分流方式之一。使用前需要确认配置文件里已声明对应的 rule-providers,否则内核会在启动时报错找不到规则集。

RULE-SET 引用自定义或订阅方提供的规则集文件,格式为 RULE-SET,集合名称,策略,规则集本身是一份包含大量 DOMAIN-SUFFIX/IP-CIDR 等条目的独立文件,通过 rule-providers 字段声明来源地址与更新周期,好处是规则内容可以独立于主配置文件更新,不需要每次都重新编辑规则列表。

进程与端口类匹配

PROCESS-NAME 按发起连接的本机进程名匹配,适合给某个具体客户端单独指定出口,例如只让某个下载工具走直连。DST-PORT 按目标端口匹配,常用于把常见的邮件、游戏端口单独摘出来处理。这两类规则依赖平台层进程识别能力,在部分移动端或沙盒环境下可能失效,建议先在桌面端验证生效后再依赖。

兜底匹配

MATCH 是通配规则,不带匹配值,必须放在规则列表最后一行,表示前面所有规则都没命中时的默认去向。绝大多数配置把 MATCH 的目标设为某个策略组而不是直接写死单一节点,方便随时在客户端界面切换出口而不用改配置文件。

NOTE

规则类型区分大小写敏感度不高,但社区惯例统一使用大写书写,建议保持这个习惯,便于团队协作和后续检索。

SEC-03

优先级逻辑:自上而下,命中即止

Clash 与 mihomo 内核处理规则列表时,遵循严格的顺序匹配原则:从 rules 列表第一行开始逐条比对当前连接,一旦某一行匹配成功,立即采用该行指定的策略,并停止继续向下比对。后面即便还有更精确或更合适的规则,也不会再被检查。这意味着规则的先后顺序本身就是优先级,而不是看匹配类型谁更"精确"。

举一个容易踩坑的例子:

rules:
  - DOMAIN-KEYWORD,google,DIRECT
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,PROXY

这份配置里,第一行的关键字匹配会先命中所有包含 google 字符串的域名并直连,导致第二行本该走代理的 DOMAIN-SUFFIX,google.com,PROXY 永远得不到执行机会——因为连接在到达第二行之前已经被第一行拦下并处理完毕。规则顺序写反,效果就会和预期完全相反,而客户端界面通常不会对这类逻辑冲突给出提示,需要使用者自己核对。

基于这个机制,书写规则时建议遵循从精确到宽泛的排列原则:先放 DOMAIN、DOMAIN-SUFFIX 这类精确匹配,再放 DOMAIN-KEYWORD、GEOSITE、GEOIP 这类范围较宽的匹配,最后以 MATCH 兜底。范围宽的规则一旦放在前面,会提前"截获"本该交给后面精确规则处理的流量。

SEC-04

自定义规则该插在订阅规则之前还是之后

大多数用户的配置文件并非从零手写,而是订阅节点提供方生成的完整配置,其中已经包含一份规则列表。这时新增自定义规则,插入位置直接决定它是否真的生效。

结论是:自定义规则应插入到订阅自带规则列表的最前面,而不是追加在末尾。原因正是上一节说的"命中即止"机制——订阅提供的规则列表往往已经覆盖了大量常见域名和 IP 段,如果把自定义规则加在最后,连接大概率会先被订阅规则匹配掉,自定义规则永远排不上号。只有把自定义规则放在最前面,才能保证它们拥有比订阅规则更高的实际优先级。

常见的做法是在规则列表顶部单独开一段注释分隔,方便下次更新订阅时快速定位并保留这部分内容:

rules:
  # ↓↓↓ 自定义规则,订阅更新时需手动保留 ↓↓↓
  - DOMAIN-SUFFIX,internal.mycompany.com,DIRECT
  - DOMAIN-KEYWORD,ads,REJECT
  # ↑↑↑ 自定义规则结束 ↑↑↑
  - DOMAIN-SUFFIX,google.com,PROXY
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

需要特别注意的是,如果客户端配置了订阅自动更新,而客户端本身不支持"自定义规则单独保存、合并时自动前置"这类高级功能,那么每次订阅刷新都会用远程文件整体覆盖本地配置,手动加在顶部的规则会被一并冲掉。使用 Clash Verge Rev、FlClash 等支持「配置合并」或「覆写(override)」功能的客户端时,建议把自定义规则写在独立的覆写文件里,而不是直接改订阅生成的主配置,这样订阅更新时自定义部分不会丢失。

WARN

直接编辑订阅生成的配置文件属于临时修改,大多数客户端在下一次拉取订阅时会整体覆盖该文件。若需要长期保留自定义规则,请优先使用客户端的覆写、合并或本地规则功能,而不是每次订阅更新后手动重复添加。

SEC-05

典型场景与规则组合示例

下面几组组合覆盖了日常配置里最常遇到的需求,可以直接参考调整策略组名称后使用。

局域网与国内直连,其余走代理

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这组规则先排除局域网和本机地址,避免内网访问被错误地丢进代理链路;再用 GEOSITE 覆盖国内域名,用 GEOIP 兜底覆盖国内 IP 但域名分类未收录的情况;最后 MATCH 把剩余流量统一交给代理策略组。

广告与追踪域名拦截

rules:
  - DOMAIN-KEYWORD,doubleclick,REJECT
  - DOMAIN-SUFFIX,adservice.google.com,REJECT

REJECT 会直接丢弃匹配到的连接请求,客户端表现为该资源加载失败或超时。这类规则同样必须放在其他允许该域名通过的规则之前,否则会被更宽泛的允许规则先行处理而失效。

指定应用强制直连

rules:
  - PROCESS-NAME,WeChat.exe,DIRECT
  - PROCESS-NAME,com.tencent.mm,DIRECT

部分即时通讯或本地网络应用对延迟和线路稳定性要求较高,单独摘出来直连往往比强行套代理体验更好。桌面端进程名通常带扩展名,移动端安卓应用则填写应用包名。

SEC-06

排查规则未生效的思路

规则写完之后如果分流结果不对,优先按下面的顺序检查,而不是直接怀疑节点本身出了问题:

  1. 确认规则顺序

    回看是否有一条范围更宽的规则被写在了目标规则之前,提前截获了流量。这是最常见的原因。

  2. 确认 rule-providers 是否正确加载

    使用 GEOSITE 或 RULE-SET 时,若对应的规则集地址失效或格式不匹配,内核可能启动失败或该规则被静默忽略,需要查看客户端日志确认加载状态。

  3. 确认策略组名称拼写一致

    规则第三段填的策略名必须与 proxy-groups 里定义的名称完全一致,大小写和空格都要对齐,拼错会导致该规则整体失效或报错。

  4. 确认是否命中了更早的兜底规则

    如果配置里存在多条 MATCH 或过早出现的宽泛 GEOIP/GEOSITE 规则,新增的精确规则很可能被挤在了后面,永远得不到执行。

规则系统一旦理清"自上而下、命中即止"这一条主线逻辑,后续无论是接手陌生订阅配置,还是自己从零搭建分流策略,排查思路都会变得清晰很多。建议把自定义规则集中管理、加注释标记边界,长期维护起来会更省心。

下载客户端