Clash 策略组 url-test 与 fallback：自动测速与故障转移怎么配

1. 两类需求：自动选快与主备切换

很多用户完成订阅导入后，默认策略组往往是「手动选一个节点」或「一个简单的自动组」。当你希望长期让系统自动维护「当前最快」，就需要能理解 url-test：它会按固定间隔对组内节点发起探测请求，根据延迟挑选候选。另一种典型诉求是主备链路：例如香港主线路优先，只有 ping 失败或 TCP 不通时才落到新加坡备用，再到美国，最后才是直连——这类「严格优先级」更适合 fallback，因为它尊重你在列表里写的先后顺序，而不是单纯比数字谁更小。

若把两者混为一谈，很容易出现「明明想主备，却发现节点老是跳到延迟略低但你不喜欢的出口」或者「想自动选快，却把最快的节点写在列表末尾永远轮不到」。先选对策略组类型，再谈 url、interval 等细节，会省大量排查时间。若你尚未熟悉订阅文件结构，可先对照 订阅导入教程 确认 proxies 与 proxy-groups 在配置中的位置。

2. url-test 与 fallback 的核心区别

用一句话概括：url-test 在「健康」的节点里优先选延迟最低的那一个（并可设容差避免来回切）；fallback 则从列表自上而下寻找第一个通过健康检查的节点，更像「串行尝试」，与延迟数值的绝对大小无必然关系——只要排在前面的节点仍可用，后面的即使更快也不会被选中。

因此：想自动切换节点、追求当前网络下体验最优，优先考虑 url-test；想固定主备顺序、仅故障时切换，优先考虑 fallback。部分机场订阅会同时提供「自动选择」与「故障转移」两个组，正是对应这两种心智模型。健康检查通常依赖你配置的探测 url（常见为轻量 HTTP 204 类地址），内核按间隔请求并标记节点是否可用。

3. url-test：延迟测试、容差与 lazy

url-test 策略组需要关注这些常见字段：proxies 列出参与测速的成员（可以是具体节点名，也可以是嵌套的其他策略组名，视内核与配置是否允许而定）；url 为探测地址；interval 为测速周期（秒），间隔过短会增加流量与耗电，过长则「自动切换节点」反应迟钝；tolerance（容差）用于避免延迟在几毫秒级波动时频繁切换出口——只有新候选比当前选中值低出超过容差，才可能触发更换。

lazy: true 常见于 mihomo 系：在未实际命中该策略组前可以延迟首次探测，适合订阅里大量 url-test 组、但你只会用到其中少数的场景，能减轻启动时的并发探测压力。若你发现「第一次访问某站点特别慢」，可以尝试对该组关闭 lazy 或手动触发一次全局测速，观察是否因懒加载导致首次选型滞后。

  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - 香港 A
      - 香港 B
      - 新加坡 C
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

具体键名以你所用内核与订阅生成器为准；若合并配置时报错，多半是缩进、引号或策略组名称与 proxies 段中的名称不一致。名称不一致是新手最高频的 YAML 错误之一，建议复制粘贴节点名而不是手打。

4. fallback：顺序即优先级，故障才下移

fallback 的配置同样包含 proxies、url、interval 等用于健康检查。区别在于选型逻辑：从上到下找到第一个健康的成员就使用它。若你希望「专线优先、便宜节点殿后」，就把专线写在最前。若主节点只是间歇性丢包，内核可能在健康检查失败时切到下一个；主节点恢复后是否会立刻切回，取决于实现与健康检查结果，总体仍应以「列表顺序表达业务优先级」来理解。

在列表末尾放置 DIRECT 或 REJECT 是常见做法：当前面代理全部不可用时直连或阻断，避免流量卡在半死状态。是否适合直连要配合你的规则场景——例如仅对某一类域名使用 fallback 组时，末位直连可能比你想象得更常命中，需要结合日志确认。

  - name: "HK-PRIMARY-SG-BACKUP"
    type: fallback
    proxies:
      - 香港专线
      - 新加坡备用
      - DIRECT
    url: "http://www.gstatic.com/generate_204"
    interval: 300

5. 完整 proxy-groups 示例（可对照改）

下面是一段将 url-test 与 fallback 并列放置的示意结构（节点名请替换为你订阅里真实存在的 proxy 名称）。实际文件中还应包含顶层的 proxies: 列表或 proxy-providers 引用。合并多份订阅时，注意策略组名称不要与提供商自带的组名冲突，必要时在编辑器里全文搜索重命名。

proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - 节点1
      - 节点2
      - 节点3
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "故障转移"
    type: fallback
    proxies:
      - 节点1
      - 节点2
      - DIRECT
    url: "http://www.gstatic.com/generate_204"
    interval: 300

部分 GUI 客户端提供「可视化编辑策略组」，底层仍是对这一段 YAML 的读写。若你在界面里改了不生效，多半是未保存到当前配置档案，或存在覆写（override）规则在启动时又把远程订阅盖掉——可在客户端日志里确认加载的是哪一份文件。

6. 在 rules 里如何引用策略组

定义好策略组后，需要在 rules: 中把流量指向组名，例如 DOMAIN-SUFFIX,google.com,自动选择 或 MATCH,故障转移。规则自上而下匹配，靠前规则优先生效；因此不要把过于宽泛的 MATCH 放在中间打断后续条目。关于规则顺序、策略组与分流哲学，可结合站内 高级规则分流指南 一起阅读，避免「策略组配对了，规则却没走到」。

若同一域名同时命中多条规则，最终以最先匹配为准，而不是以策略组内部的 url-test 或 fallback 逻辑为准——策略组只决定「这一包流量交给哪个组去选路」，不替你重新排序全局 rules。复杂场景下建议打开客户端日志或抓包面板，确认域名实际落入哪条规则。

7. 常见误区与调参建议

误区一：把 fallback 当成「自动选延迟最低」。fallback 只认顺序，若你把延迟高的主节点写在第一位，它会长期占用，除非健康检查失败。要「谁快用谁」请用 url-test。误区二：url-test 的 tolerance 设为 0。在移动网络或 Wi‑Fi 干扰环境下，延迟抖动会极其频繁，过小容差会导致策略组不断切换节点，网页加载反而卡顿；可尝试 30～80 ms 量级并按体验微调。

误区三：探测 URL 被墙或响应慢。若探测地址在你当前网络下不稳定，健康检查会误判节点不可用，fallback 可能整体落到 DIRECT 或错误备用。可更换为运营商与地区都较易访问的轻量探测地址（以你所用内核文档推荐为准），并观察日志中的错误码。误区四：interval 过短。测速过频对部分按流量计费的环境不友好，也会放大探测 URL 异常带来的影响。

最后，自动切换节点解决的是「出口选择与故障恢复」层面；若你遇到的是 DNS 污染、Fake-IP 与规则冲突，需要在 DNS 与规则侧继续排查，而不是反复更换 url-test 参数。保持「一次只改一个变量」的排错节奏，更容易定位问题。

8. 排查清单