Clash 策略组类型对比:url-test、fallback 与 load-balance 各适合什么场景

01 · 出发点

三种策略组解决的不是同一个问题

很多人第一次接触 Clash 或 Clash Meta(mihomo 内核)的配置文件时,会把 proxy-groups 里的 type 字段当成"选一个自动模式就行"的开关,遇到问题再换一种试试。 这种试错方式能用,但效率低,而且换错类型有时反而会掉进新的坑——比如本来想要低延迟,却选了偏向"能连就行"的 fallback, 延迟没有明显改善;或者本来想分摊带宽压力,却选了 url-test,结果流量全压在测速最快的那一两个节点上。

三者的核心差异可以先用一句话概括:

• url-test 关心"谁最快",持续测速并自动切到延迟最低的节点。
• fallback 关心"谁能用",按配置顺序找第一个健康的节点,不主动追求最快。
• load-balance 关心"怎么分",把并发请求按算法分散到多个节点上,不是单点最优。

接下来分别拆解它们的判定逻辑和关键参数,理解逻辑之后,类型该怎么选基本就不需要再靠试错了。

02 · url-test

url-test:延迟优先的自动选择

url-test 会周期性地对组内每个节点发起一次 HTTP 请求(请求目标由 url 参数指定),记录响应耗时作为该节点的延迟值,然后把当前流量切到延迟最低的节点上。 它是"面板上显示自动测速节点延迟"这类界面功能背后最常见的实现方式,新手接触的第一个自动策略组通常就是它。

关键参数说明:

tolerance 是最容易被忽略但影响体验的参数。如果不设置容差,两个节点延迟只要有 1 毫秒差异就会触发切换, 高频切换会导致长连接(比如视频播放、下载任务)被打断重连。设置成 50ms 左右的容差,相当于告诉客户端"差距不明显就别换", 换来的是连接稳定性,代价是不会做到理论上的绝对最优。

proxy-groups:
  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港01
      - 新加坡02
      - 日本03

适合场景:对延迟敏感、单一节点即可满足带宽需求的用途,比如网页浏览、即时通讯、游戏加速。 它不会主动分流,所有流量默认都走同一个"当前最优"节点,这点和 load-balance 正好相反。

03 · fallback

fallback:保障可用性的备援机制

fallback 同样会对组内节点做健康检测,但判定逻辑不是"选最快",而是"按顺序找第一个能用的"。 配置里 proxies 列表的排列顺序就是优先级顺序:客户端会先尝试排在最前面的节点, 只要它能通过健康检测(同样通过 url 参数判断连通性),就一直用它,不会因为后面的节点延迟更低而切换。 只有当前节点被判定为不可用时,才会依次往后尝试下一个。

proxy-groups:
  - name: 稳定备援
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 180
    proxies:
      - 主力节点-专线
      - 备用节点-香港
      - 备用节点-日本

适合场景:有一个明确的"首选节点"(比如专线、自建中转、企业内网出口),只是希望它掉线时能自动切到备用线路, 而不是让系统在多个节点之间频繁比较延迟。常见于对连接稳定性要求高于速度的场合,比如需要长时间保持在线的远程会议、 对丢包敏感的语音通话,或者本身就只信任某一条特定线路、其余节点仅作应急备份的情况。

需要注意的是,interval 决定健康检测频率,间隔设置太长会导致节点已经失效但客户端还没察觉, 产生一段时间的连接失败;间隔太短又会增加不必要的检测流量和开销,一般 120~300 秒是比较均衡的区间。

04 · load-balance

load-balance:分摊流量的负载均衡

load-balance 的目标不是选出一个"最优节点",而是把不同的连接请求分散到组内多个节点上, 避免流量长期集中在单一出口。它通过 strategy 参数决定分配算法,常见的两种是:

• consistent-hashing(一致性哈希):按连接的源地址等信息计算哈希值分配节点,相同来源的连接大概率稳定落在同一节点上,适合需要会话保持的场景。
• round-robin(轮询):按顺序依次把新连接分配给下一个节点,分配更均匀,但不保证同一来源的连接固定走同一节点。

proxy-groups:
  - name: 分流均衡
    type: load-balance
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 节点A
      - 节点B
      - 节点C

适合场景:单个节点带宽或并发连接数容易触顶的情况,比如多设备共用同一套订阅、下载任务较多、 或者节点本身有并发连接数限制。把流量分散到多个节点后,单点压力下降,整体吞吐更容易接近多个节点带宽之和, 而不是被卡在某一个节点的带宽上限里。

05 · 对照

三种类型的参数与场景对照

实际配置文件里,这三种类型完全可以组合使用,并不是"选一种用到底"。比如把 fallback 作为最外层的总入口, 备用线路本身又是一个 url-test 组,专门在多个海外节点之间挑最快的;而单独给下载工具分流出去的规则, 再指向一个 load-balance 组,避免大文件下载占满某一个节点的带宽,影响其他应用的使用体验。 这种分层设计比单一策略组更贴近真实使用场景,也是查看别人分享的复杂配置文件时经常能看到的结构。

另外提一点容易被忽略的细节:url 参数指向的检测地址如果本身不稳定或被限速, 会直接影响三种策略组的判定结果——url-test 会测出偏高的延迟,fallback 可能误判节点不可用, load-balance 的健康检测也会失真。选用轻量、响应快、覆盖面广的检测地址,是这三种自动策略组都能正常工作的前提条件, 排查"自动选择结果不对"的问题时,也应该把检测地址本身的可用性放进排查清单。