Clash 国内外分流规则实战：国内站点直连、海外服务走代理的完整配置

分流前提：规则、策略组与流量接管

国内外分流不是按网页语言判断去向。Clash 内核读取连接信息，从上到下匹配规则，再把连接交给对应策略。域名、目标 IP、进程信息能否被识别，会影响最终结果。国内网站也可能调用海外接口，海外网站也可能使用本地 CDN，因此应以实际连接为单位排查，而不是只看地址栏。

本文配置面向使用 mihomo 内核的客户端。旧版 Clash 内核与部分移动端客户端支持的字段不完全相同，导入前先查看客户端内核说明。示例使用本地规则文件，避免把远端规则下载故障与分流错误混在一起。

流量接管：系统代理只接管遵循代理设置的应用；TUN 可扩大接管范围，但仍受路由和排除项影响。
规则模式：配置中的 mode: rule 才会按 rules 列表执行。全局模式不能用于验证本文的分流顺序。
策略组：负责选择出口。把域名匹配到一个组，并不代表该组一定正在使用代理节点。
规则集：保存可复用的匹配条件。规则集本身不决定出口，出口由引用它的 RULE-SET 规则指定。

完整主配置：先建立明确的出口

示例环境与文件位置

示例假定本机已经有一个可用的 SOCKS5 上游，监听 127.0.0.1:1080，且不要求认证。mihomo 自身监听 127.0.0.1:7890。这两个端口不能互相指回，否则会形成代理回环。只有配置文件而没有可用上游，并不能产生海外代理能力。

在内核工作目录中保存 config.yaml，并建立 rules 目录。后文的三个规则文件也必须创建。桌面客户端可能管理独立的内核工作目录，相对路径以该目录为准，不一定是订阅文件所在目录。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

proxies:
  - name: 本机上游
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: 海外代理
    type: select
    proxies:
      - 本机上游
  - name: 国内直连
    type: select
    proxies:
      - DIRECT
  - name: 广告处理
    type: select
    proxies:
      - REJECT
      - DIRECT

rule-providers:
  ad-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/ad-domains.yaml
  cn-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/cn-domains.yaml
  overseas-services:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/overseas-services.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
  - DOMAIN-SUFFIX,local,DIRECT
  - RULE-SET,ad-domains,广告处理
  - DOMAIN,cloud.tencent.com,国内直连
  - RULE-SET,cn-domains,国内直连
  - RULE-SET,overseas-services,海外代理
  - MATCH,海外代理

已有订阅节点时，可以让“海外代理”引用订阅提供的节点或策略组，替换示例中的“本机上游”。不要把整个 proxies 段直接覆盖到正在使用的订阅里。部分客户端会在订阅刷新时重写配置，长期修改应通过客户端支持的覆写或合并功能保存；具体入口名称随客户端版本变化。

示例关闭 IPv6 是为了缩小首次排查范围，不代表 IPv6 不能参与分流。示例上游也未提供 UDP 转发；浏览器的 TCP 请求可用于基础验证，游戏、语音和 QUIC 需要另行确认上游协议与接管方式。

规则文件：domain 与 classical 分别怎么写

广告域名文件

将下面内容保存为 rules/ad-domains.yaml。behavior: domain 使用域名集合语法，不写策略名称，也不写 DOMAIN-SUFFIX, 前缀。这里的 +. 表示同时覆盖域名本身及其子域名。

payload:
  - '+.doubleclick.net'
  - '+.googlesyndication.com'

广告规则应保持可回退。某些站点会把统计、登录或播放接口放在关联域名下，扩大拦截范围可能造成页面缺失。若确认是误拦截，可以先把“广告处理”切为 DIRECT 验证，再对具体域名添加例外；不要一开始就删除全部分流规则。

国内直连域名文件

将下面内容保存为 rules/cn-domains.yaml。该列表只覆盖列出的域名树，不能自动识别所有国内站点。添加域名时应查看连接面板中的真实请求，避免把地址栏域名当成页面所有资源的来源。

payload:
  - '+.baidu.com'
  - '+.bilibili.com'
  - '+.bilibili.tv'
  - '+.qq.com'
  - '+.tencent.com'
  - '+.jd.com'
  - '+.taobao.com'

域名分类表达的是路由偏好，不是服务器物理位置证明。例如同一品牌的不同业务可能部署在不同区域。若希望国际业务走代理，应先为该业务添加更精确的域名规则，再放置覆盖整个品牌域名的直连规则。

海外服务文件

将下面内容保存为 rules/overseas-services.yaml。behavior: classical 可以存放带规则类型的条目，但条目末尾仍不写策略名称；引用它的主配置已经指定“海外代理”。

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,githubassets.com
  - DOMAIN-SUFFIX,wikipedia.org
  - DOMAIN-SUFFIX,wikimedia.org

这里把 GitHub 页面、原始内容与静态资源域名分开列出，便于后续为某一类资源调整出口。虽然最终 MATCH 也会把这些连接交给代理，显式规则仍有意义：日志能显示命中的规则集，后续改变兜底策略时也不会改变这些服务的既定出口。

匹配顺序：第一条命中就决定当前连接

规则没有自动的“越精确越优先”排序。DOMAIN 精确规则只有写在较宽泛的规则之前，才能覆盖后者。规则集也不会自动合并冲突：同一个域名同时出现在广告集和直连集时，先被检查的那条引用决定结果。

顺序	匹配内容	处理原因
1	回环与私有 IPv4 地址	让本地服务与常见局域网目标优先直连
2	广告域名集	优先阻断已经确认的广告请求
3	精确业务例外	覆盖后续较宽泛的域名分类
4	国内域名集	明确列入的国内业务直连
5	海外服务集	明确指定需要使用代理的服务
6	MATCH	接住前面所有规则均未命中的连接

例外规则应放在被覆盖规则之前

主配置里的 cloud.tencent.com 是精确业务规则示例。它本来就会被 +.tencent.com 命中，因此当前出口没有改变。如果某个业务需要改走代理，应把这条精确规则的策略改为“海外代理”，而不是把整个腾讯域名集合移到代理组。

若要给广告规则增加放行例外，例外必须放在广告规则集之前。相反，若把 MATCH,DIRECT 放在第一条，后续广告、国内与海外规则都不会再被检查。兜底规则必须收尾。

规则更新与 GEOIP 补充：避免扩大误判

从本地文件切换到 HTTP 规则源

本地 type: file 规则集不会按照时间间隔下载更新。需要自动更新时，应使用 type: http，提供可访问的 HTTPS 规则地址、缓存 path 与 interval。例如 interval: 86400 表示每 86400 秒，即 24 小时检查一次，不代表每天固定零点更新。

选择远端规则源时，先检查内容格式。behavior: domain 对应域名集合，behavior: classical 对应带规则类型的条目；format: yaml 对应含 payload 的 YAML 文件。网页预览地址、完整订阅配置、二进制规则文件不能当成同一种 YAML 规则源使用。下载成功但内容类型不对，仍会加载失败。

规则源只负责匹配条件，不应要求把陌生的完整配置替换为当前订阅。
首次部署先手动更新并查看日志，再依赖定时更新；不要假设缓存一定存在。
远端列表扩大后，应重新检查广告规则、业务例外与国内直连之间的交叉范围。

GEOIP CN 只作为补充

若已准备好内核所需的 GeoIP 数据，可以在 MATCH 前加入 GEOIP,CN,国内直连，为没有命中域名规则的连接补充中国 IP 分类。它依赖目标 IP 与数据库，不能代替业务域名分类。海外服务使用国内 CDN 时可能被划入直连，国内业务使用海外地址时也可能继续走代理。

添加 no-resolve 后，例如 GEOIP,CN,国内直连,no-resolve，该规则不会仅为匹配而主动解析域名。如果连接此时没有可用于匹配的真实目标 IP，规则可能被跳过。因此它能减少部分规则触发的解析，却不是“更准确的国内识别”开关。主配置不依赖 GeoIP，便于先验证基础分流。

验证与排障：先看规则命中，再看连接结果

按四步检查配置

检查语法与文件。使用 mihomo 命令行时，可在示例目录执行 mihomo -t -d . -f config.yaml。桌面客户端则使用其配置检查功能，并确认三个本地规则文件都已加载。
确认接管。启用系统代理，或使用下方显式指定代理的命令。命令可访问而浏览器连接面板没有记录时，应先检查浏览器代理设置，不要急着改规则。
检查当前策略。确认模式为规则模式，“海外代理”当前选择的是可用上游，“广告处理”当前选择的是 REJECT。
重新建立连接。修改规则后关闭原有连接再测试。浏览器可能复用旧连接，策略切换不保证已经建立的会话立即换出口。

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://github.com
curl -I --proxy http://127.0.0.1:7890 https://www.wikipedia.org

Windows 环境若 curl 被终端映射为其他命令，可改用 curl.exe。这些命令测试的是经过 7890 端口的请求，不验证 TUN 接管，也不能仅凭 HTTP 状态码证明整个网站所有资源均可用。

用命中记录定位问题

测试目标	预期规则	预期策略
www.baidu.com	cn-domains	国内直连 → DIRECT
github.com	overseas-services	海外代理 → 本机上游
www.wikipedia.org	overseas-services	海外代理 → 本机上游
ad.doubleclick.net	ad-domains	广告处理 → REJECT

上表是基于示例配置的预期结果，不是实测速度或可用性承诺。广告域名的验证重点是连接被哪条规则处理，不是要求广告服务返回页面。若规则与策略都符合预期，但访问失败，应继续检查上游连接、目标服务和 DNS，而不是反复调整规则顺序。

DNS 与 TUN 的常见干扰

域名规则要求内核能取得域名。应用直接连接 IP、浏览器使用独立加密 DNS，或 TUN 场景中的解析链路未被正确接管，都可能影响域名识别。fake-ip 可通过虚拟地址映射协助恢复域名关系，但需要与客户端 DNS 设置、TUN DNS 劫持和绕过项一起检查，不能只改一个字段就认为所有请求都能按域名匹配。

仅在日志无法定位时临时把 log-level 改为 debug，完成排查后恢复 info。分享日志前清理订阅地址、认证信息与个人访问记录。最终验收应分开确认三件事：连接确实进入内核、命中了预期规则、对应出口确实可用。三者都成立，才算完成一次可靠的国内外分流配置。