Clash 规则分流配置实战:国内直连与海外代理的规则写法

一、配置前确认：内核、规则模式与策略组

“国内直连、海外代理”不是一个能自动判断所有网站归属的开关。它通常由三部分组成：明确的域名规则、域名或 IP 分类数据库，以及最后一条兜底规则。维护目标是让常用国内服务优先直连，让指定海外服务进入代理策略组，再为未分类连接提供可预测的出口。

本文以 mihomo，也就是 Clash Meta 后续使用的内核名称为准。传统 Clash 内核、不同分支以及客户端自带的配置转换器，支持的字段并不完全相同。尤其是 GEOSITE 和地理数据库设置，不能仅凭客户端名称判断是否可用。

确认实际运行的内核。在客户端的“关于”或内核信息页面记录内核名称与版本。配置校验若提示规则类型不支持，应先查内核能力，而不是继续添加相同类型的规则。
选择规则模式。规则分流需要 mode: rule。全局模式通常把连接交给全局策略，直连模式则不按本文的规则选择代理。
确认出站名称。本文使用 Proxy 表示已有代理策略组；名称区分大小写。它必须存在于当前配置的 proxy-groups 中，并且能够选到有效节点。
备份当前配置。订阅生成的配置可能在更新后被覆盖。优先使用客户端提供的持久化覆写、合并配置或规则编辑功能，并检查最终生效配置。

二、规则匹配顺序：从上到下，先命中先处理

在规则模式下，内核按顺序检查 rules。普通分流场景中，一旦找到匹配规则，就按该规则指定的出站处理，不再继续寻找“更精确”的下一条。因此，排序比规则数量更重要：手动例外在前，批量分类居中，MATCH 放在最后。

规则类型	适用对象	关键区别
`DOMAIN`	一个完整域名	精确匹配，不自动覆盖其他子域名
`DOMAIN-SUFFIX`	域名及其子域名	`github.com` 同时覆盖 `api.github.com`
`GEOSITE`	数据库中的域名集合	依赖本地数据库含有对应分类
`GEOIP`	目标 IP 所属地区	不能据此确定网站、账号或运营主体所属地区
`RULE-SET`	规则提供者中的条目	集合定义在 `rule-providers` 中
`MATCH`	此前未命中的连接	作为最后兜底，不代表“海外识别”

先用两条域名规则验证顺序

rules:
  - DOMAIN,api.github.com,Proxy
  - DOMAIN-SUFFIX,github.com,DIRECT
  - MATCH,Proxy

这段配置用于说明优先级：api.github.com 命中第一条并进入 Proxy，github.com 和其他子域名则可能命中第二条直连。如果交换前两条的位置，后缀规则会先接住 api.github.com，精确域名规则也就失去作用。实际部署时，请按需要统一 GitHub 相关出口，不必照搬这个用于对比的例子。

不要把 MATCH,DIRECT 放在规则开头，也不要假定同一域名会自动选择最细的一条。对于广告屏蔽、公司内网、下载站等例外，同样遵循“更具体的需求先写”的原则。

三、基础分流：域名优先，GEOIP 补充，代理兜底

先不引入外部规则文件，可以用少量域名规则建立可验证的基线。下面的目标是：本地私有 IPv4 地址直连，哔哩哔哩相关主域名直连，GitHub 相关常见域名走代理，中国大陆目标 IP 直连，其余连接进入 Proxy。

mode: rule

rules:
  - 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,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,bilivideo.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

`no-resolve` 不是“关闭 DNS”

no-resolve 表示不要仅为匹配这条 IP 规则而主动触发域名解析。如果连接元数据中已有可用于匹配的真实目标 IP，仍可判断其是否落入指定网段或地区；如果目前只有域名且没有可用 IP，这条规则可能跳过，连接继续向下匹配。

因此，上面的 GEOIP,CN,DIRECT,no-resolve 不能保证所有国内域名直连。一个未被域名规则覆盖、当时又没有可用 IP 的国内域名，也可能最终进入 Proxy。补充国内域名集合通常比单纯依赖 IP 分类更可控。若改为允许 IP 规则触发解析，也要同时评估解析路径、耗时与返回地址是否符合预期。

私有网段规则只决定已进入内核的连接出口，不会自动创建局域网路由，也不授予应用访问内网的权限。
这份示例只列出常见私有 IPv4 网段；使用 IPv6 内网时，还需按实际网络补充相应规则。
使用 fake-ip DNS 时，应关注内核恢复的域名与真实解析结果，不要简单把 fake-ip 地址段添加为普通直连网段。
一个服务可能使用多个域名。主站正常而图片、登录或下载失败时，应从连接记录找出遗漏域名，不要直接把整个流量切成直连。

四、加入 GEOSITE：用域名分类补足国内直连

GEOSITE 根据域名集合匹配，不是根据服务器 IP 推测域名归属。它适合放在 GEOIP 前面，让已经分类的国内域名直接选择 DIRECT。但集合内容来自具体数据库，分类名称和覆盖范围不是所有数据源都一致。

在 mihomo 中，可采用下面的局部结构。合并时保留上一节已经确认的本地网段和手动例外；不要把这里较短的 rules 误当成必须覆盖原列表的完整方案。

geodata-mode: true

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

geodata-mode: true 使 GEOIP 使用 DAT 数据模式；在这套用法中，需要可用的 geoip.dat，而 GEOSITE 还依赖 geosite.dat。应确认客户端使用的内核工作目录、数据库加载日志，以及数据源中确实存在 cn 分类。没有该分类时，不能靠更换大小写或反复重启解决。

若日志出现数据库加载失败或分类不存在，先恢复到上一节的基础规则，再修复数据文件。不要在同一次修改中同时更换 DNS、数据库和代理节点，否则很难判断是哪项调整改变了行为。

五、rule-providers 实战：把手动规则拆成可维护文件

规则增加后，将国内直连与强制代理条目拆成两个文件，能减少主配置中的重复编辑。下面采用本地 file 类型，避免把不明来源的规则地址直接加入配置。文件路径以当前内核实际使用的配置目录为基准；通过客户端导入时，还应确认它是否会复制或改写配置目录。

第一步：创建两个规则文件

在内核配置目录下创建 rules 文件夹，将以下内容分别保存为 rules/direct.yaml 和 rules/proxy.yaml。这里使用 classical 行为，所以每一项都包含规则类型，但不包含末尾的出站名称。

# rules/direct.yaml
payload:
  - DOMAIN-SUFFIX,bilibili.com
  - DOMAIN-SUFFIX,bilivideo.com
  - DOMAIN-SUFFIX,qq.com
  - DOMAIN-SUFFIX,jd.com

# rules/proxy.yaml
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,wikipedia.org

第二步：定义提供者并接入规则

下面的片段整合了本地 IPv4 网段、两个规则集合、国内域名分类和 IP 分类。它仍然要求现有配置中已经定义有效的 Proxy 策略组，并且前一节涉及的数据库能够加载。

mode: rule
geodata-mode: true

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

rules:
  - 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
  - RULE-SET,local-proxy,Proxy
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

两份集合都包含同一个域名时，仍按主配置中 RULE-SET 的先后顺序处理。本例将强制代理集合放在国内直连集合前，因此它承担例外覆盖的作用。集合名称只是标识符，不会自动决定优先级。

第三步：检查格式与更新方式

YAML 层级：使用空格缩进，不用制表符。同一份配置只保留一个顶层 rules 和一个顶层 rule-providers，将新增条目合并进去。
行为与内容：classical 文件写 DOMAIN-SUFFIX,github.com 这类完整规则条件；不要把纯域名清单直接混入。domain 和 ipcidr 行为有各自的内容格式。
本地更新：type: file 不会定时向网络拉取内容。修改文件后，通过客户端支持的重新加载或规则集更新操作使其生效，再检查日志。
远程更新：若改用 type: http，还需填写可信的真实 URL、缓存路径和更新间隔。例如 interval: 86400 表示 86400 秒，即 24 小时，而不是 86400 毫秒。

订阅更新与规则提供者更新是两件事。前者可能重建整份配置，后者通常只更新某个规则集合。若规则每次订阅更新后都消失，应检查客户端的覆写合并顺序，而不是反复编辑临时生成的文件。

六、验证分流：看规则、策略链和新连接

网页能打开，只能说明某条访问路径可用，不能证明命中了预期规则。建议先把日志级别设为 info，在连接页面同时检查目标域名、目标 IP、命中规则与出站链。不同客户端的页面名称可能不同，以其实际展示字段为准。

加载前检查语法。若直接管理 mihomo，可在相同工作目录运行 mihomo -t -f ./config.yaml。配置文件名和路径应对应实际文件；GUI 客户端还应使用自身的配置校验功能。
测试直连样本。新访问 www.bilibili.com，检查是否命中 local-direct，并最终使用 DIRECT。页面的其他资源可能命中不同规则，应逐条看记录。
测试代理样本。新访问 github.com，检查是否命中 local-proxy。继续展开出站链，确认 Proxy 当前选择的是代理节点，而不是组内的 DIRECT。
测试兜底。选择一个不在手动集合中的域名，观察它究竟命中 GEOSITE、GEOIP 还是 MATCH。不要事先把“非手动域名”等同于“必定走代理”。
关闭旧连接后复测。规则重载通常不会迁移已经建立的连接。浏览器连接复用、HTTP/2 和 QUIC 会让旧路径继续存在；关闭相关连接或退出应用后再发起请求。

用显式代理区分“流量没进内核”和“规则没命中”

如果配置的 mixed-port 为 7890，可以在终端进行以下两次请求。端口不同就替换为实际值；Windows PowerShell 中可使用 curl.exe，避免与其他命令别名混淆。这里的 7890 是示例端口，并非所有客户端的固定端口。

curl -I --proxy http://127.0.0.1:7890 https://www.bilibili.com
curl -I --proxy http://127.0.0.1:7890 https://github.com

服务器可能对 HEAD 请求返回重定向或拒绝状态，这不影响查看连接是否进入内核。重点是同步观察连接记录。显式代理请求有记录，而浏览器或游戏没有记录，优先检查系统代理、应用自身代理设置或 TUN 接管范围，不要先扩大规则列表。

TUN 模式负责接收符合路由条件的网络流量，不等于强制全部走代理；进入内核后仍需按模式和规则选择出口。系统代理也不是所有应用都会遵守，二者解决的是接入路径问题，而不是替代规则匹配。

七、常见异常与维护顺序

现象	优先检查	处理方向
国内网站仍走代理	是否命中 MATCH、是否仅有域名元数据	补充域名规则，确认 GEOSITE 分类和 no-resolve 的影响
显示 Proxy 却使用本地出口	策略组当前选项与完整出站链	确认组内选中有效代理节点，而不是 DIRECT
修改后行为没有变化	生效配置、当前模式与既有连接	重新加载正确配置，关闭旧连接后复测
规则提供者加载失败	文件路径、payload、behavior 与缩进	先修复本地文件，再处理远程下载问题
部分图片或登录失败	失败请求使用的其他域名及其出口	为必要的关联域名设置一致出口
只有某个应用不按规则走	该应用的连接是否出现在内核中	检查应用代理或 TUN 路由接管，而非先修改分类库

维护时按“接管路径 → 规则模式 → 生效配置 → 匹配条目 → 策略组选项 → 节点连通性”的顺序排查。规则负责选择出口，不能修复失效节点，也不能保证直连线路本身可用。若已经确认命中正确规则，应继续定位对应出口，而不是重复追加同一域名。

需要进一步理解规则模式、监听端口与策略组，可查看代理模式说明、端口说明和策略组说明；订阅更新覆盖问题可从订阅相关排查继续定位。