Clash 规则分流实战：中国大陆站点直连、境外服务走代理的 rules 写法

1. 先确认规则模式与流量入口

“中国大陆站点直连、境外服务走代理”需要同时满足三个条件：请求已经进入客户端、当前使用规则模式、配置里的规则指向有效出站。只编辑 rules，却仍使用全局模式，不能验证分流结果；浏览器根本没有使用代理时，规则也不会参与处理。

FlClash 使用 mihomo 内核。本文按 mihomo 的规则语法说明，不把旧版 Clash 与当前内核的数据库能力视为完全一致。开始前先备份当前配置，再确认以下项目。

配置已选中：在配置列表确认正在使用的订阅或本地配置，不要修改一个未启用的副本。
出站模式为规则：界面中的规则模式对应配置项 mode: rule；全局模式与直连模式不按下面的规则链分流。
请求进入内核：使用系统代理时，应用必须支持并遵循系统代理；使用 TUN 时，检查虚拟网卡是否启动，以及路由是否接管了目标请求。
代理出站可用：目标策略组必须存在，并选中可连接的代理。规则命中正确不等于上游连接一定成功。

2. rules 从上往下匹配，首次命中决定出站

常见规则格式是“类型、匹配内容、策略”，例如 DOMAIN-SUFFIX,github.com,PROXY。内核按顺序检查，命中一条后通常就确定本次连接的策略，不再继续寻找更靠后的“更精确规则”。因此，专门例外应放在前面，分类规则放中间，兜底规则放最后。

规则类型	判断对象	适合用途
`DOMAIN`	完整域名	只为一个主机名指定出站
`DOMAIN-SUFFIX`	域名后缀	覆盖主域名及其子域名
`GEOSITE`	域名分类数据库	按站点集合分流
`GEOIP`	目标 IP 所属分类	补充分流域名规则未覆盖的地址
`MATCH`	所有剩余请求	最后兜底，不带匹配内容字段

精确域名与后缀的区别

rules:
  - DOMAIN,api.github.com,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,PROXY

第一条只匹配 api.github.com。第二条同时匹配 github.com 和它的子域名，但不会把 notgithub.com 当成同一后缀。上例第一条是演示精确匹配的写法；两条都指向同一策略时，保留后缀规则通常就足够。

DIRECT 是内置直连出站；PROXY 不是固定的内置代理关键字，而是本文约定的策略组名称。实际配置使用其他组名时，必须将示例中的 PROXY 全部替换成配置里已有的准确名称。

3. 先准备策略组，再写大陆直连规则

订阅通常已经包含 proxies、proxy-providers 和 proxy-groups 中的部分或全部内容。不要用一段规则示例覆盖整个订阅文件。先查找 proxy-groups，确认代理组的 name，以及该组当前选择的实际出站。

已有策略组：直接引用名称

如果当前配置已经有名为 PROXY 的可用策略组，可以直接使用后文规则。如果组名是“代理选择”，则规则应写为 GEOSITE,geolocation-!cn,代理选择。组名中的空格和大小写也属于名称的一部分，不能凭显示印象缩写。

手工配置：使用现有代理生成选择组

下面是 mihomo 的策略组片段，前提是配置已经定义有效代理或代理提供者。include-all: true 会把配置中的代理及代理提供者内的代理纳入选择范围，不会凭空创建代理连接信息。

proxy-groups:
  - name: PROXY
    type: select
    include-all: true

将这个条目合并到现有 proxy-groups 列表中，而不是再创建第二个同名顶层字段。加载后检查组内确实有可选代理；如果列表为空，应先修复订阅或代理提供者，再处理规则。不要为了让配置通过而把唯一出站改成 DIRECT，否则“境外代理”最终仍是直连。

4. 一组可调整的大陆直连、境外代理 rules

下面是规则片段，不是完整订阅。使用前需要已有可用的 PROXY 组，并确认 GeoSite 数据包含 cn 与 geolocation-!cn 分类。规则包含局域网 IPv4 地址直连、域名例外、域名分类、IP 补充和最终兜底五层。

mode: rule

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

  # 明确需要代理的域名例外
  - DOMAIN-SUFFIX,github.com,PROXY

  # 先按域名分类
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY

  # 再按已知目标 IP 补充
  - GEOIP,CN,DIRECT,no-resolve

  # 未命中其他规则的连接
  - MATCH,PROXY

为什么域名分类放在 GEOIP 前面

站点业务归属与服务器 IP 所在地并不等价。同一服务可能使用多个地区的 CDN，境外服务也可能有位于中国大陆的接入地址。先让已知域名分类决定出站，再用 IP 规则补漏，可以减少“只看 IP 地区”带来的误分流。对于你明确要求走代理的域名，应放在 GEOSITE,cn,DIRECT 之前。

MATCH 放最后意味着什么

MATCH,PROXY 表示未识别流量默认走代理。这并不保证所有大陆服务都直连：数据库未收录、未获得目标 IP、IP 分类不准确时，请求仍可能落到兜底规则。若改成 MATCH,DIRECT，则未识别的境外服务也可能直连。两种兜底是不同取舍，不应同时写两条期待它们自动判断。

5. GEOSITE、GEOIP 与 no-resolve 的边界

GeoSite 分类依赖数据库，不是实时地理查询

GEOSITE,cn,DIRECT 按域名集合匹配，并不是检测服务器所在国家。geolocation-!cn 也是一个具体分类名，不是把所有其他分类自动取反的通用语法。数据源如果没有这个分类，配置可能在加载时报告分类不存在。

遇到此类错误，先查看客户端日志中的 GeoSite 加载信息，确认数据库已下载、文件可读取且包含所用分类。如果暂时无法确认，可以移除这一条境外分类规则，让剩余流量由 MATCH,PROXY 接住；大陆分类与其他规则仍需保证能正常加载。不要反复添加拼写相近但实际不存在的分类名。

no-resolve 避免额外解析，也会改变匹配机会

GEOIP,CN,DIRECT,no-resolve 的含义是：不要仅为了这条 IP 规则而主动解析域名。若连接已有可用的真实目标 IP，仍可进行判断；若只有域名且没有可用 IP，这条规则不能凭空确定地区，请求会继续向下匹配。

直接连接 IP：目标本来就是 IP 地址时，能够按该地址检查，无须域名解析。
HTTP CONNECT 或 SOCKS 请求携带域名：不能假定进入规则链时已经有真实目标 IP。
Fake-IP 场景：是否能恢复域名与获得真实地址，取决于 DNS 接管、映射状态及规则处理过程，不能只看应用显示的虚拟地址。

如果希望大陆 IP 规则对更多未知域名生效，可以评估去掉该条的 no-resolve，允许内核在需要时解析。但这会引入 DNS 查询，结果也受解析器选择影响。先确定 DNS 请求走向与可达性，再修改，避免把 DNS 超时误判为规则失效。

6. 用连接记录检查命中规则，不凭网页速度判断

加载配置成功后，应针对新连接验证。浏览器可能复用原有 HTTP/2 或 HTTP/3 会话，改变规则不会自动让所有旧连接重新选择出站。关闭目标页面、结束对应连接后再发起请求，结果更容易判断。

确认配置与模式：检查当前配置已重新加载，且仍为规则模式。若加载失败，先处理日志里的 YAML、策略组或数据库错误。
测试局域网地址：访问实际存在的路由器管理地址，例如 192.168.1.1。若请求进入客户端，应看到私有地址规则或其他预期直连规则命中。
测试大陆站点：访问 www.baidu.com，在连接详情查目标域名、命中规则与最终出站，期望是大陆域名分类或大陆 IP 规则对应的 DIRECT。
测试显式例外：访问 github.com，期望命中 DOMAIN-SUFFIX 例外，并通过 PROXY 组内所选代理出站。
区分规则与连通性：如果已经命中 PROXY 但连接超时，继续检查所选代理、DNS 与目标服务，不要先把大陆规则全部删除。

一个网页可能同时请求主站、图片、登录接口和统计域名。主页命中直连，并不代表页面中的所有连接都直连；应分别查看失败请求的域名。这里给出的地址是验证对象，不是对网络时延或成功率的实测承诺。

7. 常见规则冲突与修正方法

现象	优先检查	修正方向
所有连接都走同一个代理	是否为全局模式；前面是否有 MATCH	切回规则模式，把兜底规则移到末尾
新增域名规则没有命中	前面是否已有后缀、分类或规则集命中	把明确例外移到更宽泛的规则之前
加载时提示策略不存在	规则目标与策略组名称是否一致	使用现有组名，检查大小写和空格
大陆站点落到 MATCH	分类是否收录；是否有真实目标 IP	补充域名规则，评估 no-resolve 与 DNS 行为
订阅更新后自定义规则消失	修改是否直接写进订阅生成内容	使用持久化覆写机制或维护独立本地配置
连接列表没有目标请求	应用是否绕过系统代理；TUN 路由是否生效	先修复流量入口，再排查规则

订阅覆写不能只看“添加成功”

不同 FlClash 版本的配置编辑与覆写入口可能不同，应以当前版本实际提供的功能为准。关键是检查最终生效的规则列表：自定义规则必须出现在兜底 MATCH 之前。若某个追加机制把新规则放到 MATCH 后面，即使文件里看得到，也没有匹配机会。

订阅中已有 RULE-SET 时，同样遵循从上到下的顺序。不要为了使用本文示例而删除所有规则集；先识别已有大陆分类、代理分类与兜底规则，再合并重复项。保存一份可恢复的配置，更新订阅后重新核对，能减少规则被覆盖却未察觉的情况。

每次只改一层

建议按“域名例外 → GeoSite 分类 → GeoIP 补充 → MATCH 兜底”逐层验证。先让一个明确域名命中正确策略，再扩大覆盖范围；不要同时更换 DNS、切换 TUN、重写规则和替换代理，否则很难判断是哪一步改变了结果。

最终应保存的不只是规则文本，还包括三个确认结果：当前是规则模式、连接详情显示预期命中规则、策略组内实际出站符合预期。满足这三项，才算完成了一次可复查的大陆直连与境外代理配置。