Clash 规则分流配置实战:按域名后缀与 GeoIP 拆分境内外流量

1. 规则模式与匹配顺序

Clash 分流的基本单位是连接。连接进入内核后，内核根据可获得的目标域名、目标 IP、端口等信息，从上到下检查 rules。首条命中的规则决定使用哪个出站策略，后续规则通常不再参与这条连接的选择。因此，规则顺序比规则数量更重要。

本文使用 Clash 常见的基础规则语法，适用于支持这些字段的 Clash 与 Clash Meta／mihomo 内核。客户端界面名称可能不同，但配置中的 mode: rule、rules 和策略名称仍需对应实际运行配置。扩展规则类型与数据库选项不能据此推定为跨版本通用。

修改前确认三项状态

运行模式：切换到 Rule／规则模式。Global／全局模式不会按本文规则逐条分流，Direct／直连模式也不是规则测试环境。
流量入口：浏览器通过系统代理或显式代理进入内核。需要接管不遵循系统代理的程序时，再评估 TUN 模式。
可用出站：配置内已有可用代理节点，或者有一个包含这些节点的策略组。本文统一将该策略组命名为 境外代理。

系统代理与 TUN 决定哪些连接进入内核；规则决定进入之后如何出站。开启 TUN 不会自动将所有连接改为代理，开启规则模式也不会自动接管系统中所有应用。首先确认连接出现在客户端连接列表，再检查分流结果。

三类核心规则

规则	匹配依据	典型用途
`DOMAIN-SUFFIX`	完整域名及其子域名	指定站点直连或代理
`GEOIP`	目标 IP 在数据库中的地区归属	将 CN 地址归入直连
`MATCH`	全部剩余连接	提供确定的兜底出站

DIRECT 是内置直连策略；境外代理 是用户配置中的名称，不是内核内置关键字。两者都可以写在规则的策略位置，但后者必须已在节点或策略组中定义，并且名称逐字一致。

2. 境内直连、境外代理的基础配置

先备份正在使用的配置，再替换规则部分。下面是需要合并到现有配置的片段，不包含订阅地址、节点凭据和完整策略组。已有 mixed-port 或 mode 时修改原字段，不要在同一层级重复添加。

mixed-port: 7890
mode: rule
log-level: info

rules:
  # 局域网名称与常用本地地址
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,lan,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,qq.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,github.com,境外代理
  - DOMAIN-SUFFIX,githubusercontent.com,境外代理
  - DOMAIN-SUFFIX,wikipedia.org,境外代理

  # IP 地区判断与最终兜底
  - GEOIP,CN,DIRECT
  - MATCH,境外代理

7890 是本文示例的 HTTP／SOCKS 混合监听端口，不代表每个客户端的默认端口。若当前客户端使用其他端口，应保留其实际值。策略组也必须检查：即使规则命中 境外代理，组内当前选择的是 DIRECT，最终仍会直连。

为什么明确域名放在 GeoIP 前面

域名策略表达的是使用意图，GeoIP 表达的是 IP 数据库归类，两者并不等价。假设某个明确要求代理的域名解析到了数据库标为 CN 的地址，如果先检查 GEOIP,CN,DIRECT，连接会提前直连。将明确的域名规则放在前面，才能使站点策略优先于地址归属。

同理，需要直连的企业服务，即使地址位于境外，也可以通过前置域名规则指定 DIRECT。这里的“境内外分流”是默认策略，不是对每个网站的绝对分类。登录、支付、企业专线等服务应根据实际网络要求单独处理。

3. DOMAIN-SUFFIX 的写法与边界

DOMAIN-SUFFIX,qq.com,DIRECT 匹配 qq.com 以及 mail.qq.com 等子域名，不会因为字符串相似就匹配 notqq.com。字段里只写域名，不写 https://、路径、查询参数，也不需要添加 *.qq.com。

精确主机：DOMAIN,login.example.com,DIRECT 只匹配该主机名。
整个域名树：DOMAIN-SUFFIX,example.com,DIRECT 同时匹配根域与子域。
关键词：DOMAIN-KEYWORD 按包含关系匹配，范围更宽，不宜代替精确域名清单。

上面的 example.com 用于说明语法。实际维护时应填入已经核实的业务域名。一个网页可能同时请求主站、图片、接口和对象存储，只有主站域名命中代理，并不意味着所有资源都使用相同策略。例如 GitHub 页面与部分原始文件分别涉及 github.com 和 githubusercontent.com，应在连接列表中逐项确认。

窄范围例外必须前置

rules:
  - DOMAIN,download.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,境外代理
  - GEOIP,CN,DIRECT
  - MATCH,境外代理

这个独立片段演示同一域名树中的例外：下载主机直连，其他子域名代理。若交换前两条规则，后缀规则会先命中，精确主机规则便失去作用。每次新增规则，都应检查其上方是否已有覆盖范围更大的规则。

4. GeoIP、DNS 与 no-resolve 的配合

GEOIP,CN,DIRECT 不是“中文网站直连”，也不是“所有 .cn 域名直连”。它读取目标 IP 的地区归属。域名可能使用境外 CDN，境外站点也可能返回境内地址；数据库更新、地址迁移和 DNS 返回结果都会影响匹配。

传统 Clash 常使用 Country.mmdb 提供 GeoIP 数据。mihomo 还存在与运行模式、版本相关的地理数据库配置。遇到数据加载错误时，应先查看当前内核日志和实际数据库设置，不要把其他客户端的数据库文件名、更新地址或扩展字段直接复制过来。

no-resolve 不等于关闭 DNS

给 IP 类规则添加 no-resolve，含义是不要为了检查该规则而额外解析目标域名。如果连接原本就携带目标 IP，规则仍可依据该地址匹配。它不会禁止应用发起 DNS 查询，也不会修改系统 DNS 设置。

写法	目标为域名时	主要取舍
`GEOIP,CN,DIRECT`	必要时可触发解析以判断地址归属	覆盖域名未命中但 IP 属于 CN 的连接
`GEOIP,CN,DIRECT,no-resolve`	不为该条规则额外发起域名解析	缺少可用目标 IP 时可能继续落入兜底

本文基础配置给局域网网段规则加了 no-resolve，避免仅为检查私有地址而提前解析每个域名；CN 规则则保留解析能力。如果内网名称必须稳定直连，优先添加明确域名规则或正确配置内网 DNS，而不是假设私有地址规则一定会先获得解析结果。

Fake-IP 与域名可见性

Fake-IP 模式由内核维护域名与假地址之间的映射。连接进入内核后，可利用映射恢复对应域名，再进行规则判断。不要把常见 Fake-IP 地址范围 198.18.0.0/16 当成真实境外服务网段，也不要为了“跳过假地址”将它整体强制直连。

相反，如果应用使用自己的 DNS、直接连接 IP，或者连接绕过了预期的 DNS 路径，内核可能没有足够域名信息，DOMAIN-SUFFIX 就不一定参与匹配。mihomo 的嗅探能力可以补充部分连接的域名信息，但不是所有协议都可恢复。应结合连接详情中的域名、目标 IP 与命中规则判断，而不是只看浏览器地址栏。

5. 配置加载、连接验证与日志定位

验证分成两步：先确认配置成功加载，再确认新连接命中预期策略。保存文件不等于客户端已经使用新规则。订阅配置还可能被客户端生成层重新处理，应以运行配置或连接详情为准。

备份：导出当前配置，记录运行模式、监听端口与策略组选择。
检查语法：确认使用半角逗号、空格缩进，并且只有一个顶层 rules。
重新加载：使用客户端的配置重载功能；若失败，先处理日志中的 YAML 或策略名称错误。
创建新连接：关闭测试页面的已有连接后重新请求。旧连接可能继续沿用建立时的出站，刷新页面也可能复用长连接。
核对三项：目标域名或 IP、命中规则、最终出站节点。三者同时正确，才能说明本次分流符合预期。

用明确入口测试，而不是只看公网 IP

如果当前混合端口确为 7890，可以在本机使用以下命令发起一次通过内核的请求。命令只验证这个显式代理入口，不代表其他应用已经接入系统代理或 TUN。

curl --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://github.com/

这里的 10 是连接阶段超时秒数，不是速度测试结果。执行后，在连接列表中查找 github.com，预期命中前置域名后缀规则，再沿 境外代理 策略组到达所选节点。HTTP 返回重定向或其他状态码，并不能单独证明分流错误。

为了验证 GeoIP，可临时选择一个没有被前置域名规则覆盖的测试目标，记录其本次解析 IP，再查看是否命中 CN。不要固定承诺某个公共网站始终命中同一条规则，因为 CDN 地址与数据库内容会变化。若需要验证最后一条 MATCH，同样应以实际连接记录为依据。

6. 常见错误与持续维护

现象	优先检查	处理方式
所有新连接都走同一策略	运行模式、顶部是否出现 MATCH	恢复规则模式，将 MATCH 放到最后
配置重载失败	策略名称、逗号、缩进、重复字段	按日志定位行号，核对实际组名
命中代理组却仍然直连	组内当前选项与嵌套组	确认最终叶子出站不是 DIRECT
域名规则没有命中	内核是否获得域名、是否有更早规则	核查 DNS 路径与匹配顺序
境内服务落入兜底代理	解析地址、GeoIP 数据、no-resolve	按证据修正数据库或添加域名例外
订阅更新后规则消失	修改的是订阅原文还是持久覆写	使用客户端支持的覆写或合并机制

订阅更新与规则合并

订阅提供的是配置或节点数据，规则是否保留取决于客户端的配置处理方式。直接编辑一次性生成的文件，下一次更新可能覆盖修改。应使用客户端明确支持的持久覆写、脚本或规则合并功能，并检查它是“前置”“后置”还是“整体替换”。将新增规则后置到已有 MATCH 后面，语法可以成立，分流却不会生效。

规则数量增多后，可以评估规则集管理。mihomo 支持通过 rule-providers 加载规则集，再用 RULE-SET 引用；具体行为类型与文件格式必须匹配。不要把只有一列域名的文件当成任意格式通用规则集，也不要为了解决一条域名例外就直接替换整套规则体系。

最终检查清单

精确业务例外在前，通用 GeoIP 在后，MATCH 位于末尾。
域名规则不含协议与 URL 路径，策略名称与实际配置一致。
IPv4 与 IPv6 分别核查，不因某次 IPv4 成功就推定双栈路径均正确。
每次只调整一组相关规则，重载后使用新连接验证，再继续修改。
记录命中规则和最终节点；遇到超时，再分别检查代理节点、DNS 与目标服务可达性。

基础分流的稳定结构是：本地与业务例外优先，域名策略其次，GeoIP 处理未覆盖地址，MATCH 提供最终出口。需要进一步核对字段时，可查看协议参考；若尚未完成客户端与代理入口配置，先按配置教程确认流量已经进入内核。