进阶分流 预计阅读 13 分钟

Clash 国内外规则分流配置：策略组、规则集与兜底顺序实战

围绕直连、代理、拦截和漏匹配兜底设计规则顺序，并说明规则集订阅与策略组联动方式。

Clash 的规则分流不是简单地把“国内域名”设为直连、把“国外域名”交给代理。真正决定连接去向的是三层结构：规则负责识别流量，策略组负责选择出口，代理节点或内置动作负责执行。任何一层的名称、顺序或引用关系不一致，都会表现为网站走错线路、局域网服务被代理、应用连接超时，或者切换节点后部分连接仍沿用旧路径。

以下配置思路适用于支持规则模式的 Clash 客户端，也适用于以 Clash Meta 名义传播、当前通常称为 mihomo 的内核。不同客户端的图形界面名称可能不同，内核版本对规则类型、规则集格式和进程匹配能力也有差异。修改前应确认客户端实际使用的内核，并保留一份能够正常启动的配置。

先确定直连、代理、拦截与兜底模型

一份便于维护的国内外分流配置，至少要明确四种处理结果。第一类是 DIRECT，连接直接交给本地网络；第二类是自定义代理策略组，例如 PROXY；第三类是 REJECT，用于阻断确定不需要访问的域名或网段；第四类是最终兜底策略，用来接收前面所有规则均未命中的流量。

DIRECT 并不等同于“国内”。局域网地址、打印机、路由器管理页和公司内部系统通常需要直连，但某些国内服务可能因账号区域、办公出口或测试需求而指定代理。反过来，一些海外站点也可能通过当前网络直接访问。因此，地域规则适合承担大范围基础判断，业务例外应放在地域规则之前。

DIRECT

直连出口

由系统当前网络直接建立连接，适合局域网、国内常用服务和明确要求本地出口的业务。

PROXY

代理策略组

把连接交给选定节点或自动选择组，策略组名称必须与规则中的目标名称完全一致。

REJECT

拦截动作

直接拒绝匹配连接。应使用边界明确的规则，避免过宽规则影响登录、支付或资源加载。

MATCH

漏匹配兜底

处理此前没有命中的连接，必须放在规则列表末尾，否则后续规则不会得到匹配机会。

用策略组隔离节点选择与业务意图

规则中直接填写单个节点名称可以运行，但维护成本较高。订阅更新后节点名称可能改变，多个规则也会重复绑定同一个具体节点。更稳定的方式是让规则引用语义明确的策略组，再由策略组选择节点、自动测速组或其他策略组。

常见结构包括总入口 PROXY、自动测速组 AUTO、手动选择组，以及按业务划分的媒体、办公或开发服务组。业务规则只指向业务策略组，节点调整则在组内完成。这样既能保持规则文件稳定，也能在客户端界面中临时切换出口。

mode: rule

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

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

  - name: MANUAL
    type: select
    use:
      - airport

上例中的 airport 必须在 proxy-providers 中已经定义。use 引用的是代理提供器，不是规则提供器。url-test 会按测试结果选择符合条件的节点，但延迟最低不代表所有业务吞吐最高；如果目标服务对出口地区有要求，应建立地区组或手动选择组，不要只依赖全局测速结果。

允许 PROXY 选择 DIRECT 便于临时诊断，但也意味着用户切换该组后，所有引用它的规则都会改变出口。对必须固定代理的业务，可单独建立不包含 DIRECT 的策略组。对必须直连的流量，则让规则直接指向 DIRECT，避免受总策略组切换影响。

策略组名称必须保持单一写法

YAML 中的名称区分字符内容。规则写成 PROXY，策略组却命名为 Proxy，不会被视为同一个目标。中文名称、空格和符号通常可以使用，但跨客户端迁移时，简短的英文大写名称更便于检查。若名称中包含特殊字符，建议使用引号，并在规则、策略组和脚本引用中保持一致。

规则集订阅与策略组的联动方式

rule-providers 用于声明可复用规则集。它与节点订阅承担不同职责：节点订阅提供代理服务器信息，规则集提供域名、IP 网段或经典规则条目。规则集本身不决定出口，只有在 rules 中通过 RULE-SET 引用，并指定 DIRECT、PROXY 或其他策略后，才会参与连接决策。

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/reject.yaml
    url: https://example.com/rules/reject.yaml
    interval: 86400

  cn-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml
    url: https://example.com/rules/cn-domain.yaml
    interval: 86400

  cn-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/cn-ip.yaml
    url: https://example.com/rules/cn-ip.yaml
    interval: 86400

示例地址只用于展示字段结构，实际配置应使用规则维护方提供的原始文件地址。path 是规则集的本地缓存位置；客户端必须对相应目录具备写入权限。interval 通常以秒为单位，设置为一天可以减少频繁请求。规则更新频率应结合上游维护节奏确定，过短间隔不会提高匹配精度。

behavior 决定规则集内条目的解释方式。domain 适合域名及域名后缀集合，ipcidr 适合 IPv4、IPv6 网段，classical 则可容纳带类型的经典规则。文件内容必须与声明的行为和格式匹配。把域名列表声明成 ipcidr，或者把经典规则文件当作纯域名集合读取，通常会触发解析失败或导致规则无法命中。

规则顺序：从具体例外到范围兜底

Clash 规则按列表从上向下检查，第一条命中的规则立即决定处理策略。它不会比较所有规则后再选择“最精确”的一条。因此，顺序设计应遵守“具体例外在前，宽泛集合在后，最终兜底位于末尾”的原则。

推荐的基础顺序是：明确拦截项、局域网与私有地址、必须直连的业务、必须代理的业务、国内域名集合、国内 IP 集合、其他地域或代理集合，最后是 MATCH。具体项目可以调整分类，但不能把宽范围规则放到它应覆盖的例外之前。

rules:
  - RULE-SET,reject-list,REJECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  - DOMAIN-SUFFIX,service-needs-proxy.example,PROXY
  - DOMAIN-SUFFIX,service-needs-direct.example,DIRECT

  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,proxy-domain,PROXY
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  - MATCH,PROXY

上例中的业务域名同样用于说明顺序，部署时应替换为实际需要控制的域名。若“必须代理”的域名同时存在于国内域名规则集，它必须放在 cn-domain 之前，否则会先命中直连。若某个拦截规则范围过宽，则登录接口、静态资源或验证码域名可能先被拒绝，即使后面存在代理规则也不会继续判断。

DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配指定域名及其子域名，DOMAIN-KEYWORD 只检查域名中是否包含关键词。关键词规则覆盖范围大，容易误伤名称相似但业务无关的站点，通常应优先使用完整域名、后缀或经过维护的规则集。

IP-CIDR 和 GEOIP 属于 IP 维度判断。附加 no-resolve 可以避免规则为了获得目标 IP 而主动触发额外解析，但也意味着该规则只在内核已经取得目标 IP 时参与匹配。是否添加该参数，应结合 DNS 模式、连接元数据和内核行为验证，而不是机械地复制到每一条规则。

MATCH 应该直连还是代理

兜底走向取决于配置目标。面向“国内直连、其余代理”的常见模型，可使用 MATCH,PROXY，这样新出现且尚未进入规则集的域名会先进入代理策略。若环境要求默认直连，仅对少量业务代理，则可使用 MATCH,DIRECT，但必须确保需要代理的规则覆盖完整。两种模式没有通用优劣，关键是未知流量出现时应采用哪种风险更可控的出口。

DNS 与 TUN 模式对分流结果的影响

规则顺序正确但访问结果仍异常时，需要检查 DNS。域名请求、解析结果和实际连接可能经过不同路径。如果系统 DNS 返回受网络环境影响的地址，域名规则虽然命中了预期策略，后续连接仍可能超时。使用 Clash 内置 DNS 时，应确认 nameserver、proxy-server-nameserver、回退解析和规则分流之间的关系，并从内核日志观察查询实际交给了哪个服务器。

在 fake-ip 模式下，内核向应用返回保留地址，并在连接阶段根据映射恢复目标域名。这样有利于域名规则稳定参与判断，但部分局域网设备、局域网域名、游戏平台或依赖真实 IP 的应用可能需要加入 fake-ip-filter。过滤项不应无限扩大；范围过大时，越来越多请求会退回真实 IP 解析，域名分流的一致性也会降低。

redir-host 模式直接向应用返回真实解析地址，兼容路径与 fake-ip 不同。切换模式后，旧 DNS 缓存和既有连接可能继续存在，因此测试前应断开相关应用连接，并按操作系统情况清理 DNS 缓存。仅刷新浏览器页面不一定会重新建立完整链路。

TUN 模式负责接管更多系统流量，但不会改变规则从上到下匹配的基本逻辑。启用 TUN 后，原本绕过系统代理的应用也可能进入 Clash，规则命中数量因此增加。如果应用只提供目标 IP，域名规则可能缺少可用元数据；支持嗅探的内核可以从部分 HTTP 或 TLS 流量恢复主机信息，但嗅探并非对所有协议都有效。

遇到“浏览器分流正常，命令行或桌面应用走错线路”时，应依次确认该程序是否进入内核、TUN 路由是否生效、域名是否被识别、最终命中了哪条规则。不要只依据网页显示的出口地址判断整个系统，因为不同进程可能使用系统代理、直连套接字、QUIC 或独立 DNS。

按连接日志验证，而不是凭访问结果猜测

分流配置完成后，最有效的验证方式是查看客户端连接面板或内核日志。每次测试应记录目标主机、命中规则、选择的策略组、实际节点和连接结果。只看到“能打开”不能证明规则正确：目标可能支持直连，也可能使用缓存、备用域名或已经建立的长连接。

  1. 确认配置已加载。查看配置更新时间与内核日志，排除 YAML 缩进、字段拼写、规则集下载或策略组引用错误。
  2. 固定测试策略。临时给 PROXY 选择一个状态明确的节点，避免自动测速组在测试过程中切换出口。
  3. 测试局域网和私有地址。确认路由器管理页、局域网设备及内部域名命中 DIRECT，并检查 TUN 是否错误接管保留网段。
  4. 测试国内域名与 IP。观察是域名规则集、IP 规则集还是 GEOIP 命中。若直接落到 MATCH，说明规则集内容或域名识别路径需要检查。
  5. 测试强制代理例外。确认它位于国内大集合之前，并实际命中指定策略组，而不是被前面的后缀规则提前截获。
  6. 测试未知域名。选择不在自定义规则中的目标，确认最终由 MATCH 接收，借此验证兜底策略。

常见现象与对应检查点

现象 优先检查 处理方向
国内站点进入代理 国内规则集是否加载、是否位于 MATCH 前 检查 provider 状态、规则引用名称与域名实际命中项
指定域名不能强制代理 前面是否存在更宽的直连后缀规则 把具体代理例外移到宽泛直连集合之前
局域网地址连接超时 私有网段规则与 TUN 路由 补充私有地址直连，并核对自动路由及接口选择
规则集显示更新失败 URL 响应、格式、behavior 与缓存目录 确认返回的是规则文件，并检查内核支持和目录权限
切换策略后结果未变化 既有连接、DNS 缓存和应用连接池 终止旧连接后重新测试，必要时清理系统 DNS 缓存

维护长期配置时，建议把自定义例外、公共规则集和兜底规则分开管理。自定义例外数量通常较少，应放在主配置中并附上用途说明；公共域名与 IP 集合交给规则提供器更新；兜底策略保持固定。规则出现问题时，就能快速判断是本地例外、远程集合还是出口策略发生变化。

每次修改只调整一个层面。先验证策略组能够连接，再验证规则集能够加载，最后调整规则顺序。一次同时修改 DNS、TUN、规则提供器和策略组，会让日志中出现多个变量，难以定位真正原因。需要继续了解配置字段与客户端操作时，可结合配置进阶文档和使用文档逐项核对。

下载Clash