规则分流 预计阅读 14 分钟

Clash 规则分流实战:国内直连、国外代理的完整配置思路

以国内外分流为场景,讲清 GEOIP、GEOSITE 与规则集的配合方式,给出可直接套用的策略组结构,并说明验证分流是否生效的排查步骤。

先确定分流目标：按域名判断，按 IP 补漏

“国内直连、国外代理”不是把全部流量简单分成两个地区。Clash 实际处理的是连接请求，每个请求可能只带域名、只带目标 IP，或者先经过 DNS 解析再建立连接。可靠的配置通常先用域名规则识别目标，再用 IP 归属规则补漏，最后用一条兜底规则处理未命中的流量。

以 Clash Meta，也就是目前常见的 mihomo 内核为例，一次连接会按照 rules 中的顺序自上而下检查。首条命中的规则立即决定该连接进入哪个策略组，后面的规则不再执行。因此，规则类型是否齐全只是基础，排列顺序同样决定最终结果。

流量类别 建议动作 主要判断依据 典型例子
局域网与本机地址 DIRECT 私有域名、私有 IP 段 192.168.1.1、10.0.0.0/8
明确的国内站点 DIRECT GEOSITE 或域名规则集 国内视频、支付、地图服务
解析到中国大陆的 IP DIRECT GEOIP,CN 未被域名库收录的国内服务
明确指定代理的服务 PROXY 独立域名规则或规则集 需要固定走代理的开发服务
其余未命中连接 PROXY MATCH 新域名、冷门域名、未知目标

为什么不能只写 GEOIP,CN

GEOIP,CN,DIRECT 只能在内核获得目标 IP 后判断归属。如果连接仍处于域名匹配阶段，或者 DNS 使用 Fake-IP 模式，单靠 GEOIP 不能完整表达域名级分流。另外，CDN 节点的位置不一定等于服务所属地区：同一个域名可能因网络、时间和 DNS 结果不同而返回不同地区的 IP。

更稳妥的结构是“域名优先、IP 补漏”。先用 GEOSITE,cn,DIRECT 或国内域名规则集处理已知站点，再用 GEOIP,CN,DIRECT 接住未收录但解析到国内地址的连接。这样既减少不必要的 DNS 依赖，也能覆盖只有 IP 的访问请求。

GEOIP、GEOSITE 与 RULE-SET 分别负责什么

GEOIP：按目标 IP 的地区归属匹配

GEOIP 规则查询的是 IP 地址与地区代码之间的映射。常见写法是 GEOIP,CN,DIRECT，含义是目标 IP 被识别为中国大陆地址时使用直连。它适合作为国内流量的补漏规则，但不适合独立承担全部域名分流。

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve 参数表示匹配这条 IP 规则时，不为了取得目标 IP 而主动解析域名。例如 GEOIP,CN,DIRECT,no-resolve 可以避免规则匹配阶段触发额外 DNS 查询，但当请求本身只有域名时，这条规则也可能无法命中。是否添加该参数，应结合前面是否已有完整的域名规则判断。

GEOSITE：按域名集合匹配

GEOSITE 是 mihomo 等内核支持的域名分类机制。GEOSITE,cn,DIRECT 会把 geosite 数据库中归入 cn 分类的域名交给直连策略。它不根据域名当前解析到哪个 IP 判断，因此更适合表达“某个服务属于哪一类站点”。

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GEOSITE 能否正常使用取决于内核和地理数据文件。旧版 Clash 内核、不同分支客户端以及 mihomo 的数据模式并不完全一致。配置报出 unsupported rule type GEOSITE 时，不应继续调整规则顺序，而应先确认客户端使用的内核类型，并在客户端的内核或地理数据更新入口完成更新。

RULE-SET：把外部规则文件接入主配置

当规则数量达到数百或数千条时，不适合全部堆在主配置的 rules 下。rule-providers 可以定义单独的规则文件，再通过 RULE-SET 引用。这样便于更新、分组和检查，也能避免每次维护规则时改动策略组与 DNS 配置。

rule-providers:
  cn-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml

  direct-extra:
    type: file
    behavior: classical
    format: yaml
    path: ./ruleset/direct-extra.yaml

rules:
  - RULE-SET,direct-extra,DIRECT
  - RULE-SET,cn-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain 适合只包含域名条目的规则集；behavior: ipcidr 用于 IP 网段；behavior: classical 可以保存 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等完整规则。规则文件的行为类型必须与内容一致，否则可能出现加载失败或条目不匹配。

一个本地域名规则文件可以写成：

payload:
  - '+.bilibili.com'
  - '+.jd.com'
  - '+.taobao.com'
  - 'cn.bing.com'

这里的 +.example.com 表示主域名及其子域名。若只需要匹配一个精确主机名，应写完整域名而不是后缀形式。修改文件后还要在客户端执行配置重载；只保存文件而不重载，正在运行的内核不会自动采用新规则。

可直接调整的策略组与规则骨架

下面的配置采用一个主代理组、一个自动测速组和一个兜底规则。节点名称需要与订阅实际提供的名称对应。如果客户端通过订阅生成代理节点，通常应在订阅覆写或配置合并功能中加入策略组，而不是直接修改会被下次订阅更新覆盖的临时文件。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
      - 香港节点
      - 日本节点
      - 新加坡节点

  - name: AUTO
    type: url-test
    proxies:
      - 香港节点
      - 日本节点
      - 新加坡节点
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mode: rule 是启用规则分流的前提。如果客户端当前处于 Global 模式，所有连接会统一进入全局策略组；如果处于 Direct 模式，所有连接会绕过代理。很多“规则没有命中”的问题，实际原因只是运行模式没有切换到 Rule。

url-test 会按指定地址周期性测试节点延迟。示例中的 interval: 300 表示每 300 秒测试一次，tolerance: 80 表示当前节点与更快节点的延迟差超过 80 毫秒时才考虑切换。频繁测速会增加连接和耗电，桌面端设置为 300 至 600 秒通常更合适。

使用订阅提供器时的策略组写法

如果节点来自 proxy-providers，策略组可以通过 use 引用提供器，避免把每个节点名称写入主配置。以下结构假设配置中已经存在名为 airport 的代理提供器：

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - airport

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

订阅更新后，新节点会进入引用该提供器的策略组。若客户端支持配置合并，建议把自定义规则和策略组放在覆写文件中；具体入口通常位于「设置」→「配置」→「覆写」或「订阅」→「配置编辑」。不同客户端菜单名称会有差异，但原则相同：保留原始订阅，把本地分流逻辑作为独立合并层。

DNS 与 Fake-IP 对分流结果的影响

规则看起来正确，但国内网站仍走代理时，DNS 是必须检查的一层。Clash 接管 DNS 后，域名解析、规则嗅探和连接建立会互相配合。若系统 DNS、浏览器安全 DNS和 Clash DNS 同时工作，部分请求可能绕过内核的域名判断，最终只留下 IP 信息。

mihomo 常用的 Fake-IP 配置如下。监听端口 1053 避免直接占用系统的 53 端口，客户端再负责把系统 DNS 请求转发到该监听地址：

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

Fake-IP 模式会先向应用返回 198.18.0.0/16 范围内的保留地址，再由内核保存 Fake-IP 与原域名的映射。这样即使应用随后连接的是 IP，内核仍能恢复域名并执行 DOMAIN、GEOSITE 或域名规则集。局域网设备发现、打印机、部分登录组件不适合 Fake-IP 时，可以加入 fake-ip-filter。

浏览器安全 DNS 为什么会干扰判断

浏览器启用独立的 DoH 后，DNS 查询可能作为 HTTPS 流量发往浏览器指定的解析服务。Clash 仍然可以代理这条 HTTPS 连接，但未必能获得后续业务域名与系统 DNS 一致的映射。排查期间可临时关闭浏览器的安全 DNS，或把它设为“使用当前服务提供商”，然后清理浏览器 DNS 缓存并重新测试。

Windows 可先执行 ipconfig /flushdns 清理系统缓存；Chromium 系浏览器需要完全关闭相关进程后重开，才能排除仍由旧连接复用导致的误判。修改 DNS 配置后，还应在客户端执行「配置」→「重载」，再断开并重新连接系统代理或 TUN。

系统代理与 TUN 模式应该怎样选择

系统代理通常把 HTTP 和 HTTPS 请求发送到 mixed-port: 7890。遵循系统代理设置的浏览器、下载器和开发工具可以正常进入 Clash，但部分游戏、命令行程序、商店应用以及自行实现网络栈的软件可能绕过系统代理。

TUN 模式通过虚拟网络接口接管更广范围的 TCP、UDP 和 DNS 流量，适合需要统一分流的桌面环境。mihomo 的基础配置可以写成：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed 兼顾系统栈兼容性与 UDP 处理；auto-route 自动写入路由；auto-detect-interface 用于识别当前出口网卡；strict-route 可减少流量绕过 TUN 的情况。启用 TUN 通常需要管理员权限，首次启动还可能触发虚拟网卡或网络扩展授权。

场景 建议模式 检查重点
主要使用浏览器和遵循系统代理的软件 系统代理 HTTP 代理是否指向 127.0.0.1:7890
命令行、商店应用、游戏需要统一接管 TUN 管理员权限、虚拟网卡、路由表
只想验证规则配置 先用系统代理 减少路由与 DNS 劫持变量
启用 TUN 后局域网设备不可访问 检查 strict-route 与私有网段规则 GEOSITE,private、GEOIP,private

怎样确认国内直连、国外代理已经生效

第一步：确认运行模式与配置已经重载

  1. 在客户端首页确认运行模式为 Rule 或规则模式。
  2. 进入「配置」→「当前配置」，确认启用的是刚刚编辑的文件。
  3. 执行「配置」→「重载」；如果刚修改过 TUN，则断开后重新连接。
  4. 把日志级别临时设为 info，不必一开始使用输出量更大的 debug。

第二步：在连接列表检查命中链路

打开客户端的「连接」或「Connections」页面，分别访问一个国内站点和一个需要代理的站点。国内请求应显示类似 GEOSITE,cn → DIRECT、RULE-SET,cn-domain → DIRECT 或 GEOIP,CN → DIRECT；其余请求应显示 MATCH → PROXY → 具体节点。

一个网页通常会同时请求主站域名、图片 CDN、统计接口、登录接口和第三方资源，因此连接列表中同时出现 DIRECT 与 PROXY 并不一定是错误。判断时应选中具体连接，核对目标域名、命中规则、策略组和最终节点，而不是只看页面对应的主域名。

第三步：用命令行绕过浏览器缓存

系统代理模式下，可以显式指定本地混合端口测试。下面两个命令都会通过 127.0.0.1:7890 进入 Clash，随后由规则决定直连还是代理：

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://www.google.com/generate_204

运行命令时同步观察连接面板。第一个请求通常应命中国内域名规则或国内 IP 规则，第二个请求应进入 PROXY。HTTP 状态码只说明目标是否响应，真正的分流结论仍以连接详情中的规则链路和最终策略为准。

常见异常与定位顺序

国内网站全部进入 PROXY

国外网站显示 MATCH，但仍然无法访问

命中 MATCH,PROXY 只表示规则选择正确，不代表策略组中的节点可用。继续展开连接链路，确认 PROXY 最终选中了哪个节点。若停在 DIRECT，说明策略组被手动切换到了直连；若已选节点但连接超时，则应检查节点状态、订阅更新和节点对目标协议的支持。

规则文件更新后没有变化

开启 TUN 后局域网设备访问失败

先确认私有地址规则位于其他宽泛规则之前，并覆盖常见网段。常见私有地址包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。若访问的是带有 .local 后缀的设备，还应把对应域名加入 Fake-IP 过滤列表。之后检查系统防火墙是否把新建的 TUN 网卡识别为公用网络并限制了局域网通信。

配置维护建议：保留可控的最小结构

国内直连、国外代理并不需要不断增加规则类型。对大多数配置而言，私有地址直连、国内域名直连、国内 IP 补漏、指定服务例外和最终代理兜底已经足够。规则越多，越需要明确来源、更新时间和优先级，否则一次规则集更新就可能改变原有行为。

建议把自定义内容拆成三层：订阅负责提供节点，策略组负责选择节点，规则集负责决定流量进入哪个策略。订阅更新时不要覆盖本地规则；规则集更新时不要重写代理节点；切换节点时也无需修改规则。三层职责分离后，问题会稳定落在“节点不可用”“策略选错”或“规则未命中”中的某一层。

完成配置后，至少保存三项可复查信息：当前内核名称与版本、实际加载的配置文件、一次国内请求和一次代理请求的连接详情。后续出现异常时，这些信息比单纯描述“网站打不开”更有定位价值。

下载 Clash 按平台选择客户端