Clash 规则分流配置详解：从语法到实战的完整规则编写指南

规则是 Clash 系软件最核心的部分，也是最容易出问题的地方。很多「某个网站访问不了」「国内网站反而变慢」的现象，追根溯源都是规则写错了。

这篇会把规则从语法讲到编排策略，尽量让你看完之后不再依赖别人分享的规则集，能自己写出符合需求的规则。

一、规则的基本语法

统一结构

所有规则都遵循同一个格式：

规则类型,匹配值,目标

例如：

- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- IP-CIDR,192.168.1.0/24,DIRECT

目标通常是三种之一：

七种规则类型

二、三种域名规则的选择

这是新手最常混淆的地方，先把它们的区别讲清楚。

DOMAIN（精确匹配）

只有当域名完全一致时才命中。

- DOMAIN,example.com,PROXY

匹配情况：

适用于：你只想精确控制某一个主机名，不希望波及其子域名。

DOMAIN-SUFFIX（后缀匹配）

匹配该域名及其所有子域名。日常使用中最常用。

- DOMAIN-SUFFIX,example.com,PROXY

匹配情况：

注意最后一行：notexample.com 不会被匹配（因为后缀确实是但主机部分不同）。

DOMAIN-KEYWORD（关键词匹配）

只要域名中包含该字符串即命中。

- DOMAIN-KEYWORD,google,PROXY

匹配：

注意它的宽泛性 —— 最后一行的例子说明，关键词匹配很容易误伤。这也是为什么它应该谨慎使用，最好搭配更精确的规则。

选择策略

需要覆盖某服务的所有子域名？ → DOMAIN-SUFFIX（最常用）
只针对单一主机名？          → DOMAIN
不确定具体子域名但知道关键词？ → DOMAIN-KEYWORD（谨慎）

实践建议：能用 SUFFIX 就不用 KEYWORD。关键词规则虽然方便，但误伤率高，且随着规则变多，排查成本会上升。

三、IP 类规则

GEOIP（地理位置）

按 IP 的归属地判断。

- GEOIP,CN,DIRECT

这是国内直连规则的标配。注意几个要点：

• 它需要 DNS 解析结果 — 对于域名请求，需要先解析出 IP 才能判断
• 依赖 GEOIP 数据库的准确性，边界情况可能有误判
• 与 fake-ip 模式的配合会影响行为

IP-CIDR（IP 段）

用于精确的 IP 范围控制，尤其是内网地址。

- IP-CIDR,192.168.0.0/16,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- IP-CIDR,172.16.0.0/12,DIRECT

这三个是 RFC1918 定义的私有地址段，内网直连规则几乎必然包含它们。

还有回环地址：

- IP-CIDR,127.0.0.0/8,DIRECT

GEOIP vs IP-CIDR 的取舍

日常规则里两者通常配合使用：GEOIP 处理地理分流，IP-CIDR 兜住内网和特殊地址。

四、PROCESS-NAME（进程规则）

这是最灵活但也最容易被误解的一类。

它能做什么

按发起请求的应用程序来判断：

- PROCESS-NAME,Game.exe,DIRECT
- PROCESS-NAME,ssh.exe,PROXY

可以实现「某款游戏直连、其他走代理」这类很具体的需求。

重要前提：必须开启 TUN 模式

这是关键点。在系统代理模式下，客户端拿不到发起请求的进程信息，因此进程规则不会生效。

系统代理模式：应用 → 系统代理 → 客户端（不知道是哪个进程）
TUN 模式：    应用 → 虚拟网卡 → 客户端（可以拿到进程信息）

如果你发现进程规则不生效，首先检查 TUN 是否开启。

各平台的写法差异

五、规则编排的核心：顺序决定一切

命中即停原则

规则是从上往下逐条检查，第一条命中就停止。

这意味着顺序错误会导致后面的规则完全失效：

# ✗ 错误示例
rules:
  - GEOIP,CN,DIRECT              # 宽泛规则在前
  - DOMAIN-SUFFIX,example.com,PROXY   # 永远执行不到（若该域名解析到国内 IP）

# ✓ 正确示例
rules:
  - DOMAIN-SUFFIX,example.com,PROXY   # 特例在前
  - GEOIP,CN,DIRECT              # 宽泛规则在后

推荐的编排顺序

一份结构清晰的规则通常遵循这个顺序：

rules:
  # ① 本地与内网（永远直连）
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT

  # ② 需要屏蔽的
  - DOMAIN-SUFFIX,ads.example.com,REJECT

  # ③ 需要代理的特例（放这里，避免被下面的宽泛规则截住）
  - DOMAIN-SUFFIX,specific.service.com,PROXY
  - DOMAIN-KEYWORD,github,PROXY

  # ④ 国内直连（宽泛规则）
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,cn,DIRECT

  # ⑤ 兜底（必须在最后）
  - MATCH,PROXY

每一层的作用：

• ① 本地内网 — 这些不处理会导致访问本机服务出问题
• ② 屏蔽规则 — 需要在消耗流量之前拦截
• ③ 代理特例 — 这是最常需要改动的部分
• ④ 国内直连 — 宽泛规则，必须在特例之后
• ⑤ 兜底 — 处理所有未命中的情况

为什么 MATCH 必须在最后

MATCH 会匹配一切请求。如果放在前面，后面所有规则都不会被执行。这是一条硬性要求，不是建议。

六、常见错误与修正

错误 1：宽泛规则放太前

症状：明明加了代理规则却不生效。

修正：把具体的规则移到宽泛规则之前。

错误 2：忘记内网直连规则

症状：访问本机服务或路由器管理页异常。

修正：确保 # ① 本地与内网 部分完整。

错误 3：滥用 DOMAIN-KEYWORD

症状：意外命中一些无关域名。

修正：改用 DOMAIN-SUFFIX，或把关键词写得更具体。

错误 4：MATCH 位置错误

症状：所有规则似乎都失效。

修正：把 MATCH 移到 rules 的最后一条。

错误 5：进程规则不生效

症状：按进程写的规则没反应。

修正：检查 TUN 模式是否开启（见第四节）。

七、性能优化

规则数量直接影响匹配开销。当规则达到数千条时，优化就变得有意义。

具体建议

关于规则数量

对于普通用户（几百条规则），性能差异几乎不可感知，不必过度优化。规则数量在数千条以上时才需要认真考虑这个问题。

过度追求精简而牺牲可读性，通常是得不偿失的。

八、调试方法

用日志验证命中情况

这是唯一可靠的验证方式。

1. 日志级别切到 debug
2. 访问目标网站
3. 查看日志中的这条输出：

match(DOMAIN-SUFFIX,example.com) using PROXY

它明确告诉你：命中了哪条规则、走了哪个出站。

分步验证法

遇到规则不生效时，按这个顺序排查：

1. 切全局模式测试
   └─ 能访问？ → 确认是规则问题，继续第 2 步
   └─ 不能？  → 问题在节点或配置，规则无关

2. 查看日志中的 match 记录
   └─ 看看实际命中的是不是你期望的那条

3. 检查规则顺序
   └─ 是否有更靠前的宽泛规则抢先命中

4. 单独测试该规则
   └─ 临时把规则移到最前面验证

第 1 步的价值在于快速界定问题范围 —— 如果全局模式也不行，就不用在规则上浪费时间了。

九、规则文件的组织建议

使用 Merge 分离管理

把规则放在独立文件中，通过 Merge 与订阅合成。这样订阅更新时规则不受影响。具体配置方法见《Merge 混合配置实战教程》。

添加注释

YAML 支持注释，务必善用：

rules:
  # 以下三条是为了解决某 NAS 管理页无法访问的问题
  # 添加日期 2026-10-11
  - DOMAIN-SUFFIX,nas.local,DIRECT

三个月后再回头看，你会感谢自己写了这些注释。

版本管理

把规则文件放进 Git 仓库，好处是：

• 改动有完整历史
• 出错能快速回滚
• 多设备间同步方便

注意不要把包含敏感信息的文件提交到公开仓库。

小结

规则这块内容看起来繁杂，但核心其实就三条：

1. 理解三种域名规则的区别 — 大多数日常问题源于选错了类型
2. 记住顺序决定一切 — 命中即停，宽泛规则放后面
3. 用日志替代猜测 — match 记录会直接告诉你答案

掌握这三点之后，你就不需要到处找别人分享的规则集了 —— 自己写的规则最贴合自己的实际需求，而且出问题时你知道每一行在做什么。