Clash 自定义规则怎么写:DOMAIN 系列语法与匹配优先级详解

先看懂一条 Clash 规则的结构

Clash 的规则系统按连接特征决定流量去向。最常见的规则由规则类型、匹配内容和策略三部分组成，各字段使用英文逗号分隔。以域名规则为例，下面这行表示访问 api.example.com 时使用名为 DIRECT 的策略：

DOMAIN,api.example.com,DIRECT

DOMAIN 是规则类型，api.example.com 是匹配内容，DIRECT 是目标策略。目标策略可以是内置动作，也可以是配置中已经存在的代理或策略组名称。常见内置动作包括 DIRECT、REJECT；如果配置里有一个名为“节点选择”的策略组，规则末尾也可以直接写“节点选择”。名称必须逐字一致，空格、大小写和符号都属于名称的一部分。

完整规则列表放在哪里

传统 Clash YAML 把内联规则放在顶层 rules 字段下。每一项以前导短横线开始，排列顺序就是实际匹配顺序：

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

在支持编辑配置的图形客户端中，通常可从「配置」→选择当前配置→「编辑」打开 YAML。不同客户端的按钮名称可能是“编辑文件”“查看配置”或“扩展配置”。保存后还要重新载入该配置；只改磁盘文件但没有触发重载，当前运行中的内核仍会使用旧规则。

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 的区别

域名规则应优先用于网站分流，因为它能直接利用请求域名，不必先把域名解析成 IP。三个常用 DOMAIN 系列规则的覆盖范围不同，不能只看名称相似就互相替换。

规则类型	示例	可以匹配	不会匹配
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	`api.example.com`	`www.example.com`、`v2.api.example.com`
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com` 及其子域名	`example.com.test`
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,DIRECT`	域名中包含 `example` 的连接	不包含该连续字符串的域名

DOMAIN：只匹配完整主机名

DOMAIN 适合只想处理一个明确主机名的情况。例如让软件更新接口直连，但不改变同一主域下其他服务的路线：

DOMAIN,updates.example.com,DIRECT
DOMAIN,telemetry.example.com,REJECT
DOMAIN-SUFFIX,example.com,节点选择

请求 updates.example.com 时，第一条命中并停止；请求 telemetry.example.com 时，第二条命中；请求 store.example.com 才会继续到第三条后缀规则。精确规则放在宽泛规则之前，才能保留例外。

DOMAIN-SUFFIX：覆盖主域和所有下级域名

DOMAIN-SUFFIX,example.com,节点选择 会覆盖 example.com、www.example.com 和 cdn.assets.example.com。它不会按普通文本结尾误匹配 fakeexample.com，匹配过程遵循域名标签边界。

一个网站往往同时使用登录、接口、图片和静态资源子域。已确认这些子域应采用相同策略时，一条后缀规则比逐个列出完整域名更容易维护。如果某个子域需要例外处理，就把对应的 DOMAIN 放到该后缀规则上方。

DOMAIN-KEYWORD：覆盖广，使用前先评估误匹配

DOMAIN-KEYWORD 检查域名中是否包含指定字符串。它适合域名变化较多、但都带有稳定品牌片段的服务，也可能把名称相近但无关的域名一起纳入。关键词越短，覆盖面越大。例如关键词 cdn 可能同时匹配大量互不相关的内容分发域名。

DOMAIN-KEYWORD,company-service,节点选择

能够用 DOMAIN 或 DOMAIN-SUFFIX 表达时，应优先使用范围更明确的类型。关键词规则适合放在精确域名和后缀规则之后、IP 类规则之前。

规则优先级只有一个核心：自上而下，首次命中

Clash 不会把所有匹配结果收集起来再挑“更具体”的一条。内核从 rules 第一行开始检查，遇到第一条匹配规则后立即使用其策略，后续规则不再参与。所谓优先级，本质上就是配置文件中的先后顺序。

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - DOMAIN,api.example.com,DIRECT
  - MATCH,节点选择

这段配置中，api.example.com 会先命中第一条 DOMAIN-SUFFIX，因此第二条精确规则永远没有机会生效。正确写法是把例外放到宽泛规则之前：

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,节点选择

一套便于维护的排序方式

最明确的拒绝、直连或指定节点例外，例如单个 DOMAIN。
覆盖一组服务的 DOMAIN-SUFFIX、DOMAIN-KEYWORD 或 GEOSITE。
局域网、保留地址和已知网段的 IP-CIDR、IP-CIDR6。
按国家或地区归类的 GEOIP。
最后放兜底规则 MATCH。

这不是语法强制模板，而是减少规则遮挡的实用顺序。真正需要优先处理的规则仍应放得更靠前。例如某个 IP 网段必须拒绝访问，它就不应排在可能提前命中的宽泛直连规则之后。

IP-CIDR、GEOIP 与 no-resolve 的真实作用

IP-CIDR 按目标 IPv4 地址或网段匹配，IP-CIDR6 处理 IPv6。CIDR 后的数字表示网络前缀长度：192.168.1.0/24 覆盖 192.168.1.0 到 192.168.1.255，而 10.0.0.0/8 覆盖整个 10.0.0.0 私有地址段。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fd00::/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
MATCH,节点选择

GEOIP 根据目标 IP 在地理数据库中的归属进行匹配。例如 GEOIP,CN,DIRECT 表示数据库判定为中国大陆地址的连接直连。判断质量取决于内核实际加载的 GeoIP 数据，云服务、Anycast 和地址变更都可能造成个别结果与服务器物理位置不一致。

为什么 IP 规则可能触发 DNS 解析

应用发起连接时，内核拿到的目标可能是域名，也可能已经是 IP。检查 IP-CIDR 或 GEOIP 时，如果当前只有域名，内核可能需要解析该域名以取得目标 IP，再判断是否属于指定网段或地区。这就是 IP 规则与 DNS 查询之间的联系。

在支持该参数的 IP 类规则末尾加入 no-resolve，表示不要为了检查这条规则额外解析域名。如果连接本身已经提供目标 IP，这条规则仍可以正常匹配；如果只有域名且没有可用目标 IP，则跳过需要解析才能完成的判断，继续检查后面的规则。

IP-CIDR,203.0.113.0/24,节点选择,no-resolve

no-resolve 不是通用的性能开关，也不应附加到 DOMAIN、DOMAIN-SUFFIX 或 MATCH 后。它主要用于 IP 类规则。是否使用取决于规则目的：局域网网段通常可加，因为目标本来就是私有 IP；如果必须根据域名解析后的地址判断归属，就不能用它阻止这次解析。

Fake-IP 模式下仍要保留域名规则在前

使用 Fake-IP DNS 模式时，客户端可能先收到一个映射地址，但内核保留域名与映射关系，仍能按域名规则分流。把明确的域名规则排在 IP 地理规则之前，可以避免同一服务因 CDN 地址变化而被导向不同策略。只有缺少可用域名信息或域名规则未命中时，IP 类判断才更重要。

mihomo 常用扩展规则：GEOSITE、端口与进程

Clash Meta 现行内核 mihomo 支持比早期 Clash 更丰富的规则类型。配置需要跨不同内核使用时，应先确认客户端实际启动的是哪一种内核；不受支持的规则类型可能直接导致配置载入失败。

规则	用途	示例
`GEOSITE`	使用域名分类数据库匹配一组站点	`GEOSITE,category-ads-all,REJECT`
`DST-PORT`	按目标端口匹配	`DST-PORT,22,DIRECT`
`SRC-IP-CIDR`	按发起连接的来源地址匹配	`SRC-IP-CIDR,192.168.1.50/32,DIRECT`
`PROCESS-NAME`	按进程名称匹配	`PROCESS-NAME,backup.exe,DIRECT`

GEOSITE 匹配的是数据库中的域名集合，不是按服务器 IP 所在国家判断；GEOIP 则基于 IP 数据库。两者名称相近，处理对象完全不同。配置中使用 GEOSITE 前，需要确保客户端已配置并能加载相应 GeoSite 数据。

进程规则依赖操作系统和内核获得进程信息的能力。在 TUN 模式下，不同平台对进程识别的支持程度并不完全一致。需要跨 Windows、macOS 和 Linux 共用配置时，域名与 IP 规则通常更稳定；进程规则更适合做特定设备上的补充，而不是唯一判断条件。

自定义规则应该插在哪一行

自定义规则是否生效，通常不取决于它“写得对不对”，而取决于它有没有放在提前命中的规则之前。定位插入位置时，先找配置尾部的 GEOIP、大范围 RULE-SET 和 MATCH，再判断新增规则要覆盖哪一层行为。

场景一：让一个域名绕过代理

如果原配置已经用 DOMAIN-SUFFIX,example.com,节点选择 接管整个主域，新加的直连例外必须放在它上面：

rules:
  - DOMAIN,office.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

场景二：让一个网段固定走代理

如果该网段可能先被 GEOIP,CN,DIRECT 命中，就应把网段规则插到 GEOIP 之前：

rules:
  - IP-CIDR,198.51.100.0/24,节点选择,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

场景三：在订阅配置中长期保留规则

直接编辑订阅生成的 YAML 往往只能维持到下一次更新。订阅刷新后，客户端通常会用远端内容覆盖本地副本。更稳妥的方法是使用客户端提供的配置覆写、合并配置或扩展脚本，把自定义规则插入订阅规则之前。具体入口应以当前客户端为准，常见操作路径是「设置」→「配置管理」→「覆写」或在当前订阅的菜单中选择「扩展配置」。

如果需要维护几十条以上的规则，可以使用 rule-providers。规则集单独更新，主配置只通过 RULE-SET 引用：

rule-providers:
  private-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-sites.yaml
    url: https://example.com/private-sites.yaml
    interval: 86400

rules:
  - RULE-SET,private-sites,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

behavior: domain 表示规则集负载是域名类内容；如果规则集同时包含 DOMAIN、IP-CIDR 等完整规则，应使用适合完整规则的 classical 行为。提供者类型、文件格式和实际内容必须对应，不能把完整 Clash 规则直接塞进只接受域名负载的集合。

保存后怎样确认规则真的命中

规则验证不能只看网页能否打开。网页成功可能来自直连、代理、缓存或其他网络路径。应同时检查配置载入状态、连接记录和实际命中的规则。

保存配置并执行重新载入，确认界面没有 YAML 解析或规则类型错误。
清理目标应用已有连接，必要时完全退出并重新打开应用。
在客户端的「连接」页面按域名筛选目标请求。
查看该连接显示的规则类型、规则内容和最终策略组。
分别测试主域、子域和一个不应命中的相似域名，确认覆盖范围符合预期。

例如测试 DOMAIN-SUFFIX,example.com,DIRECT 时，可以依次观察 example.com、api.example.com 与 example.com.test。前两个应命中，第三个不应命中。测试精确规则时，再增加 v2.api.example.com，它不应被 DOMAIN,api.example.com,DIRECT 视为同一个域名。

规则没有生效时按这个顺序排查

先看是否被上方规则截走：在连接详情中找到实际命中的规则，而不是反复移动末尾的自定义项。
再看策略名称：规则末尾必须与策略组名称完全一致。
检查当前配置：编辑的文件可能不是客户端正在使用的配置。
检查旧连接：规则变更通常不会重新分流已经建立的 TCP 连接。
检查 DNS 与目标类型：应用可能直接连接 IP，也可能使用不同子域或 QUIC 的 UDP 连接。
检查内核兼容性：GEOSITE、逻辑组合和部分进程规则需要 mihomo 支持。

一份可直接检查顺序的规则示例

下面的结构展示了“单域名例外、域名集合、私有网段、地区规则、最终兜底”的顺序。策略组名称需要与自己的配置保持一致：

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN,ads.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - GEOSITE,category-ads-all,REJECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

这份示例中，登录域名优先直连，广告子域优先拒绝，其余 example.com 服务走“节点选择”。随后才检查通用广告分类、私有地址和地区 IP。最后，所有没有命中的连接交给 MATCH。新增规则时，只要先回答“它应该覆盖哪条现有规则”，插入位置通常就能确定。

规则维护的重点不是堆数量，而是控制覆盖范围。优先使用精确域名，确认整组子域策略一致后再用后缀；IP 规则明确是否允许解析；大范围分类与兜底放在后面。完成修改后通过连接详情验证命中项，能比单纯观察网页结果更快定位问题。