规则分流 预计阅读 10 分钟

Clash 规则分流实战:GEOIP 与 DOMAIN-SUFFIX 搭配实现境内外分流

以真实规则写法演示中国大陆境内直连、境外走代理的分流配置,涵盖规则顺序、MATCH 兜底与 rule-provider 维护。

先确认：连接进入内核，模式设为 Rule

境内外分流不是按软件界面上的节点名称判断，而是让每条进入内核的连接，按域名、目标 IP 等条件选择出口。本文采用“明确的直连域名优先、中国大陆 IP 直连、其余连接交给代理组”的方案。这里的境内外是路由策略的简写，不代表能够准确识别网站的注册地、运营主体或内容所属地区。

Clash for Windows 原项目已停止维护。保留旧环境时可以参考基础规则语法；新建配置则建议先在客户端对比中确认维护状态与内核能力。下文的基础规则适用于常见 Clash 配置，规则集示例以 mihomo 为使用环境，不把现代内核特性当作旧版 CFW 必然具备的功能。

  1. 在 Clash for Windows 的 General → System Proxy 开启系统代理，让遵循 Windows 代理设置的程序进入客户端。程序不遵循系统代理时，需要单独设置代理，或使用已正确配置的 TUN。
  2. 进入 Proxies → Rule，确认运行模式是规则模式。Global 会将连接统一交给全局策略，Direct 则直接连接，二者都不适合验证本文规则。
  3. 在 Profiles 确认当前启用的配置，再检查其中是否已有代理策略组。本文把现有代理组名称记为 PROXY，实际使用时必须改成配置中的真实名称。

DOMAIN-SUFFIX、GEOIP 与 MATCH 各管一层

Clash 规则通常从上到下匹配，遇到能够确定出口的命中项就停止继续查找。不要把规则表理解成会自动比较“哪条更精确”的列表。把宽泛规则写在前面，后面的精确例外便可能没有机会执行。

写法匹配对象注意事项
DOMAIN,example.com,DIRECT完整域名不覆盖 www.example.com。
DOMAIN-SUFFIX,example.com,DIRECT根域名及其子域名匹配 example.com 与 a.example.com，不匹配 notexample.com。
GEOIP,CN,DIRECT目标 IP 在 GeoIP 数据中的归属依赖本地数据；并不表示网站属于中国公司。
MATCH,PROXY前面尚未确定出口的连接应放最后；PROXY 必须是已有代理或策略组。

域名规则不要写成网址

DOMAIN-SUFFIX 后面只写域名，不带 https://、端口和路径。例如给支付宝相关域名设直连，可以写 DOMAIN-SUFFIX,alipay.com,DIRECT，不能写成网页地址。它也不负责判断 URL 中的 /login 或 /video 路径。

域名后缀同样不是地理边界。不能把全部 .com 都当作境外，也不宜仅靠 .cn 判断实际服务器位置。常用服务用明确域名规则处理，其余目标再交给 IP 归属判断，通常更容易检查和维护。

基础配置：先例外，再 GEOIP，最后兜底

下面是主配置中的片段，不是包含节点的完整订阅。使用前先备份当前配置，确认存在名为 PROXY 的代理组。合并时保留原来的节点、DNS 与端口设置；若已有顶层 rules:，应编辑原列表，不要再追加第二个同名键。

mode: rule

rules:
  # 本机与常见局域网 IPv4 地址
  - DOMAIN,localhost,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

  # 本机与局域网 IPv6 地址
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  # 按实际业务增加明确的域名策略
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,alipay.com,DIRECT
  - DOMAIN-SUFFIX,wikipedia.org,PROXY

  # 未被域名规则处理的中国大陆 IP 直连
  - GEOIP,CN,DIRECT

  # 其余连接交给已有代理组
  - MATCH,PROXY

这个顺序让局域网目标先直连，再处理明确的域名例外。随后 GEOIP,CN,DIRECT 承担较宽的 IP 归属判断，最后由 MATCH 收住剩余连接。示例域名只展示写法，不是一份完整的国内服务名单；一个应用可能还使用独立的图片、登录、支付与更新域名。

为什么不把 GEOIP 放在所有域名之前

假设某个业务域名需要固定走代理，但其当前解析地址被 GeoIP 数据归为 CN。若先写 GEOIP 直连，后面的域名代理规则便可能无法生效。相反，把明确业务意图放在前面，再用地理数据补充判断，就能保留例外。

局域网段也要与实际网络相符。示例包含 172.16.0.0/12，并非整个 172.0.0.0/8。不要为了少写几行，把可能包含公网地址的整段都设成直连。上述规则只负责出口选择，不会自动修复 TUN 路由、网卡优先级或防火墙拦截。

GEOIP 后面的 no-resolve：少一次解析，也可能少一次命中

排查分流时，经常会遇到两个版本：GEOIP,CN,DIRECT 和 GEOIP,CN,DIRECT,no-resolve。区别不是地理数据库变了，而是匹配这条规则时，是否允许为判断目标 IP 而主动解析域名。

  • 不加 no-resolve：对于仍需目标 IP 才能判断的域名连接，内核可以进行解析，再按结果查询 GeoIP。上面的基础示例采用这种写法，便于覆盖未列入域名清单的境内服务。
  • 加上 no-resolve：这条规则不会为了自身匹配主动触发域名解析。若当前上下文没有可用的真实目标 IP，便可能继续落到后面的 MATCH。
  • 已经取得 IP：直接访问 IP，或内核在当前连接上下文中已有可用于匹配的地址时，仍可能命中带 no-resolve 的 IP 类规则。具体应看连接详情，不要只看配置文本推断。

因此，不能一边给 GEOIP 加上 no-resolve，一边期待它完整接住所有未列出的国内域名。若希望尽量减少为分流而触发的解析，应先维护足够的域名规则，再接受部分未知域名落入代理兜底的结果。

fake-ip 不等于网站真实地址

启用 fake-ip 时，应用可能看到 198.18.0.0/16 范围内的映射地址。它是内核用于关联域名的虚拟地址，不是网站的真实所在地。不要把整个 fake-ip 地址池加成直连，以此“修复 GEOIP”；应查看内核恢复出的域名、实际解析信息及命中规则。DNS 配置还应与所用内核和客户端版本对应，详见配置参考。

rule-providers：把常用域名规则拆成可维护文件

当规则从十几条增长到几百条，继续把所有域名塞进主配置会增加审查难度。rule-providers 用来声明规则来源，RULE-SET 则在主规则列表里引用它。下面采用 mihomo 支持的本地文件规则集，避免把远程规则下载、定时更新与基础分流混在一起排查。

第一步：在主配置声明并引用

将需要维护的域名移入规则集后，用下面的声明和规则列表替换主配置中的对应部分。local-direct 是自定义规则集名称，引用时必须完全一致；原有局域网规则仍应保留在规则集之前。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,localhost,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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - DOMAIN-SUFFIX,wikipedia.org,PROXY
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

第二步：创建规则集文件

在内核工作目录对应的 rules/local-direct.yaml 中保存下列内容。相对路径通常基于内核工作目录，不一定是下载订阅文件所在的目录；以客户端日志及实际数据目录为准。mihomo 对路径访问有安全限制，优先把文件放在其允许的数据目录内。

payload:
  - DOMAIN-SUFFIX,baidu.com
  - DOMAIN-SUFFIX,qq.com
  - DOMAIN-SUFFIX,alipay.com

这里的 behavior: classical 表示条目采用带规则类型的写法。注意文件里没有尾部的 ,DIRECT：出口由主配置中的 RULE-SET,local-direct,DIRECT 指定。若改用 behavior: domain，条目的格式也必须随之改变，不能只改 behavior 而保留原内容。

本地文件类型不会按远程订阅周期自行获取新内容。编辑后应使用客户端提供的配置重载或规则集重载入口，并检查日志是否成功读取。需要 HTTP 类型规则集时，再配置可信来源、缓存路径与更新间隔；例如 interval: 86400 的单位是秒，表示一天，但来源格式仍须与 behavior 匹配。

订阅更新与规则维护：先确定谁会覆盖谁

直接修改客户端生成的订阅配置，往往在下一次更新时被覆盖。更稳妥的做法是：保留原订阅作为节点来源，在客户端支持的覆写、合并或扩展配置层中维护自己的规则。不同客户端的合并行为不统一，有的替换整段 rules，有的支持前置追加，不能只看保存成功就认为顺序正确。

  1. 先备份：保存原配置以及当前可用的规则集文件，记下正在使用的配置名称。
  2. 检查最终配置：确认 mode: rule、代理组名、规则顺序，以及 rule-providers 声明都出现在实际运行的配置中。
  3. 主动更新一次订阅：更新后重新检查，不要等到第二天发现自定义规则消失才排查。
  4. 每次只改一类内容：先验证域名规则，再增加 GEOIP，最后拆分规则集。发生异常时更容易定位是哪一层改变。

维护 GeoIP 数据与维护域名规则也是两条线。GeoIP 数据更新不能补齐应用新增加的域名；新增域名规则也不能修正过时的 IP 归属。数据库名称、下载方式和更新入口取决于内核，不应直接把另一款客户端的文件名照搬到 CFW 目录中。

验证分流：看命中规则，不凭网页是否打开判断

保存配置后，先重新建立待测连接。已有的长连接通常不会因为修改规则就自动换出口；浏览器连接复用也会让旧结果继续出现。可以关闭对应连接后重试，再打开客户端的 Connections 页面，检查目标域名、命中规则和代理链。各客户端字段名称可能略有区别。

验证场景示例配置下的预期异常时先检查
访问 www.baidu.com命中域名规则或 local-direct，出口 DIRECT域名拼写、规则集加载、前面是否已有拦截规则。
访问 www.wikipedia.org命中域名规则，进入 PROXY 策略组组内当前选项是否为代理节点，而不是 DIRECT。
访问实际路由器地址，如 192.168.1.1进入内核时应命中局域网直连规则若连接列表没有记录，可能被系统代理绕过列表直接放行。
访问未在域名表中的公网目标按 GEOIP 判断，未命中则 MATCH目标解析地址、GeoIP 数据，以及是否存在 no-resolve。

三个常见误判

  • 看到 PROXY 就认为一定走了节点：PROXY 只是组名，组内如果选择 DIRECT，最终仍是直连。应继续看完整代理链。
  • 网页打开就认为所有资源路线一致：主页面、图片和登录接口可能分别连接不同域名，需要逐条查看相关连接。
  • 连接列表里没有记录就认为规则失效：程序可能根本没有进入内核。先确认系统代理或 TUN 接管，再讨论匹配问题。

对一个误分流域名，按“是否进入内核 → 运行模式 → 实际域名与 IP → 命中规则 → 最终出口”的顺序查，通常比反复切换节点更有效。基础方案稳定后，再逐步补齐业务域名和规则集；不要为了追求一份看似完整的规则表，同时引入多组来源不明、优先级重叠的清单。

下载客户端