Clash 自定义规则写法:DOMAIN-SUFFIX、IP-CIDR、RULE-SET 语法与匹配优先级

先确认规则模式与实际生效配置

要让某个域名固定直连，先将客户端运行模式切到「规则 / Rule」，再把自定义条目放在现有 rules: 列表的前部。保存并重新加载配置后，打开连接列表，检查该域名命中的规则与最终出站。全局模式按全局策略转发，直连模式直接连接，都不适合用来验证这里的分流顺序。

Clash 是客户端与内核生态中的常见名称，Clash Meta 后续使用 mihomo 名称。本文的域名规则、CIDR 规则和顺序匹配属于常见配置能力；具体规则集格式、附加规则类型仍取决于实际内核。客户端界面和内核不是同一个概念，排错时应在「关于」或内核信息区域确认当前运行的是哪一种内核。

打开当前启用的配置，先备份原文件或导出配置。
确认已经存在的策略组名称，例如 代理选择，包括大小写、空格与汉字。
通过客户端提供的覆写、合并或自定义规则入口，添加少量规则。
重新加载后查看生效配置，确认新增规则真的进入了 rules，而不只是保存在编辑器里。

基础语法：类型、匹配内容、出站目标

大多数普通规则采用 类型,匹配内容,目标 的结构。目标可以是内置的 DIRECT、REJECT，也可以是当前配置中已有的代理节点或策略组。MATCH 不需要匹配内容，写成 MATCH,目标，通常放在最后兜底。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,代理选择

这是一段用于替换或合并现有规则列表的示例，默认配置中已经定义了 代理选择。若现有策略组叫 Proxy，就必须使用实际名称；单独粘贴这段并不会创建策略组或代理节点。示例中的保留域名用于说明匹配边界，部署时应换成需要控制的真实业务域名。

类型	匹配范围	适用情况
`DOMAIN`	完整域名精确匹配	只调整一个 API 或登录入口
`DOMAIN-SUFFIX`	域名本身及其子域名	统一处理一个域名体系
`DOMAIN-KEYWORD`	域名中包含指定字符串	明确接受较宽匹配范围时使用
`IP-CIDR`	目标 IPv4 地址段	局域网、固定服务地址
`RULE-SET`	引用已声明的规则提供器	集中维护较多域名或网段
`MATCH`	前面尚未命中的连接	列表末尾的默认出站

DOMAIN-SUFFIX 不是任意字符串结尾

DOMAIN-SUFFIX,example.com,DIRECT 可以匹配 example.com 和 img.example.com，不会匹配 notexample.com。无需写成 *.example.com，也不要把 https://、端口或路径填进域名字段。规则匹配的是连接目标信息，不是浏览器地址栏中的完整 URL。

若只想修改 api.example.com，使用 DOMAIN 更便于控制范围。DOMAIN-KEYWORD,example,DIRECT 则可能连带匹配含有同一字符串的其他域名；涉及登录、支付或企业内部系统时，优先选择精确匹配，再按需求扩大范围。

匹配优先级：从上到下，首条命中结束

普通 rules 列表按书写顺序评估，通常第一条命中的规则决定出站，不会先收集所有结果，再自动选择「更具体」的一条。域名规则没有天然高于 IP 规则的等级，精确域名也不会自动抢在域名后缀前面；需要优先执行的例外必须写在前面。

rules:
  - DOMAIN,api.example.com,代理选择
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,代理选择

在这段顺序里，api.example.com 使用 代理选择，而 www.example.com 直连。如果交换前两条，API 域名先命中后缀规则，下面的精确规则就不会再执行。这也是新增规则后「配置能加载，但流量没变化」的常见原因。

自定义规则应放在什么位置

局部例外放在通用规则之前：单个域名的特殊出站，排在覆盖整个域名体系的规则之前。
自定义修正放在相关订阅规则之前：若订阅中的规则集已覆盖目标域名，后置追加通常无法改变它的结果。
兜底规则放在末尾：MATCH 之后的普通规则没有机会处理已经兜底的连接。
保留明确的安全边界：前置直连规则也可能绕过订阅中的拦截规则，只为确认需要放行的域名添加例外。

因此，「自定义规则放在订阅规则之前」是处理覆盖关系的方法，不是要求所有自定义条目无条件排在最顶部。若已有必须优先执行的拦截规则或本地网络规则，应按实际需求排列，最后检查完整生效列表，而不是只看新增的几行。

IP-CIDR 与 no-resolve：控制规则触发的解析

IP-CIDR,192.168.50.0/24,DIRECT,no-resolve 表示将该 IPv4 网段作为匹配条件，目标为直连；/24 是网络前缀长度。单个 IPv4 地址可用 /32，单个 IPv6 地址可用 /128。这里填写的是目标地址，不是本机源地址。

当连接目标仍是域名时，内核在评估需要目标 IP 的规则时，可能为了判断是否命中而进行 DNS 解析。no-resolve 的作用是避免仅为这条 IP 规则主动发起解析；它不是「禁止 DNS」，也不表示此连接一定直连，更不会阻止后续规则或实际建立连接时所需的解析。

目标已经是 IP，或内核已有可用的真实目标 IP 时，仍可以进行网段匹配。
目标是域名且此时没有可用 IP 时，带 no-resolve 的 IP 规则通常不会为了匹配而查询地址，连接会继续检查后续规则。
局域网地址与明确的 IP 直连需求适合使用此参数；若希望根据域名解析结果判断某个网段，需要同时评估去掉参数后的 DNS 行为。

以公司内网服务为例：如果应用直接访问 192.168.50.10，上面的网段规则很容易验证；如果访问的是解析到该地址的内部域名，则优先添加明确的域名直连规则，并确认 DNS 能解析公司内网域名。路由选择与 DNS 可达性是两个问题，单独写 DIRECT 不会修复错误的解析服务器。

RULE-SET 写法：提供器定义与规则引用

规则数量较多时，可以在 rule-providers 中声明规则提供器，再用 RULE-SET,提供器名称,目标 引用。它和提供代理节点的 proxy-providers 用途不同。下面以 mihomo 的本地 YAML 域名规则集为例，先准备文件，再合并主配置。

第一步：创建本地域名规则文件

在内核允许读取的配置目录内创建 rules/local-direct.yaml。文件内容使用 payload，因为提供器声明为 behavior: domain，这里只填写域名匹配内容，不添加 DOMAIN-SUFFIX 类型和出站目标。

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

这里的 example.com 用于精确域名匹配，+.example.org 表示域名本身及其子域名。规则集域名表示法与主配置中的 DOMAIN-SUFFIX 语法处于不同层级，不能原样混写。

第二步：声明并引用提供器

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,代理选择

local-direct 必须在定义与引用处完全一致。相对路径按内核的工作目录解释，不一定是当前编辑的订阅文件旁边；遇到读取失败，查看内核日志中的实际路径与权限。这里的 type: file 读取本地文件，不会自动从网络下载内容。

如果改用 behavior: classical，规则集中的条目要带规则类型，例如 DOMAIN-SUFFIX,example.org，但仍不写出站目标，目标由外层 RULE-SET 指定。规则集里的所有匹配项在主列表中占据引用处的位置，并不会获得额外优先级。把引用放在 MATCH 后面，同样无法达到分流目的。

验证与排错：看命中规则，再看出站链

每次只增加一到三条规则，先通过配置语法检查，再重新加载。YAML 使用空格缩进，避免 Tab；已有 rules: 时直接合并列表，不要在文件末尾再添加一个同名顶层键。重复键可能导致前面的内容被覆盖，或直接引发解析错误。

确认流量进入内核。浏览器使用系统代理，或应用明确设置代理，或由 TUN 接管相关流量。没有进入内核的连接不会执行这些规则。
确认测试端口。若当前生效配置的 mixed-port 是 7890，可用下面的命令显式走本地 HTTP 代理；实际端口不同就同步修改。
检查新连接。在连接列表中搜索目标域名，展开查看规则类型、匹配内容与出站链。已有长连接可能继续沿用旧路径，需要关闭对应连接后重试。
区分策略组与最终节点。命中 代理选择 只表示进入该组；如果组内当前选择 DIRECT，最终仍然直连。

curl --proxy http://127.0.0.1:7890 --head https://example.com

这条命令用于产生一条明确经过本地代理入口的测试请求，不能仅凭 HTTP 状态码判断分流成功。应同时在客户端中核对命中规则；域名可能返回重定向，浏览器页面也可能请求多个不同域名，必须分别检查需要控制的连接。

三类常见故障的检查顺序

配置加载失败：检查缩进、逗号、策略组名称，以及 RULE-SET 引用的提供器是否存在；优先阅读日志中的第一条错误。
加载成功但规则未命中：检查运行模式、规则顺序、真实请求域名和生效配置。若连接只带 IP，域名规则能否匹配还取决于内核是否掌握域名信息。
规则命中但连接失败：继续检查 DNS、选中节点、目标服务和本地路由。规则命中只证明选择了路径，不证明该路径一定可达。

使用 TUN 时，部分系统流量、局域网访问或配置中排除的路由可能不会进入预期路径；应用自带代理也可能改变入口。先用显式代理命令验证规则本身，再回到浏览器或目标应用验证接管范围，能把「规则写错」与「流量没有进入内核」分开定位。

完成验证后，再执行一次订阅更新并检查规则是否保留。稳定的维护顺序是：本地覆写保存例外、订阅维护通用规则、末尾保留明确兜底；每次修改都用连接记录确认结果。关于完整配置字段和接管方式，可继续查看进阶配置或帮助中心。