为什么「规则分流」才是国内快、海外稳的关键

很多用户第一次打开 Clash 时，会直觉地把模式切到「全局」，以为这样最省心。 但在真实网络里，把本可直连的国内站点也送进代理隧道，往往只会增加往返时延、浪费出口带宽，甚至还可能触发机场线路的拥堵。 Clash 的核心价值之一，正是用一套可读的 rules 列表，把流量按域名、IP、地理位置逐条匹配，让大陆业务走本地路径，把真正需要出海的请求交给节点。

本文目标很具体：讲清楚规则是如何从上到下匹配的，DNS 与 Fake-IP 怎样影响「第一眼」速度， 以及怎样用 GEOIP、DOMAIN-SUFFIX、IP-CIDR 与策略组配合，搭出一套国内直连、国外代理且易于维护的配置思路。 下列示例以通用字段为主，适用于多数基于 Clash Premium 或 Mihomo（Clash Meta）内核的图形客户端；若你的订阅自带规则，也可用「覆写」方式插入本节模板。

阅读提示：同名策略组必须在 proxy-groups 或 proxies 中存在，rules 里引用的名字大小写也需一致； 否则客户端会在载入配置时直接报错或静默回退，表现为「开了规则却不生效」。

先说模式：Rule / Global / Direct 分工不同

「规则分流」的前提是客户端处于Rule（规则）模式。 在该模式下，Clash 对每个连接逐项对照 rules，命中后即停止继续向下匹配； 若一路未命中，则依赖最后的 MATCH 行作为总兜底——因此 MATCH 写什么，就等于「默认值」。

Global 把所有 TCP/UDP（视实现与 TUN 配置而定）统一导向某个策略组，适合临时排障； Direct 则是全局直连。 日常使用若长期 Global，等价于放弃了规则引擎带来的路径优化， 国内视频、网银、政企站点若被无谓代理，用户体验会明显变差。

规则从上到下匹配：顺序即性能

Clash 的规则语义可以概括成先到先得：rules 数组中越靠前的条目优先级越高。 这也意味着：宽泛、误判成本高的条目不应压在细粒度条目之上。 实践经验是：

  • 需要确定性直连的国内核心业务（流媒体省内节点、局域网、公司等）应尽量靠前。
  • 针对少数国外服务的精确域名规则，紧随其后排在 GEOIP 大段规则之前更易维护。
  • 像 GEOIP,CN、GEOIP,private 这类大范围条目适合放在中下游，但仍要早于最终 MATCH。

一旦你理解了「排序 = 性能和可预期性」，很多「为什么我改了规则却没变」的现象都能定位到：MATCH 或某条 GEOIP 抢答了命中。

DNS 与 Fake-IP：决定首开速度的第二张网

仅写好 rules 并不够。 若 DNS 仍旧向境外递归，或在 Fake-IP 关闭时迟迟拿不到可用地址，浏览器会在 TLS 之前就卡住。 常见做法是开启 dns.enable，为大陆域名准备可靠的国内上游（如运营商或公共可信解析），同时为海外域名准备 fallback， 并在规则模式下启用 enhanced-mode: fake-ip，让系统在本地瞬时得到解析结果以便立刻进入代理决策。

当然，Fake-IP 并非银弹——个别应用对「非真实地址」兼容性差，出现异常时可尝试 redir-host 或对单一域名追加策略。 核心是：让 DNS、规则、策略组三件事指向同一语义，避免浏览器以为要直连却被规则送去代理的反常路径。 

# dns snippet (adapt nameserver pools to your network policy)
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
    - tls://dns.pub
  fallback:
    - tls://dns.google
    - https://dns.cloudflare.com/dns-query

GEOIP：用地理库快速「识别大陆流量」

GEOIP,CN,DIRECT 是许多订阅的标配，它会把命中中国大陆 IP 库的目标地址送回直连队列。 这条规则覆盖面广，是域名规则的有力补充：当某些 API 仅以 IP 裸露访问时仍然能回填到正确隧道策略。 但 GeoIP 数据需保持更新——过期的 mmdb 可能把新增的 CDN 段标错坐标，误判时可在其前后插入 IP-CIDR/Lan 特例。

GEOIP,private,DIRECT 也值得保留，用于局域网与保留地址段的直连， 避免本地打印机、路由器管理页误入代理链路。

DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD 的取舍

DOMAIN-SUFFIX,example.com 常用于「整块业务域」，例如你希望某云厂商控制台永远直连或永远走某一策略组； DOMAIN-KEYWORD 命中范围广，易产生误杀，只适合明确知道关键字唯一性的场景； DOMAIN 针对单主机名，粒度最精确。 对国内大厂业务，可参考公开维护的国内分流列表或通过客户端「规则集」挂载，但要注意优先级仍由摆放顺序决定——不要把超大规则块无条件放在 MATCH 之上而不留例外。

IP-CIDR 与局域网例外

CLAT/隧道场景下你可能需要把一些网段固定在直连：IP-CIDR,127.0.0.0/8,DIRECT、IP-CIDR,192.168.0.0/16,DIRECT 等， VPN/TUN 环境尤其需要避免「本机回路」再次被捕获。 IP 规则应尽量写得可追溯，并在注释中标明归属段，免得半年后自己也不记得为何插入。

策略组：把「怎么走代理」写成可组合的积木

单列节点适合临时测试； 真正日常使用时应当把节点放进 select、url-test、fallback 等策略组， rules 只引用稳定的组名而非某个易变的服务器条目。 例如：名为「自动选优」的 url-test 策略组放在 MATCH 兜底，可避免手动频繁切换， interval 与 tolerance 控制刷新频率以避免抖动， lazy 选项（若内核支持）则减少空闲时的探测开销。

需要注意的是，自动选优测的是到你的客户端的 ICMP/TCP RTT， 它不等价于流媒体解锁或商务线路 SLA——有高阶需求时请仍手工锁定地区组。

可直接改造的 YAML 骨架

下面是一段刻意精简的配置骨架，占位名 PROXY 与你订阅中的出站或策略组名保持一致即可； 「国内列表」占位符提醒你可在客户端中用规则集或远程列表替换， 「敏感域名」占位符可按个人需求填写必须代理的条目。 实战中请把与个人环境强相关的例外放在 GEOIP/MATCH 之前。 

# proxies / proxy-groups: keep your subscription output here unchanged if possible

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-KEYWORD,ntp,DIRECT
  - GEOIP,private,DIRECT
  # Put must-proxy domains BEFORE broad CN rules if they resolve inside CN CDNs:
  # - DOMAIN-SUFFIX,example-news.com,PROXY

  # Optional domestic list (RULE-SET/provider) placeholders:
  # - RULE-SET,domestic-domain,DIRECT

  - GEOIP,CN,DIRECT

  # Catch-all
  - MATCH,PROXY

若你的订阅已经将 MATCH 固定在某一组， 覆写时最好整段重写 MATCH 之上的策略，而不是在中间插入互相矛盾的条目， 否则会出现「配置文件能加载但实际路径与可视化面板不一致」的错觉。

自检清单：三组信号确认分流真的正确

完成编辑后建议按三步验证：连通性日志（观察命中规则名）、 延迟矩阵（国内站点应稳定在个位数毫秒级别到本省）、 DNS 泄露检测页（确认海外站点查询路径未意外回到本地污点解析）。 任一环节异常都应回到本节开头检查「DNS → 规则 → 策略」三角是否指向同一语义。

  1. 打开流媒体或电商首页，延迟应与未开代理时接近；明显飙高则说明仍走了隧道。
  2. 访问海外搜索或代码托管站，应当在日志里看到指向代理条的命中。
  3. 切换蜂窝 / Wi‑Fi 复测一遍，以防运营商劫持 DNS。

常见问题

为什么开了规则模式，国内网站还是很慢？

常见原因是 DNS 仍走海外解析、规则顺序把部分国内域名误送到代理，或订阅内置规则在大段条目里把 MATCH 写死为代理。 请逐项核对：.fake-ip/fallback 是否合理、靠前的 DOMAIN 直连是否覆盖了业务域、GEOIP 库是否陈旧。

GEOIP,CN 一定要配吗？

强烈建议保留。它能兜底大量「仅暴露 IP」的访问路径，并为 DOMAIN 规则查漏补缺。 若发现误判，优先考虑更新数据库或在 GEOIP 行前后插入更小范围的精确规则。

Fake-IP 和 Redir-Host 怎么选？

追求「首开」与规则协作体验时优先考虑 Fake-IP；遇到兼容性疑难再尝试 Redir-Host 或对单域名关闭增强模式——两者并非互斥，可通过客户端粒度化设置折中。

RULE 和 GLOBAL 哪个更快？

Global 只是把决策变简单，并不降低物理 RTT； RULE 才能让国内链路保持在本地互联网上。 如果长期 Global 体感慢，换回 RULE 并按本文调整往往立竿见影。

订阅里的规则能改吗？

可以，推荐走覆写或在本地补丁文件维护「个人例外」， 并确保新版本订阅不会意外覆盖你最前面的精细规则——必要时在客户端关掉「远端规则覆盖本地」一类选项。

Mihomo 与原版 Clash 在规则上有什么差异要注意？

语义大体一致； Mihomo 可能提供额外规则类型或数据源格式（如 RULE-SET、GEOSITE）。 迁移时盯住策略组关键字与兼容性开关即可，不要为了「尝鲜语法」而把基础 DIRECT/PROXY 链打断。

与其反复切换全局模式，不如用成熟客户端把分流一次做对

传统「单开关」代理工具往往在全局与PAC之间来回横跳， 遇到分应用、分域名、UDP 游戏的组合需求就容易力不从心， 用户只能不断手工改系统代理或通过浏览器插件打补丁， 既难排查也无法沉淀成可版本化的 YAML。 另一些闭源加速器则把分流策略黑盒化，透明度不足时一旦误判业务流量，你连日志都难以对齐。 Clash/Mihomo 生态把路由逻辑摊开在配置文件里：dns、rules、proxy-groups 三件事彼此对照即可复盘每一次连接决策。

如果你希望在一套界面里并行管理多套订阅与策略组， 并持续用上社区维护的内核与新协议， 可以从本站 Clash 客户端下载页 获取适合你系统的安装包， 在图形界面完成「规则 + DNS + TUN/TAP」协同调试， 让国内应用的响应继续跑在本地互联网上，同时为海外学习与开发场景保留顺滑出口。

免费下载 Clash 客户端