规则分流 预计阅读 13 分钟

Clash 自定义规则怎么写:DOMAIN、IP-CIDR、GEOSITE 语法与匹配顺序

逐类拆解 Clash 规则字段的写法与适用场景,说明规则自上而下逐条匹配、首条命中即停的原则,以及 no-resolve、MATCH 兜底与规则集顺序对分流结果的实际影响。

先理解 Clash 规则的执行方式

Clash、Clash Meta 与后续的 mihomo 内核都把连接信息交给规则模块处理。规则模块会读取目标域名、目标 IP、端口、网络类型和进程等信息，再决定使用代理组、具体节点、DIRECT 或 REJECT。这里的关键不是规则数量，而是排列顺序。

规则从上到下逐条检查。第一条符合条件的规则一旦命中，后面的规则就不再参与当前连接的判断。因此，范围窄、意图明确的规则通常放在前面，范围大的规则放在后面，最后再用 MATCH 接住没有命中的连接。

rules:
  - DOMAIN,api.example.com,开发接口
  - DOMAIN-SUFFIX,example.com,国外网站
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,默认代理

在这段配置中，访问 api.example.com 会先命中第一条，使用“开发接口”策略组。即使它也符合第二条的 DOMAIN-SUFFIX,example.com，第二条也不会继续执行。访问 www.example.com 则跳过第一条，在第二条完成匹配。

一条规则通常包含哪些字段

常见规则采用逗号分隔，基本结构是“规则类型、匹配内容、策略”。部分规则可以在末尾增加参数，例如 no-resolve。

规则类型,匹配内容,策略
IP-CIDR,203.0.113.0/24,节点选择,no-resolve

策略名称区分字符，规则里的名称必须和 proxy-groups 中的 name 完全一致。配置里定义的是“节点选择”，规则却写成“节点选择 ”或“代理选择”，都会导致配置加载失败或找不到策略。

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 怎么选

域名规则最适合处理网站和 API 分流。它直接利用连接中的主机名判断，不依赖目标服务器当前解析到了哪个 IP。面对使用 CDN、频繁更换地址或同时分布在多个网段的服务，域名规则通常比固定 IP 更稳定。

DOMAIN：只匹配一个完整域名

rules:
  - DOMAIN,login.example.com,登录服务
  - DOMAIN,cdn.example.net,静态资源

DOMAIN 要求目标域名完整相等。第一条会匹配 login.example.com，但不会匹配 www.example.com、api.login.example.com 或根域名 example.com。它适合单个接口、登录域名、下载域名等边界清楚的目标。

DOMAIN-SUFFIX：匹配根域及其子域名

rules:
  - DOMAIN-SUFFIX,example.com,国外网站
  - DOMAIN-SUFFIX,example.org,DIRECT

DOMAIN-SUFFIX,example.com 会覆盖 example.com、www.example.com 和 a.b.example.com。写规则时不需要在前面增加星号，也不应写成 *.example.com。如果一个站点的网页、图片和 API 都位于同一主域的不同子域，使用 DOMAIN-SUFFIX 更简洁。

DOMAIN-KEYWORD：按域名中的字符串匹配

rules:
  - DOMAIN-KEYWORD,example,测试策略

这条规则会匹配域名中包含 example 的连接，不要求它位于域名末尾。除了 example.com，example-cdn.net 和 notexample.org 也可能命中。它覆盖面大，容易带入无关域名，应放在精确规则之后，并尽量使用足够独特的关键词。

规则 适合场景 主要边界
DOMAIN 单个 API、登录或下载域名 不包含其他子域名
DOMAIN-SUFFIX 整个主域及全部子域 可能覆盖同域下用途不同的服务
DOMAIN-KEYWORD 域名结构变化但关键词稳定 误匹配概率较高

IP-CIDR、IP-CIDR6 与 no-resolve 的作用

IP-CIDR 按 IPv4 地址或网段匹配，IP-CIDR6 用于 IPv6。CIDR 后缀表示网络前缀长度，例如 /32 是单个 IPv4 地址，/24 通常覆盖连续 256 个 IPv4 地址；IPv6 的 /128 表示单个地址。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,203.0.113.8/32,专用节点,no-resolve
  - IP-CIDR6,2001:db8::/32,专用节点,no-resolve

前两条常用于私有网络直连。第三条只匹配一个 IPv4 地址。示例中的 203.0.113.0/24 与 2001:db8::/32 属于文档示例地址，不应当作为真实服务网段直接投入使用。

no-resolve 不是“不使用 DNS”

当连接只有域名信息时，IP 规则需要目标 IP 才能判断。没有 no-resolve 时，内核可能为规则匹配触发一次域名解析。加入 no-resolve 后，该 IP 规则不会仅为判断规则而主动把域名解析为 IP；如果连接本身已经提供目标 IP，规则仍可正常匹配。

- DOMAIN-SUFFIX,example.com,国外网站
- IP-CIDR,203.0.113.0/24,专用节点,no-resolve
- GEOIP,CN,DIRECT,no-resolve
- MATCH,默认代理

这种排列先利用已有域名做判断，再检查已知 IP，最后兜底。它可以减少规则阶段额外解析带来的延迟和 DNS 依赖。需要注意，no-resolve 不会关闭 Clash 的 DNS 模块，也不会改变应用自身发起的 DNS 请求。

GEOIP 与固定网段的区别

GEOIP,CN,DIRECT 使用 GeoIP 数据库判断目标 IP 所属地区。它适合做大范围地区分流，但数据库分类不等同于服务归属：一个国外品牌可能使用中国大陆 CDN，一个国内服务也可能连接境外节点。因此，关键服务宜先写 DOMAIN 或 DOMAIN-SUFFIX，GEOIP 放在后面承担较宽的地区判断。

GEOSITE、GEOIP 与规则集如何配合

mihomo 支持 GEOSITE 规则。GEosite 数据按类别整理域名，例如地区、服务或用途分类。它减少了手写大量 DOMAIN-SUFFIX 的工作，但实际可用分类取决于客户端携带或下载的 geosite 数据文件。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

上面的顺序先处理广告类别，再处理私有域名和中国大陆域名，接着处理已经取得 IP 的私有地址及中国大陆地址。未命中的连接交给“节点选择”。如果把 GEOSITE,cn,DIRECT 放在自定义代理域名之前，该域名只要被 cn 分类收录，就会提前直连。

规则集通过 RULE-SET 插入执行队列

rule-providers 负责定义规则集来源、格式、更新周期和本地存储位置，RULE-SET 决定该规则集在主规则队列中的位置。声明了 provider 并不代表规则会自动执行，仍需在 rules 中引用。

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

  service-rules:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-rules.yaml
    url: https://rules.example.net/service-rules.yaml
    interval: 86400

rules:
  - DOMAIN,api.example.com,专用节点
  - RULE-SET,service-rules,节点选择
  - RULE-SET,direct-sites,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

interval: 86400 表示按 86400 秒，也就是 24 小时检查一次更新。behavior: domain 的内容应是域名类条目；behavior: ipcidr 用于网段；behavior: classical 可以承载带类型的经典规则。provider 的实际格式必须和文件内容一致。

payload:
  - example.com
  - api.example.net
  - +.service.example.org

这是 domain 行为规则集的常见 YAML 结构。若使用 classical 行为，条目通常带规则类型，例如 DOMAIN-SUFFIX,example.com 或 IP-CIDR,203.0.113.0/24,no-resolve。策略不写在 provider 的每个条目中，而由主配置里的 RULE-SET,规则集名称,策略 统一指定。

MATCH 兜底与常见顺序错误

MATCH 不带匹配内容，所有到达它的连接都会命中，因此通常只能放在规则列表最后。它决定未分类流量的默认去向。常见选择是一个可手动切换的代理组，而不是固定节点，这样节点不可用时更容易调整。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

rules:
  - DOMAIN-SUFFIX,intranet.example,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

错误一：MATCH 放得太早

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

第二条永远没有执行机会。所有连接在第一条就完成匹配。配置可能仍能加载，但分流结果会表现为“全部走同一个策略”。

错误二：宽泛后缀覆盖精确例外

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,video.example.com,媒体节点

video.example.com 同时符合两条规则，却会先被第一条接走。正确做法是把精确例外移到前面：

rules:
  - DOMAIN,video.example.com,媒体节点
  - DOMAIN-SUFFIX,example.com,DIRECT

错误三：策略名称与代理组不一致

规则中的“节点选择”必须已经在 proxy-groups 定义。如果代理组实际名称是“代理选择”，加载配置时通常会出现策略找不到一类错误。中文名称、空格和大小写都应逐字核对。

错误四：把端口当成服务身份

DST-PORT,443,节点选择 会覆盖所有目标端口为 443 的连接，不只是一家网站。现代 HTTPS、应用 API 和部分加密 DNS 服务都会使用 443。端口规则适合明确协议边界，不适合替代域名规则。

rules:
  - DST-PORT,22,开发网络
  - NETWORK,udp,UDP 策略
  - MATCH,节点选择

即使是端口 22，也可能被用于非 SSH 服务；反过来，SSH 也可以运行在其他端口。涉及工作网络时，应结合目标域名、目标网段和端口，而不是只看单一字段。

一套便于维护的规则排序模板

实际配置没有唯一顺序，但可以按“本地例外、精确服务、批量域名、IP 与地区、默认策略”组织。下面的模板适用于常见桌面使用场景，名称需要替换为配置中已有的代理组。

rules:
  # 1. 本地网络与明确例外
  - DOMAIN,router.lan,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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

  # 2. 单个服务的精确策略
  - DOMAIN,api.example.com,专用节点
  - DOMAIN-SUFFIX,example.net,媒体节点

  # 3. 外部规则集
  - RULE-SET,work-services,工作网络
  - RULE-SET,streaming-services,媒体节点
  - RULE-SET,direct-sites,DIRECT

  # 4. 大范围域名和地区判断
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  # 5. 最终兜底
  - MATCH,节点选择

私有 IPv4 网段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。回环地址 127.0.0.0/8 通常也应直连。是否需要显式写入这些规则，取决于配置已有的私有网络规则集和客户端设置，重复规则不会增加匹配能力。

控制规则数量与更新边界

修改配置后怎样验证规则是否生效

修改 YAML 后，第一步是确认配置能够重新加载。桌面客户端通常提供配置编辑和重载入口。例如在配置管理页面打开当前配置，编辑文件并保存，再执行“重新载入”或切换到该配置。不同客户端菜单名称会有差异，不应只保存文件而跳过重新加载。

如果使用 mihomo 的外部控制器，常见监听地址是 127.0.0.1:9090；HTTP 与 SOCKS 混合端口常见为 7890，DNS 监听端口常见为 1053。这些数字只是常用默认值，应以当前配置中的 external-controller、mixed-port 和 dns.listen 为准。

按四步检查命中结果

  1. 重载配置：确认客户端没有 YAML 缩进、未知规则类型或策略不存在的报错。
  2. 清理旧连接：关闭目标应用的现有连接，必要时退出后重新打开。已建立的长连接不会因新增规则自动重新分流。
  3. 发起单一测试：只访问一个目标域名，减少后台同步、更新和推送连接的干扰。
  4. 查看连接详情：在客户端“连接”页面检查 Host、目标 IP、命中规则与所用代理链。

假设新增了 DOMAIN,api.example.com,专用节点，连接详情却显示命中 DOMAIN-SUFFIX,example.com，应先检查精确规则是否真的位于后缀规则之前。如果显示的是 IP-CIDR，可能是应用直接连接 IP，或域名信息没有传递给内核。

TUN 模式下仍然遵循同一规则顺序

TUN 模式改变的是流量进入内核的方式，不会把规则改成并行匹配。系统代理通常覆盖遵循代理设置的应用，TUN 模式则可接管更多 TCP、UDP 和不读取系统代理的程序。流量进入内核后，仍然从第一条规则向下检查。

启用 Fake-IP DNS 增强模式时，应用可能先得到保留地址，内核会利用映射关系恢复域名并参与规则判断。因此在连接页面看到 Fake-IP，不代表 DOMAIN 规则失效。若某个应用只连接硬编码 IP，仍应使用 IP-CIDR、GEOIP 或进程规则处理。

规则不生效时的排查顺序

规则问题适合从配置加载、流量入口、连接信息、规则位置四层排查。先确认内核采用了新配置，再判断目标流量是否进入 Clash，最后检查规则本身。直接反复调整语法，往往会掩盖系统代理未开启或配置没有重载的问题。

配置能否加载

目标流量是否进入内核

系统代理模式下，应用可能忽略系统代理设置；TUN 模式下，也可能存在路由排除、接口冲突或权限问题。连接列表完全看不到目标应用时，应先检查入口，而不是继续改规则。浏览器已有连接也可能通过连接复用继续工作，关闭标签页未必会立即断开底层连接。

内核拿到的是域名还是 IP

DOMAIN 类规则需要域名信息。若应用直接访问 IP，规则只能依靠 IP-CIDR、GEOIP、端口、网络类型或进程信息。反过来，给 IP-CIDR 加上 no-resolve 后，如果连接当前只有域名，该条规则会跳过，而不是主动解析后再比较。

前面是否已有更宽的规则

在目标规则上方依次寻找 DOMAIN-SUFFIX、DOMAIN-KEYWORD、RULE-SET、GEOSITE、GEOIP 和 MATCH。任何一条先命中，目标规则都不会执行。排查时可以暂时把精确规则移动到规则列表最前面；验证成功后，再放回结构合理的位置。

写规则时可直接遵循的结论

一套可维护的规则并不依赖大量条目，而是让每条规则的边界和位置都可解释。先写精确例外，再放批量规则集，最后进行地区判断和 MATCH 兜底，出现偏差时就能沿着执行顺序快速定位。

下载 Clash 客户端 查看 Windows、macOS 与移动端版本