进阶配置 2026-05-21 预计阅读 9 分钟

Clash 策略组选型指南:url-test、fallback、load-balance 区别与适用场景

select、url-test、fallback、load-balance 四类策略组的选择逻辑各不相同。本文逐一拆解测速判定、故障切换与负载分摊的工作机制,并给出常见分组结构的组合建议。

策略组是什么:决策组与执行组的关系

Clash 与 Clash Meta(mihomo)的配置文件里,proxies 段列出的是具体的代理节点,而 proxy-groups 段定义的是"策略组"——一种把多个节点或多个下级策略组打包起来、按某种规则决定实际走哪一条的逻辑单元。规则(rules)段最终指向的往往不是某个具体节点,而是某个策略组的名字,由策略组在运行时决定流量落到哪个节点上。

目前主流的策略组类型有四种:select(手动选择)、url-test(自动测速选择)、fallback(故障转移)、load-balance(负载均衡)。四者共享相同的字段结构(name、type、proxies),但判定逻辑完全不同,混用不当会导致"明明配了备用节点却不切换"或者"节点频繁跳动"之类的问题。理解每种类型的触发条件,是配置一份稳定订阅规则的前提。

select:手动选择型策略组

select 是最基础的类型,它本身不做任何测速或健康检查,单纯把一组节点或策略组摆出来给用户在客户端界面里手动切换。默认展示 proxies 列表里第一个,切换后客户端会记住上次选择(写入运行时状态,不会改动配置文件本身)。它的典型用途是作为顶层入口组,让用户在"自动选优"和"直接手动指定某个节点"之间自由切换。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选优
      - 香港中转
      - 日本专线
      - DIRECT

由于没有测速与故障检测,select 组里放进去的节点如果本身已经失效,流量依旧会被硬塞过去直到用户手动切换。因此实践中通常不会把裸节点直接铺满 select,而是把测速类的下级策略组(比如下文的 url-test 组)作为选项之一放进来,兼顾手动可控与自动兜底。

url-test:自动测速与切换判定机制

url-test 组会周期性地向配置的测试地址发起请求,记录每个节点的响应延迟,并自动选用当前延迟最低、且延迟差异超过容差阈值的节点。核心字段有三个:

  • url:测速请求目标,通常用一个国际可达的轻量地址;
  • interval:测速周期,单位秒,过短会增加节点负担和电量消耗,过长则故障发现变慢;
  • tolerance:容差值,单位毫秒。只有新的最优节点比当前节点快出容差值以上才会真正切换,避免延迟在几毫秒范围内抖动导致节点反复跳变。
proxy-groups:
  - name: 自动优选
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - 香港中转
      - 新加坡专线
      - 日本专线

url-test 适合节点数量较多、且希望"谁快用谁"而不关心具体是哪一个的场景,比如日常浏览、看视频这类对延迟敏感但不要求固定线路的用途。它的局限在于测速结果只反映测速那一刻的网络状况,如果实际业务流量的目标服务器与测速地址网络路径差异很大,选出来的"最优"未必是业务场景下真正最快的节点。

fallback:故障转移的触发条件与延迟

fallback 组按 proxies 列表里的顺序依次探测,优先使用排在前面且探测通过的节点,只有当前使用的节点探测失败(超时或返回非预期状态)时才会顺位切换到下一个可用节点。它同样依赖 url、interval 两个字段做健康检查,但判定逻辑与 url-test 不同:url-test 比的是"哪个最快",fallback 比的是"排在前面的是否还活着"。

proxy-groups:
  - name: 故障转移
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - 主用专线
      - 备用专线-A
      - 备用专线-B

fallback 适合有明确优先级、希望"非必要不切换主线路"的场景,例如把稳定但成本较高的专线放第一位,把速度一般但胜在稳定的备用节点排在后面,只在主线路真正掉线时才切走,而不是因为主线路某一次测速延迟稍高就跳走。需要注意的是,fallback 的健康检查间隔决定了故障发现的延迟——检测周期设得太长,主线路故障后会有一段时间流量仍卡在失效节点上;设得太短又会增加探测请求的频率。

load-balance:负载分摊的两种策略

load-balance 组不追求"选出唯一最优",而是把请求分摊到多个节点上,常用于希望多条线路共同分担带宽压力、避免单一节点长时间承担全部流量的场景。它通过 strategy 字段指定分配算法,主要有两种取值:

  • consistent-hashing:按请求的目标地址做一致性哈希,同一个目标域名/IP 会稳定落到同一个节点,适合需要会话保持(比如某些需要固定出口 IP 才能正常登录的站点)的场景;
  • round-robin:按轮询顺序把请求依次分配给不同节点,分摊更均匀,但同一个目标在不同请求之间可能落到不同节点,不适合对出口 IP 一致性有要求的业务。
proxy-groups:
  - name: 分流负载
    type: load-balance
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - 专线-A
      - 专线-B
      - 专线-C

load-balance 组同样带健康检查,失效节点会被自动排除在分配范围之外。它更适合多条同质化线路(带宽、延迟相近)并存、目的是分摊压力而非择优的场景,如果几条线路质量差异明显,盲目负载均衡反而会让请求随机落到较差的节点上,体验不如 url-test 稳定。

常见分组组合与实践建议

实际配置中很少只用单一类型,更常见的是分层组合:顶层放一个 select 组供用户手动干预,下面挂多个不同策略的子组,再由 rules 按域名/IP 规则分发到具体的子组。一个常见结构如下:

proxy-groups:
  - name: 出站策略
    type: select
    proxies:
      - 自动优选
      - 故障转移
      - DIRECT

  - name: 自动优选
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [专线-A, 专线-B, 专线-C]

  - name: 故障转移
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies: [主用专线, 备用专线-A]

选型时可以按下面的思路判断:如果目标是"平时自动挑最快、允许偶尔跳动",用 url-test;如果目标是"有明确主备顺序、不希望轻易离开主线路",用 fallback;如果目标是"多条线路一起扛流量",用 load-balance;如果目标只是"给用户一个手动开关",用 select。四者可以互相嵌套——比如把一个 url-test 组作为 select 组的一个选项,既保留自动优选,又保留手动指定单一节点的退路。

注意 NOTICE 测速类策略组(url-test/fallback/load-balance)的 url 字段建议使用国际通用的轻量测速地址,并避免把 interval 设置得过短;订阅内容更新后策略组会按新的节点列表重建,手动切换的选择状态也会随之重置,这属于预期行为而非配置异常。

另外需要提醒的是,策略组的判定只覆盖代理层面的连通性与延迟,不涉及规则匹配是否命中、DNS 解析是否走了正确的出口、TUN 模式下系统路由表是否生效等其他环节。如果切换策略组后问题依旧,建议先确认规则段是否真的把目标流量指向了这个策略组,再回头检查测速地址与容差参数是否合理,逐层排查比一次性改动多个字段更容易定位问题所在。

下载客户端