Clash Meta 策略组 url-test 与 fallback：自动测速与故障切换逐步配置

为什么光有多节点还不够

订阅里常有几十上百个节点，但快与稳并不总是一致：某一时刻延迟最低的可能在几分钟后的晚高峰里排队变差；而归档为「专线」的节点也可能在维护。若你总是引用一个固定的 proxy 名，这些问题都会直接反馈到浏览器或应用上。策略组的意义，是把「选谁出站」从静态变为带策略的调度：url-test 侧重比较性（谁此刻测出来更优），fallback 侧重顺序与可用性（从首选开始往下找能用的）。两者都依赖同一套健康检查（对 url 发请求、看成否与耗时），差别在于决策逻辑：前者像「比武选将」，后者像「按职务接替」。

如果你尚未完成基础导入与 Rule 模式，请先读 《Clash for Windows 安装与配置》 或 《Clash 新手入门完整指南》；服务端侧可参考 《Clash Meta Docker 部署》。下文假设 proxies 列表已存在且至少可连通。

url-test：自动选当前「相对最快」

type: url-test 会在组成员之间周期性地发起对你指定的 url 的请求，记录延迟（或失败），并选出合适的一个作为当前出口。它不是「全球网速测试」，而是你的节点到你设的检测地址这一条路径上的近似 RTT，因此检测 URL 的选址会直接塑造「谁算快」——下文单设一节说明。

• interval：多久测一轮（秒）。太小会增加流量与 CPU 唤醒；太大则切换滞后。
• tolerance：容差（毫秒量级，依客户端展示为准）。新节点要比当前节点「好出足够多」才值得切换，用来减少来回抖动。
• lazy：为 true 时，策略组在未被规则命中使用之前可以不急着全员测速，有助于降低空闲时的探测流量；一旦真有流量要走这组，再进入常态检测。

fallback：按顺序的主备与故障切换

type: fallback 的成员有先后次序：从上到下，对每个成员做可用性检测（同样使用 url），采用第一个通过的。它不追求「谁延迟更低」，而追求「谁来兜底」。典型用法包括：自家机房的主线路写在最上，商业节点的备胎依次往下放；或同一机场里标为「IEPL / 专线」的排前面，普通线路排后面。与 url-test 相比，当你的业务更在意稳定性与可预期性（而不是极致低延迟），fallback 往往更直观。

逐步写：proxy-groups 示例

下面是一段示意结构：请把 节点A 等换成你 proxies 里真实存在的名称；若嵌套引用其他策略组，请确保不会造成循环。合并订阅后，名称以你实际加载的配置为准。

# Illustrative proxy-groups — replace names with your proxies
proxy-groups:
  - name: AUTO-GROUP
    type: url-test
    proxies:
      - 节点A
      - 节点B
      - 节点C
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: MAIN-FALLBACK
    type: fallback
    proxies:
      - 主出口
      - 备用-1
      - 备用-2
    url: http://www.gstatic.com/generate_204
    interval: 300
    lazy: true

各 GUI（Clash Verge、OpenClash 等）在可视化编辑时生成的字段名与缩进可能略有差异，但内核识别的语义一致：保存后可在「配置文件」或日志里核对是否按预期落地。

测速 URL、健康检查与选路偏差

url 项不是装饰，而是健康检查探针：内核会请求这个地址来判断节点是否「活着」以及大致延迟。常见做法包括使用返回 204 的轻量地址、或运营商／云厂商提供的极小响应资源。重点在于：探针走的路径是否与你真实访问的目标相似。例如探针全部命中同一云边缘，而你看流媒体时走的是另一 ASN，则「测速好看、实际卡顿」完全可能发生——这不是内核坏了，而是优化目标不对齐。

实践建议：

• 为「泛用浏览器代理」选通用、稳定、权宜的 HTTP 探针即可；
• 若你为某类站点单独写了策略组，可让该组的探针更贴近该类流量（仍须注意合规与站点条款）；
• DNS 异常会让「假死活」——探针全红时先排除 DNS 与 fake-ip，而不是盲目加节点。

接到 rules：让分流使用策略组

定义好 proxy-groups 后，需要在 rules 中引用组名，流量才会按你的分流命中该组。顺序仍遵循「从上到下首个命中」——与策略组内部调度是两件事：前者决定「哪类流量进哪个组」，后者决定「这个组当下选哪个节点或主备链」。

# Example rules tail — group names must match proxy-groups
rules:
  - DOMAIN-SUFFIX,google.com,AUTO-GROUP
  - GEOIP,CN,DIRECT
  - MATCH,MAIN-FALLBACK

若你大量使用 rule-providers，只需保证最终在合并规则中，关键的业务域名行仍指向期望的策略组；远程规则集更新后，建议在客户端里复查一遍命中与日志，避免组名被覆盖或大小写不一致。

lazy 与 tolerance 如何一起调

二者常被同时讨论，因为都影响「切换是否积极」。lazy: true 适合订阅极大、节点很多、且多数策略组长期不被触发的场景：避免一启动就对全部节点做一轮探测。缺点是第一次命中该组时，可能要等待短暂测速才能完成选路——体感上像「第一次稍慢，其后稳定」。若你追求开机即全员最优，可将关键组的 lazy 设为 false，并接受更频繁的探测。

tolerance 与 interval 要成套看：interval 越长，你对「晚一点才知道变差了」的容忍度就越高；配合较大的 tolerance，整体切换会更「钝」，适合网页与长连接较少的场景。反过来，游戏或实时会议可以缩短间隔（或依赖其他更贴近业务的策略），但仍要警惕过于频繁切换导致会话重建。

参数	大致作用	常见误区
interval	健康检查周期	设得过短徒增负载；过长则故障发现慢
tolerance	防抖，减少微小抖动引发的换节点	过大可能长期留在次优节点
lazy	未使用前可不测速	首次命中该组可能略等一轮探测

组合思路：同一套节点，两种调度

实际部署中常见两种叠法：其一，对延迟敏感、且节点质量接近的一组使用 url-test，让内核帮你「矮子里拔将军」；其二，对明确主备关系使用 fallback，只要主恢复且探测通过，通常会回到列表靠前的位置（具体以你使用的内核版本与实现为准，升级大版本后建议复读发行说明）。也可以让 fallback 的某一格再指向 url-test 组，形成「先定大类，再在小类里自动选 fastest」——层次越多，越要用日志验证是否命中你以为的那一层。

常见问题

测速全红或延迟异常高

先查本机时间、DNS、系统代理是否与 TUN 冲突；再单独用一个浏览器扩展绕过 Clash 访问同一 url 对比。若仅 Clash 内红，多为节点或嗅探／TLS 相关策略导致，可暂时精简规则做二分法。

节点「反复横跳」

增大 tolerance，或略增大 interval；检查是否多个策略组对同一域名链式引用导致重复决策。

主节点恢复了却没切回去

核对探针是否仍失败（部分网站间歇性拒绝数据中心 IP）、以及 fallback 实现上是否要求连续成功次数——可 bump 版本说明或社区文档；同时排除 DNS 缓存层。

实操检查清单

收尾前逐项确认，可减少「配置写了却不生效」的挫败感：

• proxy-groups 中的 proxies 名称与配置中 proxies 小节里的节点名完全一致；
• rules 中引用的组名与策略组 name 一致；
• url 可在你网络环境下被正常解析与访问；
• 升级内核或客户端大版本后，复核 lazy 等字段是否仍受支持；
• 用日志观察「命中策略 → 选中节点」链条，避免只盯着 ping 图。

下一步

把自动测速与故障切换写进配置后，你等于把「运维视角」交给了 Clash Meta：它在你设定的探针与容差下持续做小规模健康检查。若你还希望远程维护规则集而非整表粘贴，可继续阅读 《rule-providers 下载路径与更新间隔》，与本文策略组配合使用。

立即免费下载 Clash，开启流畅上网新体验