Clash 策略组类型怎么选:url-test、fallback 与 load-balance 区别详解

策略组:流量的分岔口

一份 Clash 配置里,rules 决定「哪类流量交给谁处理」,proxy-groups 决定「接到流量的这一组,最终从哪个节点出站」。除了手动选择的 select 组,Clash 内核(含 mihomo)还提供三种自动策略组:url-test、fallback、load-balance。三者都不需要手动切节点,但自动的逻辑完全不同:一个盯延迟,一个盯存活,一个做分流。

先给结论,再逐一展开:日常浏览图省心,用 url-test;手里有明确的主力节点、只要故障兜底,用 fallback;想把多条线路的带宽叠起来,用 load-balance。

url-test:延迟最低者上岗

url-test 是使用频率最高的自动策略组。工作机制分两步:每隔 interval 秒,组内每个节点各自向 url 指定的地址发起一次探测请求,记录往返耗时;有新连接进入该组时,内核把连接交给最近一次测速中延迟最低且通过检查的节点。

两个参数直接决定它好不好用:

• tolerance:容差,单位毫秒。候选节点必须比当前节点快出这个数值,才会发生切换。几个节点延迟接近时,没有容差会来回抖动,连接被反复重建。
• lazy:开启时,只在该组有流量通过时才测速;关闭则按 interval 持续后台探测。节点数量多的订阅建议保持开启,减少无谓的探测流量。

proxy-groups:
  - name: 自动选优
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100
    timeout: 5000

一个常见误解要拆开:延迟低不等于速度快。204 探测只是一个小请求的往返时间,反映线路响应快慢,不反映带宽大小。下载大文件慢,未必是选错了节点,可能是节点本身带宽就小。

适用场景:同一地区有多个质量相近的节点,日常浏览、流媒体、普通下载交给它自己挑。mihomo 另支持 expected-status 指定期望的响应状态码,探测返回非预期状态即判定该次检查失败,可用于识别「能连通但响应异常」的线路。

fallback:主力挂了才换

fallback 不比较延迟,只判断通与不通。它严格按照 proxies 列表的顺序工作:永远使用列表里第一个健康检查通过的节点。当前节点连续失败达到 max-failed-times 上限后被标记为不可用,流量自动落到下一个可用节点;排在前面的节点恢复健康后,再自动切回去。

proxy-groups:
  - name: 故障转移
    type: fallback
    proxies:
      - 专线主力
      - 备用中转 A
      - 备用中转 B
    url: http://www.gstatic.com/generate_204
    interval: 120
    max-failed-times: 3

和 url-test 的本质区别:url-test 在「都能用」的节点里挑最快的,fallback 只认顺序——哪怕备用节点延迟更低,也绝不主动切换。这正好匹配一种常见情况:主力是贵而稳的专线,备用是普通线路,平时一毫秒都不想让流量跑到备用上。

健康检查间隔决定故障发现速度,所以 fallback 的 interval 可以比 url-test 调小,比如 120 秒。再小意义不大,只会增加探测流量和日志噪音。

load-balance:连接摊到多条线路

前两种组在任意时刻只有一个出口节点,load-balance 让组内节点同时干活:每条新连接按 strategy 指定的策略分配给不同节点。

• consistent-hashing(默认):按目标地址做哈希,同一网站的连接固定落到同一节点。对站点而言出口 IP 稳定,适合日常混合使用。
• round-robin:逐条连接轮换节点。多线程下载工具一次建立几十条连接时,流量被均匀摊开,多条线路的带宽得以叠加。

proxy-groups:
  - name: 负载均衡
    type: load-balance
    proxies:
      - 节点 A
      - 节点 B
      - 节点 C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: round-robin

代价同样明显:不同连接从不同的出口 IP 出站。网银、支付、账号登录这类对 IP 一致性敏感的场景,出口频繁变动容易触发风控,轻则要求重新验证,重则临时限制登录。稳妥做法是用规则把这类域名单独指向固定节点或直连,其余流量再进负载均衡组。

三种策略组怎么选

一句话选型:节点质量相近、图省心,url-test;节点有明确等级、只接受故障兜底,fallback;追求吞吐、能接受出口 IP 变动,load-balance。拿不准就先建一个 url-test,它覆盖绝大多数日常需求。

组合用法与常见坑

策略组可以互相嵌套,组名本身就是合法成员。常见写法是把自动组塞进一个 select 组,rules 只引用最外层:

proxy-groups:
  - name: 主代理
    type: select
    proxies:
      - 自动选优
      - 故障转移
      - DIRECT
  - name: 自动选优
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: http://www.gstatic.com/generate_204
    interval: 300

平时走「自动选优」,需要固定出口时在客户端代理页手动切到「故障转移」或 DIRECT,规则文件一行不用动。mihomo 用户还可以用 use 字段引用 proxy-providers,把订阅里的节点成批纳入组内,配合 filter 正则筛选,省去逐个列名的维护。

改动会被订阅更新覆盖

直接编辑订阅生成的配置文件,下次更新订阅时改动会被覆盖。长期自定义请使用 Clash Verge Rev 配置页的合并(覆写)处理,把策略组写进扩展配置,而不是订阅文件本体。

interval 不是越小越好

探测间隔太短,几十上百个节点轮番请求探测地址,CPU、电量与流量都在消耗,日志也被健康检查刷屏。日常 300 秒上下是合理起点;fallback 可以稍短,但不建议低于 60 秒。

探测地址本身要稳定

三种组都依赖健康检查:探测请求经节点发出,地址不可达就判定节点失败。选一个长期稳定的 204 探测地址;某天整组节点集体「超时」,先怀疑探测地址失效,再怀疑节点。

组名引用要一致

rules 里引用的组名必须与 proxy-groups 中的 name 完全一致,多一个空格都会匹配失败。改完配置看一眼日志页,加载报错会直接指出问题所在行。