Clash YAML 规则分流完全指南 2026：策略组与 Rule Providers

为什么「全局代理」往往不是好答案

很多新手第一次用 Clash 时，会习惯把模式切成「全局」——简单直观，但副作用也很明显：国内站点、局域网管理地址、甚至某些银行与政务站点都会被迫绕路，延迟升高、偶发无法访问。反过来，如果规则写得太粗，只依赖少量关键词匹配，又容易出现该走代理的没走（漏代理）或不该走的走了（多余代理）两种情况。

Clash 的设计思路是：在一份 YAML 里同时声明节点/策略组与规则表，由内核按顺序判断每一条连接「应该交给谁」。理解这套机制后，你可以把「国内外分流」「按域名分流」「按进程分流」组合起来，既保证访问体验，又减少手工维护成本。下文默认读者已能导入订阅；若你尚未升级内核，可先阅读我们的Meta 内核升级教程，再回来继续配置规则。

一句话记住目标 分流配置的本质，是在「延迟、隐私需求、规则维护成本」三者之间找平衡——没有万能模板，只有适合你网络环境与使用习惯的写法。

规则从上到下：第一条命中即停止

Clash 的 rules 是一个有序列表。对每一个新连接，内核会从第一条规则开始尝试匹配；一旦某条规则匹配成功，就采用该规则指定的动作（指向某个策略组、直连或拒绝），不再继续向下。因此，规则的排列顺序与内容同等重要：更具体、更优先的例外应当写在前面，宽泛的兜底规则放在后面。

列表末尾几乎总会有一条 MATCH 规则，作为「其余所有流量」的最终去向。若你忘记写 MATCH，或中间某条规则写错导致逻辑分叉，都可能出现与预期不符的走法。建议养成习惯：每改一次规则，都在客户端日志里观察命中的是哪一条（多数 GUI 会显示 rule 名称或类型）。

与 DNS 的简要关系

部分规则（如基于域名的匹配）依赖正确的域名解析流程。若 DNS 请求被污染或走了意外出口，可能出现「规则看起来对，但实际连错 IP」的现象。进阶用户会在配置中同时整理 dns 段与 fake-ip 相关选项；本文聚焦规则与策略组，DNS 细节可在做好基础分流后再逐项优化。

策略组 proxy-groups：先定义「可选项」，再被规则引用

在 proxy-groups 里，你为每一种「选路方式」起一个名字，例如「自动选择」「故障转移」「手动选择」。规则里写的并不是具体节点名，而是这些策略组名（或单独的 proxy 名）。这样做的优点是：订阅更新导致节点名称变化时，只要策略组里引用的是订阅中的节点列表，你不必逐条改规则。

常用类型速查

类型	典型用途	说明
`select`	手动切换	用户或 GUI 在多个候选中选一个，适合「主力 / 备用」场景
`url-test`	自动测速	按延迟自动选最快节点，需配置 `url` 与 `interval`
`fallback`	故障转移	按顺序检测可用性，前一个不可用则顺延
`load-balance`	负载均衡	在多个节点间分配连接，策略因客户端与内核版本略有差异
`relay`	链式代理	流量依次经过多个节点，适合特殊拓扑（延迟通常增加）

一个最小示例：定义名为「代理」的手动策略组，内含订阅解析出的若干节点，再定义一个「自动选择」组做延迟优选。规则里只需写 代理 或 自动选择 即可。

proxy-groups:
  - name: "代理"
    type: select
    proxies:
      - "自动选择"
      - "节点 A"
      - "节点 B"
  - name: "自动选择"
    type: url-test
    proxies:
      - "节点 A"
      - "节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

命名建议 策略组名尽量用简短中文或英文且避免空格与特殊符号，与订阅里节点名冲突时以客户端报错为准调整。同一名字在 rules 与 proxy-groups 中必须一致。

常用规则类型：从域名到 IP 与地理区域

下面几条是日常分流中最常见的规则前缀。实际配置时请与你的订阅、操作系统以及是否使用 TUN 模式结合起来看——例如进程名规则在部分环境下需要额外权限。

DOMAIN 与 DOMAIN-SUFFIX

DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配后缀，适合覆盖某一主域下的全部子域。对 CDN 较多、子域繁杂的站点，后缀匹配往往比逐条 DOMAIN 更易维护。若规则写得太宽，可能误伤同后缀下的其他服务，需要靠顺序或更细的规则修正。

DOMAIN-KEYWORD

按域名中的关键词命中，覆盖面大但也更容易误判。通常只在对一类服务有把握时使用，并放在较谨慎的位置，避免关键词过短导致意外匹配。

IP-CIDR 与 GEOIP

IP-CIDR 按网段匹配目标 IP，适合内网段、已知数据中心段等。GEOIP 依赖 GeoIP 数据库，常用于「国内 IP 直连」这类 broad 规则。注意：若解析结果或实际连接 IP 与预期不符，GEOIP 行为也会偏离预期，必要时结合规则顺序与 DNS 设置排查。

PROCESS-NAME 与规则顺序

在支持的平台上，可按进程名把特定应用定向到指定策略组，实现「只有某软件走代理」。该功能强大，但可移植性不如域名规则，换客户端或系统版本后需重新核对。

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,代理

上面是一段极度简化的示意：local 与局域网相关域名直连，中国大陆 IP 直连，其余全部走名为「代理」的策略组。真实订阅中你会在 MATCH 之前插入大量来自 Rule Providers 或手写的细分规则。

Rule Providers：用远端规则集托管海量条目

当规则数量从几十条增长到成千上万条时，全部写在主配置里会难以阅读，也不便随社区规则更新。Rule Providers 允许你把某一类规则放在单独的「提供者」中，由内核按设定间隔拉取或加载本地文件，再在 rules 里用 RULE-SET 一条引用整包。

典型配置结构

在 rule-providers 中声明名称、类型（常见为 http）、行为（classical / domain / ipcidr 等，与 Meta 版本有关）、路径或 URL、自动更新间隔等。引用时使用：

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

rules:
  - RULE-SET,reject-spam,REJECT
  # ... more rules ...

其中 path 为本地缓存位置，首次拉取成功后即使离线也可能继续使用旧文件（视客户端实现而定）。interval 控制检查更新的频率，过短会增加请求负担，过长则规则滞后，可按重要性折中设置。

与手写规则如何分工

实践中常见做法是：个人敏感或经常变动的条目手写放在前部；大块公开规则集用 Rule Providers 引用；最后再 GEOIP,CN,DIRECT 与 MATCH 兜底。这样你只需维护少量「例外」，其余交给社区维护的规则列表。

来源可信与 HTTPS Rule Providers 的 URL 应具备可信来源与有效 HTTPS，避免中间人篡改规则表。对极其敏感的环境，可优先使用本地打包的规则文件而非公网直链。

可维护性：注释、分段与版本管理

YAML 支持 # 注释。建议为每一段规则加简短说明（使用英文注释以兼容部分工具习惯亦可），并把「机场订阅生成的块」与「用户自定义块」在视觉上分开——许多客户端提供 Merge / Mixin / 覆写文件，避免直接修改订阅拉取的原始文件，这样订阅更新不会覆盖你的手改部分。

若你使用 Git 或定期导出配置备份，请在重大变更前保留上一版，以便对比「某条规则新增后为何某站异常」。分流问题排查通常是顺序与命中问题，而不是单条语法写错一项那么简单。

需要全平台安装包时，可从本站下载中心获取各系统客户端，再导入同一份经过验证的配置，减少环境差异带来的困惑。

常见问题与排查思路

现象	可能原因	建议
国内站变慢或打不开	未直连或被错误 MATCH 到代理	检查 `GEOIP,CN` 与国内域名规则是否在前，日志中看命中规则
某海外站始终直连失败	规则未覆盖或 DNS 解析异常	针对该域名单独加 `DOMAIN-SUFFIX` 或调整 DNS/fake-ip
Rule Providers 不更新	网络拦截、URL 失效或路径无写权限	查看客户端日志中的拉取错误，手动访问 URL 校验
策略组显示无节点	订阅未解析或名称引用错误	确认 `proxies` 列表与 `proxy-groups` 内名称一致

更多内核级报错可与内核升级与协议篇对照：新版本 Meta 对字段与行为偶有调整，升级后若规则集格式不兼容，需按日志提示迁移到新的 behavior 或规则集格式。

写在最后：分流是「长期工程」

一份优秀的 Clash 配置往往不是一次性写就，而是随订阅变化、站点改版和个人习惯逐步迭代出来的。把策略组当作「选路菜单」，把规则列表当作「从细到粗的决策流」，把 Rule Providers 当作「可更新的规则模块」，三者分工明确，你的配置文件就能长期保持可读、可改、可备份。相比单纯追求「规则数量最多」，更值得关注的是：关键站点是否稳定命中预期路径，以及出问题能否在十分钟内定位到是顺序、DNS 还是节点本身。

若你希望少碰 YAML、在图形界面完成订阅与模式切换，可以选择已集成 Meta 内核、对新手友好的客户端，把精力留在选节点与网络环境上，而不是与缩进和合并冲突搏斗——这与「手写规则」并不矛盾，而是同一套分流逻辑在不同界面上的呈现。

→ 立即免费下载 Clash，开启流畅上网新体验；内置或一键升级 Meta 内核，配合本文分流思路即可快速落地。

若你还想系统了解内核与 Hysteria2、TUIC 等协议，可继续阅读《Clash Meta 内核升级完整教程》；更多文章见技术专栏。