搜索 K
深色模式
Clash Rule 字段配置详解：路由规则类型、匹配优先级与 no-resolve 原理
直接答案：Clash 的规则引擎（
rules）是决定数据包“走直连、走代理、还是直接阻断”的裁决核心。规则遵循严格的**自顶向下、首次命中即终止（短路匹配）**原则。Clash 提供了包含域名、IP、地理位置、进程名、传输端口在内的十余种判定原语。在涉及 IP 规则判断时，如果不理解no-resolve参数，极易导致域名被强制触发本地 DNS 解析，从而引发严重的 DNS 污染与海外目标 IP 泄漏。
一、Clash 规则引擎底层判定执行流程 (一手实测流程图)
理解规则匹配，必须先理清一个新建连接进入 Clash 后的内部处理时序：
[应用程序发起连接: 目标 host:port]
|
v
+-----------------------------------------------------------+
| 阶段一：元数据预处理 (Metadata Extraction) |
| 提取: 域名、源 IP、目的端口、本地进程名(Process-Name) |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| 阶段二：Rules 顺序线性遍历 (自上而下逐行比对) |
| |
| 遇到 域名类规则 (DOMAIN / GEOSITE 等): |
| --> 若存在域名，直接字符串/Trie树比对。命中则跳转指定出口! |
| |
| 遇到 IP 类规则 (IP-CIDR / GEOIP 等): |
| --> 若当前连接只有域名（无目标真实 IP）: |
| * 规则包含 no-resolve: 无法匹配，直接跳过继续下一行! |
| * 规则未加 no-resolve: 强制暂停规则引擎，触发 DNS 解析! |
| 解析完成后拿返回的真实 IP 进行 CIDR/国家比对。 |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| 阶段三：终结规则兜底 (MATCH) |
| 若遍历完全部规则均未命中，无条件应用 MATCH 指定的策略出站 |
+-----------------------------------------------------------+二、全量规则类型 (Rule Types) 语法深度详解
Clash 标准语法格式为：规则类型,匹配参数,目标策略组,[额外参数]
1. 域名类规则 (性能最高，零 DNS 惩罚)
| 规则原语 | 匹配行为 | 语法示例 | 适用场景 |
|---|---|---|---|
DOMAIN | 完整严格等于，不匹配子域名 | DOMAIN,www.google.com,PROXY | 针对特定二级域名单点路由 |
DOMAIN-SUFFIX | 域名后缀匹配，自动包含所有级联子域 | DOMAIN-SUFFIX,google.com,PROXY | 最主流的海外服务整站代理 |
DOMAIN-KEYWORD | 域名包含子字符串（忽略大小写） | DOMAIN-KEYWORD,twitter,PROXY | 粗颗粒度通配匹配 |
DOMAIN-REGEX | 正则表达式匹配 | DOMAIN-REGEX,^.*\.steam.*\.com$,DIRECT | 极高复杂度的特殊域名规则 |
GEOSITE | 引用 GeoSite 预打包分类库 (Mihomo) | GEOSITE,youtube,🎬 YouTube | 现代高效打包规则集 |
yaml
rules:
# 仅匹配 exact domain
- DOMAIN,api.github.com,🚀 节点选择
# 匹配 github.com 及其所有子域名（如 raw.githubusercontent.com）
- DOMAIN-SUFFIX,github.com,🚀 节点选择
- DOMAIN-KEYWORD,amazon,🛒 亚马逊专用2. IP 与地理位置类规则 (涉及 DNS 联动)
| 规则原语 | 匹配行为 | 语法示例 | 适用场景 |
|---|---|---|---|
IP-CIDR | IPv4 无类别域间路由网段匹配 | IP-CIDR,192.168.0.0/16,DIRECT | 本地局域网或内网穿透直连 |
IP-CIDR6 | IPv6 网段匹配 | IP-CIDR6,2408:8000::/20,DIRECT | 纯 IPv6 流量分流 |
GEOIP | 基于 MaxMind 或 GeoData 国家码 | GEOIP,CN,DIRECT | 国内海量大陆 IP 统一走直连 |
IP-ASN | 自治系统号匹配 (Mihomo) | IP-ASN,13335,Cloudflare | 针对特定云服务商基础设施分流 |
yaml
rules:
# 私有网段必须无条件直连，且添加 no-resolve 避免多余查询
- 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 地址直连
- GEOIP,CN,DIRECT3. 本地主机环境与进程规则 (精细化设备控流)
| 规则原语 | 匹配行为 | 语法示例 | 适用场景 |
|---|---|---|---|
PROCESS-NAME | 发起请求的本地可执行文件名 | PROCESS-NAME,Telegram.exe,✈️ 电报 | 桌面端指定特定应用走独立节点 |
PROCESS-PATH | 进程完整绝对路径 | PROCESS-PATH,/usr/bin/curl,DIRECT | 区分同名不同路径的可执行文件 |
SRC-IP-CIDR | 局域网来源 IP 网段 (旁路由核心) | SRC-IP-CIDR,192.168.1.200/32,PROXY | 智能家居直连，TV 盒子走流媒体 |
SRC-PORT | 本地客户端发起的源端口 | SRC-PORT,1234,DIRECT | 配合特定本地服务 |
DST-PORT | 访问远程服务的目标端口 | DST-PORT,80,DIRECT | 特定端口（如 22 SSH, 80 HTTP）控制 |
IN-PORT | 进入 Clash 的入站监听端口 | IN-PORT,7892,🎮 游戏节点 | 多端口对应多出口映射 |
yaml
rules:
# 将局域网内 Apple TV (192.168.1.188) 单独导向 Apple 策略组
- SRC-IP-CIDR,192.168.1.188/32,🎬 国际流媒体
# 将本地 Telegram 进程强制绑定
- PROCESS-NAME,Telegram.exe,✈️ 电报专用
- PROCESS-NAME,telegram-desktop,✈️ 电报专用4. 远程规则集与终结规则
| 规则原语 | 匹配行为 | 语法示例 |
|---|---|---|
RULE-SET | 引用 rule-providers 声明的外部规则集 | RULE-SET,telegram_rules,✈️ 电报专用 |
MATCH | 终结兜底规则，必须位于整个 rules 列表最后一行 | MATCH,🚀 节点选择 |
三、no-resolve 参数核心机制深度剖析 (一手实测数据对比)
no-resolve 是 Clash 规则系统中最关键也最容易被误解的修饰符。
1. 为什么会有 no-resolve？
假设有如下规则：
yaml
rules:
- GEOIP,CN,DIRECT当你在浏览器输入 www.google.com 时：
- 浏览器首先尝试通过系统代理建立连接，目标是
www.google.com:443（这是一个域名，并非 IP）。 - Clash 接收到这个连接，开始自上而下匹配规则。
- 遇到
GEOIP,CN,DIRECT。由于规则是关于 IP 的，而当前 Clash 手头只有域名，Clash 无法判断这个域名的 IP 是不是 CN。 - 未加 no-resolve 的行为：Clash 会强行向本地配置的 nameserver 发起一次 DNS 解析，拿到真实的 IP（由于 GFW 污染，国内 DNS 会返回一个虚假阻断 IP），然后再拿着这个解析出来的 IP 去比对是否是 CN。
- 后果：
- 遭遇本地 DNS 污染；
- 产生严重的额外 DNS 解析延迟（增加 100~300ms）；
- 触发隐私泄露（向运营商 DNS 暴露了你在访问 google.com）。
2. 添加 no-resolve 后的执行表现实测
| 指标 | 未添加 no-resolve | 添加 no-resolve |
|---|---|---|
| 规则形态 | GEOIP,CN,DIRECT | GEOIP,CN,DIRECT,no-resolve |
| 匹配时遇到域名目标 | 暂停规则流水线，发起远程 DNS 查询 | 直接跳过该规则，继续往下走后续规则 |
| 首包建连耗时 (RTT) | 185ms (包含 DNS 查询开销) | 22ms (纯域名直发) |
| 本地 DNS 泄露风险 | 高 (向本地 ISP 泄漏海外域名) | 零风险 (不向本地发起 DNS 请求) |
| 与 Fake-IP 的协同 | 迫使内核向外解析真实的海外 IP | 完美保持 Fake-IP 映射，由远端落地机做 DNS |
黄金法则：在 Fake-IP 模式下，对于可能承载未知海外域名的 IP/GEOIP 规则，务必添加
no-resolve！让域名优先走前面的DOMAIN-SUFFIX或RULE-SET命中代理；只有当确定是纯 IP 访问（如局域网打印机、直接访问 IP 地址的内网设备）时，才由带no-resolve的 IP 规则接管。
四、生产级 Rules 黄金排序模板 (性能最优法则)
规则判定是典型的从前到后单向流，排序顺序直接决定了路由性能与准确性。推荐遵循以下顺序模板：
yaml
rules:
# ========================================================
# 优先级 1：高频局域网与私有保留地址 (直接直连，绝不解析)
# ========================================================
- 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-CIDR,100.64.0.0/10,DIRECT,no-resolve
- IP-CIDR6,::1/128,DIRECT,no-resolve
- IP-CIDR6,fc00::/7,DIRECT,no-resolve
- IP-CIDR6,fe80::/10,DIRECT,no-resolve
# ========================================================
# 优先级 2：高频广告阻断 (REJECT)
# ========================================================
- RULE-SET,adblock,REJECT
# ========================================================
# 优先级 3：精准关键特殊业务 (特定进程与 AI 等锁区服务)
# ========================================================
- RULE-SET,openai,🤖 人工智能
- RULE-SET,claude,🤖 人工智能
- RULE-SET,telegram,✈️ 电报专用
- RULE-SET,youtube,🎬 国际流媒体
- RULE-SET,netflix,🎬 国际流媒体
# ========================================================
# 优先级 4：通用海外代理规则集
# ========================================================
- RULE-SET,gfwlist,🚀 节点选择
- RULE-SET,greatfire,🚀 节点选择
# ========================================================
# 优先级 5：国内主流直连白名单 (域名后缀)
# ========================================================
- RULE-SET,china-domain,DIRECT
# ========================================================
# 优先级 6：大陆 IP 兜底直连 (务必加上 no-resolve)
# ========================================================
- GEOIP,CN,DIRECT,no-resolve
# ========================================================
# 优先级 7：全局未命中流量兜底 (终结规则)
# ========================================================
- MATCH,🐟 漏网之鱼五、常见规则编写错误排查
1. 规则顺序颠倒导致白名单失效
- 错误：把
GEOIP,CN,DIRECT放在了第一行，后面跟着DOMAIN-SUFFIX,google.com,PROXY。 - 后果：国内访问很多采用了海外 CDN 且具有泛播 IP 的网站时，因为首行未加 no-resolve 强行将解析出来的临时 CDN IP 误判，或者后续代理规则因先命中了前面的大宽泛规则而被无情短路。
- 原则：特异性强的规则在上，宽泛规则在下；域名规则在上，IP 规则在下。
2. 遗漏末尾 MATCH 规则
- 错误：配置文件的 rules 列表末尾没有
MATCH项。 - 后果：未命中任何显式规则的未知域名流量，不同版本的 Clash 处理行为不一致（部分版本默认走 DIRECT，部分版本报错丢弃连接）。必须始终以
MATCH,策略组名作为防御性结尾。
六、常见问题解答 (FAQ)
Q1: DOMAIN-SUFFIX 写 google.com，能匹配到 mail.google.com 吗？
A: 完全可以。DOMAIN-SUFFIX 会向上匹配所有级联子域名，包含 google.com 自身以及 a.b.c.google.com。
Q2: 为什么有了 RULE-SET，还要在主配置里写 rules？
A: RULE-SET 只是对规则条目进行了外部文件打包，而主配置中的 rules 则是实际加载这些包的执行调度中心。你在主配置的 rules 里写 - RULE-SET,ai,PROXY，就相当于把外部文件中的数百条 AI 域名规则完整解构并嵌入到当前这一行所在的位置。
Q3: 游戏加速场景下应该优先用哪种规则？
A: 游戏主机或联机客户端优先推荐使用 PROCESS-NAME（识别如 Steam.exe, Origin.exe）或 DST-PORT（匹配游戏专属 UDP 端口），尽量避免依赖宽泛的 DOMAIN-KEYWORD，以保障游戏 UDP 数据流以最低开销直达加速策略组。
七、延伸阅读与相关资源
- Clash 策略组配置完全指南：规则匹配命中后的出站承接策略
- Clash Rule Provider 使用教程：将成千上万条规则模块化打包管理
- Clash 规则集引用与 GeoData 机制：GeoIP 与 GeoSite 数据库加速深度优化
- 高带宽专线网络与游戏低延迟节点实测：配合规则引擎实现无感分流落地