跳到正文

· 规则进阶 · 预计阅读 12 分钟

Clash 自定义规则写法:DOMAIN-SUFFIX、IP-CIDR 与 RULE-SET 的匹配顺序详解

逐条拆解常用规则类型的语法,说明自上而下首条命中的匹配机制,以及自定义规则放在订阅规则前后会带来的不同结果。

规则匹配顺序：从上到下，命中即停止

给一个网站指定直连，却仍然走代理，常见原因不是规则类型选错，而是前面已有规则先命中。Clash 的 rules 是一个有顺序的列表。内核从第一条开始检查，遇到适用且命中的规则，就使用该规则指定的出口，不会继续向下寻找“更精确”的规则。

这里的内核指实际处理连接、执行分流的程序。Clash Meta 后续以 mihomo 名称继续发展；客户端则是管理订阅、开关和连接记录的界面。下面以 mihomo 常用 YAML 配置为例。YAML 是用缩进表达层级的文本格式，缩进使用空格，不要混入制表符。

具体规则不会自动获得更高优先级

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,docs.example.com,DIRECT
  - MATCH,PROXY

访问 docs.example.com 时，第一条后缀规则已经匹配，因此使用 PROXY。第二条即使写得更具体，也没有执行机会。若希望文档站直连，应把第二条移到第一条前面。

本篇的 PROXY 是示例策略组名称，不是所有配置都自带的固定关键字。请替换成当前配置中真实存在的策略组名称，大小写与空格也要对应。DIRECT 是内置直连策略，REJECT 是内置拒绝策略，可以直接使用。

DOMAIN 与 DOMAIN-SUFFIX：域名精确匹配和后缀匹配

常见规则写法是“类型、匹配内容、目标策略”，各字段之间使用英文逗号。域名规则里只写主机名，不写 https://，也不写路径、查询参数或末尾斜杠。一个网页地址中的 /account 不是域名的一部分。

规则类型示例匹配范围
DOMAINDOMAIN,docs.example.com,DIRECT仅匹配该主机名，不包含它的子域名。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXY匹配 example.com 本身以及其各级子域名。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,PROXY匹配域名中包含 example 的连接，范围比后缀规则更宽。

后缀规则按域名边界匹配

DOMAIN-SUFFIX,example.com,PROXY 能匹配 example.com、api.example.com 和 a.b.example.com，但不会匹配 notexample.com。这里不需要写成 *.example.com，也不要在匹配内容前补一个点。

如果只想让登录主机直连，优先写 DOMAIN,login.example.com,DIRECT。如果一个组织的整组子域名都需要相同出口，再使用 DOMAIN-SUFFIX。关键词规则适合确实需要宽范围匹配的场景，不能拿它代替所有域名后缀规则，否则容易把不相关的网站一起分流。

IP-CIDR 与 no-resolve：按目标地址分流

IP-CIDR 匹配 IPv4 目标地址段。CIDR 是“地址加前缀长度”的表示方式，例如 192.168.50.0/24 表示从 192.168.50.0 到 192.168.50.255 这一段地址；它不是只匹配最后写出的单个地址。单个 IPv4 地址可用 /32 表示。

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,PROXY

上例中的 IP-CIDR6 用于 IPv6。三个地址段只是写法示范，应按实际局域网范围调整。尤其不要把过大的地址范围直接加入直连列表，否则会改变原本希望通过代理访问的连接。

no-resolve 不等于关闭 DNS

DNS 是把域名解析成 IP 地址的过程。对于带域名但尚未获得目标 IP 的连接，IP 类规则可能触发解析以判断是否匹配。末尾加上 no-resolve，表示不要仅为了检查这一条规则而主动解析域名；若连接本来就带有可用的目标 IP，仍然可以匹配。

因此，no-resolve 既不会关闭整个客户端的 DNS，也不会让某个域名自动绕过代理。若目标是“让某个网站固定直连”，通常应先写域名规则；若目标是“让某段内网地址直连”，再写 IP 规则。域名获取方式、DNS 模式和嗅探设置都会影响内核最终掌握的信息，排查时要看连接详情，而不是只看浏览器地址栏。

RULE-SET：引用规则集合，不改变先后顺序

RULE-SET 用来引用规则提供器（rule-provider）。提供器负责加载一批域名或地址，rules 中的引用则决定这批内容匹配后走哪个策略。集合名字、提供器类型和文件内容必须相互对应，不能只粘贴一条引用就期待集合自动出现。

本地域名集合示例

下面是供合并使用的配置片段，不是可独立运行的完整订阅。先确保现有配置已有名为 PROXY 的策略组，再把提供器与规则合并到各自的顶层字段中。

rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

随后在内核使用的工作目录下创建 rules/work-domains.yaml。相对路径以客户端实际使用的内核工作目录为准，不一定是安装目录。该文件可以写成：

payload:
  - 'example.com'
  - '+.example.org'

在这种域名集合中，example.com 表示该域名，+.example.org 表示 example.org 及其子域名。由于提供器的 behavior 是 domain，这里放的是域名匹配内容，不应写成 DOMAIN-SUFFIX,example.org,PROXY。

domain、ipcidr 与 classical 的区别

远程提供器还需要 URL、更新间隔等配置。使用订阅附带的远程集合时，先检查它是否成功加载，再判断命中顺序。文件下载失败、内容格式不符、集合名称拼错，与规则被前面的条目抢先命中，是不同的问题。

自定义规则放在订阅前面还是后面

订阅更新通常会重新生成配置。直接编辑下载得到的 YAML，可能在下次更新时被替换。更稳妥的方式是使用客户端提供的持久化覆写或规则合并功能。覆写指在订阅原配置之外保存自己的修改，再在启用时合成为内核配置。

不同客户端的菜单名称、合并方向和脚本接口并不相同。不要仅凭“已添加”就判断规则已经生效。关键是确认最终生效配置中的位置：是前置追加、尾部追加，还是整体替换。需要界面基础操作时，可先查看使用手册。

推荐顺序：例外在前，集合居中，兜底在末尾

rules:
  # 自定义例外：优先处理
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN,blocked.example.net,REJECT

  # 已存在的订阅规则：以下仅展示其位置
  - DOMAIN-SUFFIX,example.com,PROXY
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

  # 最后处理未被前面命中的连接
  - MATCH,PROXY

MATCH 是兜底规则，不需要匹配内容。凡是走到这里的连接都会使用其目标策略。如果客户端把自定义规则附加在已有 MATCH 之后，这些规则就没有机会执行。解决方法是前置自定义规则，或者把它们插入最终兜底之前，而不是继续重复添加相同条目。

规则不生效：按连接记录逐项检查

规则修改后，先重新加载配置，再关闭目标应用的旧连接并重新发起请求。浏览器可能复用已经建立的连接；旧连接通常不会因为规则变化就自动切换到新出口。测试时只调整一两条规则，比较起来更容易。

  1. 确认活动配置与模式。检查当前启用的是哪份订阅，工作模式是否为规则模式。编辑了未启用的配置，不会影响当前流量。
  2. 确认流量进入内核。打开客户端的“连接”页面，搜索目标域名或目标 IP。若没有记录，先检查系统代理、应用自身代理和 TUN 接管范围。
  3. 查看命中规则。在连接详情中查找规则类型、规则内容和策略链。各客户端字段名称可能不同，但核心是找出实际命中的那一条。
  4. 对照最终配置顺序。若显示命中了较宽的后缀规则或集合，把更具体的例外移到它前面；若显示命中 MATCH，检查规则内容和提供器是否真的匹配。
  5. 检查出口是否符合预期。命中 PROXY 只表示交给该策略组。如果组内当前选的是 DIRECT，最终仍然是直连。
  6. 更新一次订阅再复测。确认自定义规则仍保留，位置也没有变化。这一步能发现“临时编辑成功、更新后丢失”的问题。

用三次请求验证前后顺序

以前面的域名示例为准：访问 docs.example.com，预期命中精确域名规则并直连；访问 api.example.com，预期命中后缀规则并进入 PROXY；访问一个没有被其他规则覆盖的目标，预期落到 MATCH。这些域名用于说明规则关系，实际测试时请换成可访问且由你确认用途的域名。

一个页面还可能请求登录、图片、视频和接口等多个主机。只给主站写规则，不代表所有资源都会采用相同出口。若出现网页能打开但图片加载失败，先在连接记录中找出失败资源的域名，再决定增加精确规则还是扩展后缀范围。

常见规则问题

DOMAIN-SUFFIX 与 IP-CIDR 同时匹配时，哪条优先？

通常由它们在规则列表中的先后顺序决定，不存在固定的“域名一定优先于 IP”原则。同时还要看连接是否具备判断所需的域名或 IP，以及 no-resolve 是否阻止了为该条规则主动解析。把明确的域名例外放在前面，通常更容易理解与维护。

切换到 TUN 后，还需要自定义规则吗？

需要按分流需求决定。TUN 是通过虚拟网络接口接管流量的方式，不是一套新的匹配优先级。流量进入内核后，规则模式仍按规则顺序选择策略。若某个局域网目标甚至无法建立连接，还应同时检查路由、TUN 排除范围和防火墙。

为什么一条 REJECT 规则没有拦住网页？

先看该域名是否被更靠前的规则放行，再确认网页是否使用了其他资源域名或已有连接。REJECT 只影响实际命中它的连接，不会按网页标题识别整个服务。修改后重新建立连接，并以连接详情中的命中记录为准。

维护规则时，优先保留少量目的明确的例外。每次修改都记录“匹配什么、交给哪个策略、放在哪里”，然后用连接记录验证。只要把流量接管、规则命中和策略组出口分开检查，大多数“写了规则却没有变化”的问题都能定位到具体一层。

下载Clash