Published on

Clash Rules 配置说明

Authors
  • Name
    Twitter

Rules 是 Clash 系列内核里最核心的分流能力之一。它决定一条请求最终应该走 DIRECT、某个代理节点，还是某个代理组。

这篇文档以 mihomo / Clash.Meta 的规则语法为主来总结，因为它是现在最常见、规则能力也更完整的一支实现。
如果你使用的是更早期的 Clash 内核，需要特别注意：RULE-SET / rule-providers 这类能力通常只在 Premium 核心或 mihomo 中可用，不是所有 Clash 内核都完整支持。

1. Rules 的基本格式

最常见的格式是：

rules:
  - RULE-TYPE,VALUE,POLICY

例如：

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

上面这段的含义是：

  • 访问 google.com 及其子域名时，走 PROXY
  • 目标 IP 属于中国大陆时，走 DIRECT
  • 其余没有匹配到的请求，最终走 MATCH 指向的策略

2. 匹配顺序

Rules 按照 从上到下 的顺序匹配，谁先命中就优先采用谁。

这意味着配置时要遵守三个原则：

  • 具体规则放前面
  • 范围更大的规则放后面
  • MATCH 一定放最后

例如：

rules:
  - DOMAIN,www.google.com,PROXY
  - DOMAIN-SUFFIX,google.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这里会先尝试精确命中 www.google.com，再尝试更宽泛的 google.com 后缀规则。

在 mihomo 文档里还特别提到一个细节：
如果当前请求是 UDP，而命中的代理节点本身不支持 UDP，那么内核会继续向下匹配后续规则，而不是直接结束。

3. 常见 Rules 类型

下面是实际使用最频繁的一组规则类型。

3.1 域名类

DOMAIN

精确匹配完整域名：

- DOMAIN,www.google.com,PROXY

只匹配 www.google.com，不匹配其他子域名。

DOMAIN-SUFFIX

按域名后缀匹配：

- DOMAIN-SUFFIX,google.com,PROXY

它会匹配：

  • google.com
  • www.google.com
  • mail.google.com

但不会匹配 content-google.com。

DOMAIN-KEYWORD

按域名关键字匹配：

- DOMAIN-KEYWORD,google,PROXY

只要域名里包含 google，就会命中。
这类规则写起来方便，但范围相对更模糊，通常不建议滥用。

DOMAIN-WILDCARD

使用通配符匹配域名：

- DOMAIN-WILDCARD,*.google.com,PROXY

这里支持的通配符主要是：

  • *：匹配 0 个或多个字符
  • ?：匹配恰好 1 个字符

DOMAIN-REGEX

使用正则匹配域名：

- DOMAIN-REGEX,^abc.*com,PROXY

它更灵活，但也更难维护，除非确实有必要，否则优先考虑 DOMAIN 和 DOMAIN-SUFFIX。

GEOSITE

按域名分类库匹配：

- GEOSITE,youtube,PROXY

这种规则会引用预定义的域名分类集，适合大规模分流。
如果你已经在用 mihomo 的 geosite 数据，这会比手工堆很多 DOMAIN-SUFFIX 更省事。

3.2 IP 类

IP-CIDR / IP-CIDR6

按 IP 网段匹配：

- IP-CIDR,127.0.0.0/8,DIRECT
- IP-CIDR6,2620:0:2d0:200::7/32,PROXY

GEOIP

按目标 IP 所属国家/地区匹配：

- GEOIP,CN,DIRECT

这通常是最常见的“国内直连、国外代理”写法之一。

其他来源 IP 规则

mihomo 还支持更多按来源维度匹配的规则，例如：

  • SRC-IP-CIDR
  • SRC-GEOIP
  • SRC-IP-ASN
  • SRC-IP-SUFFIX

例如：

- SRC-IP-CIDR,192.168.1.201/32,DIRECT

如果你在做局域网、透明代理或网关场景，这类规则会很有用。

3.3 端口与网络协议类

DST-PORT

按目标端口匹配：

- DST-PORT,80,DIRECT

SRC-PORT

按来源端口匹配：

- SRC-PORT,7777,DIRECT

NETWORK

按协议类型匹配：

- NETWORK,udp,DIRECT

通常用于把 UDP 流量单独分流。

3.4 进程类

这类规则主要出现在桌面端或支持进程识别的平台上。

常见类型有：

  • PROCESS-PATH
  • PROCESS-PATH-WILDCARD
  • PROCESS-PATH-REGEX
  • PROCESS-NAME
  • PROCESS-NAME-WILDCARD
  • PROCESS-NAME-REGEX

例如：

- PROCESS-NAME,curl,PROXY
- PROCESS-PATH,/usr/bin/wget,PROXY

在 Android 平台里，PROCESS-NAME 还可以用于匹配包名。

3.5 入站相关

mihomo 还支持一些与入站监听有关的规则：

  • IN-PORT
  • IN-TYPE
  • IN-USER
  • IN-NAME
  • UID

例如：

- IN-PORT,7890,PROXY
- IN-TYPE,SOCKS/HTTP,PROXY

如果你只是普通客户端使用者，这些规则未必常用；但在自建网关、透明代理、容器网络或多入站场景里会很实用。

3.6 规则集与逻辑规则

RULE-SET

引用一个预定义规则集：

- RULE-SET,reject,REJECT

它本身不会定义内容，而是去引用 rule-providers 里声明的规则集合。

AND / OR / NOT

逻辑组合规则：

- AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT
- OR,((NETWORK,UDP),(DOMAIN,baidu.com)),REJECT
- NOT,((DOMAIN,baidu.com)),PROXY

逻辑规则功能很强，但括号层级容易写错，建议先从简单规则开始。

MATCH

兜底规则：

- MATCH,PROXY

任何前面都没匹配到的请求，最终都会走这里。

4. 附加参数

在 mihomo 中，一些 IP 相关规则还能带额外参数。

no-resolve

只对目标 IP 相关规则生效，例如：

- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve

正常情况下，如果请求先是域名，内核为了判断它是否命中 IP 规则，可能会先做 DNS 解析。
加上 no-resolve 后，可以跳过这一步，避免为了匹配 IP 规则而主动解析域名。

src

把目标 IP 匹配转换为来源 IP 匹配。
这也是偏网关或高级路由场景使用得更多。

5. Rule Providers 是什么

当规则越来越多时，手写到 rules: 下面会很难维护，这时可以把规则拆成独立规则集，通过 rule-providers 引入。

基本结构如下：

rule-providers:
  google:
    type: http
    path: ./ruleset/google.yaml
    url: https://example.com/google.yaml
    interval: 86400
    proxy: DIRECT
    behavior: classical
    format: yaml

rules:
  - RULE-SET,google,PROXY
  - MATCH,DIRECT

常见字段含义如下：

  • name：规则集名称，必须唯一
  • type：来源类型，常见有 http、file、inline
  • url：当 type: http 时必须配置
  • path：本地缓存路径
  • interval：自动更新时间，单位秒
  • proxy：下载规则集时使用哪个策略
  • behavior：规则集内容类型，常见为 domain、ipcidr、classical
  • format：文件格式，常见为 yaml、text，mihomo 还支持 mrs

6. Rule Providers 的三种内容格式

6.1 domain

只存域名类内容：

payload:
  - '.blogger.com'
  - '*.*.microsoft.com'
  - 'books.itunes.apple.com'

这种形式更像“域名列表”。

6.2 ipcidr

只存 IP 段：

payload:
  - '192.168.1.0/24'
  - '10.0.0.1/32'

6.3 classical

可以存传统规则行，也是最灵活的一种：

payload:
  - DOMAIN-SUFFIX,google.com
  - DOMAIN-KEYWORD,google
  - DOMAIN,ad.com
  - SRC-IP-CIDR,192.168.1.201/32
  - IP-CIDR,127.0.0.0/8
  - GEOIP,CN
  - DST-PORT,80
  - SRC-PORT,7777

如果你需要在一个规则集中混合域名、IP、端口等多种规则，通常就会选 classical。

7. 一个可直接参考的完整示例

下面是一份比较典型的“广告拦截 + 国内直连 + 国外代理 + 兜底”的示例：

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

  proxy_sites:
    type: http
    behavior: classical
    url: https://example.com/proxy-sites.yaml
    path: ./ruleset/proxy-sites.yaml
    interval: 86400

rules:
  - DOMAIN,ad.example.com,REJECT
  - RULE-SET,reject,REJECT

  - DOMAIN-SUFFIX,openai.com,PROXY
  - GEOSITE,youtube,PROXY
  - RULE-SET,proxy_sites,PROXY

  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这份配置的逻辑是：

  1. 先拦截明确的广告域名和广告规则集
  2. 再把指定站点与站点集合走代理
  3. 中国大陆 IP 直连
  4. 剩余请求全部代理

8. 实际编写时的建议

  • 优先使用 DOMAIN 和 DOMAIN-SUFFIX，语义清晰，也更容易排查
  • DOMAIN-KEYWORD 和 REGEX 虽然灵活，但容易误伤，尽量少用
  • MATCH 放最后，否则后面的规则根本没有机会执行
  • 大规则集尽量拆到 rule-providers 中维护
  • 调试规则时先检查顺序，再检查策略组名称是否写对
  • 如果 IP 规则表现异常，留意是否触发了 DNS 解析，以及是否需要 no-resolve
  • 如果是普通 Clash 而不是 Premium / mihomo，先确认当前内核是否支持 RULE-SET

9. 参考资料

如果你后面还想继续整理，我建议下一篇可以接着写：

  • proxy-groups 的常见写法
  • rule-providers 与在线规则集的组织方式
  • TUN + DNS + Rules 三者是如何联动的
Discuss on Twitter • View on GitHub