为什么分流规则是 Clash 的灵魂

很多人第一次用 Clash 时，注意力都放在「节点速度快不快」和「订阅会不会过期」——这两点当然重要，但真正决定日常使用是否顺手、流量是否划算的，往往是 rules（分流规则）这一段。分流规则是一套自上而下的判定流水线：每一条连接在开始转发前，都会在列表里从上到下寻找第一条命中的规则，命中后输出的第三列就是你的策略——直连、某个代理策略组，或者拒绝。

这意味着两件事：其一是顺序比单条规则的“聪明程度”更重要；其二是你只需要搞懂少量高频规则类型——尤其是与域名相关的 DOMAIN 家族、与地理归属有关的 GEOIP、以及与远程文本规则集相连的 RULE-SET——就可以把绝大多数场景配置得相当可靠。本文会从匹配语义、常见写法、优先级与调试思路四个维度，把它们讲透。

术语对齐：本文以基于 Mihomo（Clash Meta）内核的客户端为主讲解，语法与经典 Clash 高度兼容；若你使用仍在维护的 GUI 客户端（如 Clash Verge Rev、FlClash 等），配置形态一致，差异多在界面位置而非底层字段。

规则行的基本格式与策略名

典型规则行由三段组成：规则类型, 匹配内容, 策略。其中「策略」通常是 DIRECT、REJECT，或你在 proxy-groups 里定义的某个组名（例如 Proxy、Apple）。

# Pattern: RULE_TYPE, PAYLOAD, POLICY
DOMAIN-SUFFIX,google.com,Proxy
GEOIP,CN,DIRECT
MATCH,Proxy

写规则时请务必做到「第三列真的能指到存在的名字」——很多看似神秘的“规则不生效”，其实是策略名拼写不一致，或订阅里把组名改成了别的语言标签。建议你在改规则前先在配置中搜索对应的 name: 字段核对一遍。

DOMAIN 系列：从精确主机名到后缀与关键词

与域名相关的规则是日常最常用的一类，因为它们通常在连接建立前就能判定，且语义直观，适合拿来修正常见站点的例外。下面按从严到宽介绍常见成员（不同内核版本可能略有扩展，以下覆盖最核心、最稳妥子集）：

  • DOMAIN：完整主机名精确匹配，适合只影响单站点、又不想波及其子域的情况。
  • DOMAIN-SUFFIX：匹配某个后缀下的所有域名，是最常见的「整站走代理／直连」写法，例如让所有以 google.com 结尾的域名统一走代理。
  • DOMAIN-KEYWORD：只要域名中包含指定子串即命中，覆盖面大，也容易误伤；仅建议用于你非常确定不会产生副作用的关键词。
  • DOMAIN-REGEX（视内核与配置开启情况而定）：用正则表达更复杂的模式，可读性较差，调试成本高，除非你确实需要动态模式，否则优先 DOMAIN / SUFFIX。
DOMAIN,www.example.com,DIRECT
DOMAIN-SUFFIX,cdn.example.net,Proxy
DOMAIN-KEYWORD,internal-corp,DIRECT

实战建议：对「必须在代理前抢先直连」的域名（局域网管理地址、打印机、NAS、公司内网证书站点）优先用 DOMAIN 或极短且确定无副作用的 DOMAIN-SUFFIX；对公开互联网服务，用远程 RULE-SET 维护更省事。

IP-CIDR、SRC-IP-CIDR 与 GEOIP

当域名规则无法覆盖、或你希望按目标 IP 段做兜底时，就会用到基于地址段的规则：IP-CIDR 与 GEOIP 是最常见的组合。

  • IP-CIDR：把某个 CIDR 段指向固定策略，适合处理已知的 CDN 段、特殊的内网映射、或对少数业务做强制直连／代理。
  • SRC-IP-CIDR（可选）：按来源地址匹配，常用于多网卡、旁路由或局域网分设备策略，桌面用户偶尔才会遇到。
  • GEOIP：根据 GeoIP 数据库判断目标 IP 的地理归属；其中 GEOIP,CN,DIRECT 是实现「中国大陆目标尽量直连」的标配写法之一。
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT

注意：no-resolve 用在部分 IP 规则尾部，作用是避免为了匹配该条规则而触发额外的 DNS 解析，从而减轻循环解析或不必要的延迟。是否在每一行都需要，取决于你的 DNS 与 fake-ip 设定；遇到「莫名其妙的解析放大」或规则日志里 DNS 次数异常时，可以把相关 IP-CIDR 改成带 no-resolve 的形式对比观察。

GEOIP 的边界： GeoIP 只能表达「归属地」这一维度，并不能替代业务意图。某些海外服务可能使用中国大陆境内的边缘节点；反过来，某些国内业务也可能经由海外出口。此类「地理与业务不一致」的 corner case，需要用 DOMAIN／RULE-SET 提前覆盖，而不是单靠 GEOIP 硬扛。

RULE-SET 与 rule-providers：把海量列表交给维护者

当你需要「上万条域名级别的精细分流」时，如果把全部内容手写在 rules: 里，文件会迅速变得不可维护。现代 Clash / Mihomo 的做法是：用 rule-providers 声明一段可定期拉取的远程文本，再在 rules 里用 RULE-SET 引用它的名字。

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    interval: 86400
  proxy:
    type: http
    behavior: domain
    url: "https://example.com/rules/proxy.txt"
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,proxy,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

其中 behavior 决定内核如何解释远程文件：

  • domain：文件内是域名或域名类规则集合，匹配路径更直接。
  • ipcidr：文件内是 IP/CIDR 列表，适合大规模地址段。
  • classical：兼容更传统的「每行一条完整 Clash 规则」格式，灵活但体积与性能压力通常更大；除非必须复用历史规则集，新项目更推荐拆成 domain 与 ipcidr 两类 provider。

interval 控制拉取频率（秒）。过短会给 CDN 与本地磁盘带来无意义压力；过长则规则滞后。对大多数用户，86400（一天）是常见折中。若你刚切换规则提供方，记得在客户端里手动触发一次更新，并观察下载是否被网络或证书问题阻断。

匹配顺序、MATCH 与「永远放最后」的铁律

Clash 的规则匹配是单次自上而下扫描：命中即停止。因此推荐的大致骨架是：

  1. 局域网与明确直连的 DOMAIN／IP-CIDR；
  2. 广告与恶意域拦截（若你使用 REJECT 规则集）；
  3. 覆盖面广的 RULE-SET（例如「应代理列表」「应直连列表」）；
  4. GEOIP,CN,DIRECT 等地域类兜底；
  5. 最后一行 MATCH 指向你的默认策略（多数用户是代理组）。
MATCH,Proxy

把 MATCH 提前到列表中间，会导致后续所有规则变成死代码；把更「宽松」的 DOMAIN-KEYWORD 放在精细 DOMAIN 之前，则会让你的例外怎么改都不生效——这类问题在论坛里屡见不鲜，本质是顺序问题而非语法问题。

和 DNS、Fake-IP 的协同（避坑提要）

规则再漂亮，也要和 DNS 配置一起读：域名类规则能否提前命中，与「何时拿到真实 IP」「是否启用 fake-ip」等设置强相关。若你发现某些站点在浏览器里表现为「时而直连时而代理」，除了检查规则顺序，还应观察连接日志里的解析阶段与最终命中的策略是否一致。

实践上可以记住一句糙话：先让规则意图稳定，再微调 DNS。否则你会在 DNS 与规则两层之间来回甩锅，调试成本指数级上升。需要深度优化时，可打开客户端自带的连接面板或仪表盘，核对每一次命中的 RULE 名称与延迟。

调试清单：从「看起来像 bug」里快速脱身

  • 重载配置：改完 YAML 或远程规则集后，务必在 GUI 或 API 层面执行 reload，单纯保存文件不等于内核已读取。
  • 核对策略名：第三列拼写必须与 proxy-groups 完全一致，包括大小写。
  • 核对 provider 名称：RULE-SET,foo,Proxy 里的 foo 必须在 rule-providers 中存在。
  • 看下载日志：远程地址被劫持、TLS 校验失败或 404，会导致规则集停留在旧版本或空集合。
  • 缩减实验配置：临时只保留数十行最小规则重现问题，比在一千行订阅里肉眼搜快一个数量级。

延伸阅读与常见问答（正文版）

若你希望进一步把策略组（如自动测速、故障转移）与规则串起来，可以结合本站关于 proxy-groups 类型的文章一起阅读；规则解决「走哪」，策略组解决「怎么走才稳」。

是否应该无限堆 DOMAIN-KEYWORD？

不建议。关键词命中是「宁可错杀」的 blunt 工具；一旦与服务名称、地区拼写或其他品牌撞车，就会出现难以排查的间歇性问题。能用 SUFFIX、DOMAIN 或可信 RULE-SET 解决，就不要偷懒用 KEYWORD。

可以把所有海外都交给 MATCH 吗？

可以，但不经济。缺少精细化分流会把可直连的海外资源也送进代理，既增加延迟也浪费节点流量。大多数人仍应保留「国内直连／常见业务直连」的一层。

为什么复杂规则更适合放在 Clash 体系里打磨

一些「全局一键」型工具虽然上手快，但往往把分流黑盒化：你想让某个国内金融站点永远直连、或给某类流量单独指定低延迟节点时，会发现修改入口浅、日志不透明，出问题只能反复卸载重装。另一类过度简化的客户端则走向另一个极端——要么只提供寥寥几种模式，要么把高级能力藏得过深，让你在版本升级后才发现旧配置结构不再兼容。

相比之下，Clash 的配置模型把 节点、策略组与规则解耦得非常清楚：订阅负责「有什么路可走」，策略组负责「怎么选路才稳」，规则负责「该不该走这条路」。当你把 DOMAIN、GEOIP 与 RULE-SET 的组合吃透以后，绝大部分需求都可以在一份人类可读的 YAML 里优雅完成，并且可以版本化管理、备份与 diff。更重要的是，活跃的 Mihomo 生态仍在持续演进新协议与新特性，你不会被锁死在几年前的内核上。

如果你希望自己的代理方案在「可解释、可调试、可持续升级」三者之间取得平衡，与其在各类闭源小工具之间来回试错，不如直接选择一条经过社区长期验证的路线：用维护中的 Clash 系客户端承接你的订阅与规则。我们在官方下载页提供了面向多平台的安装包与更新渠道，省去你自己辨别来路的时间成本。

立即免费下载 Clash，开启流畅上网新体验 →