Clash 策略组怎么选:url-test、fallback、load-balance 三种类型实测差异

策略组解决的是"选哪个节点"的问题

一份 Clash / Clash Meta(mihomo)配置文件里,proxies 列出的是所有可用节点,proxy-groups 才是真正决定流量走向的地方。规则(rules)只负责判断一条连接该交给哪个策略组,策略组内部再决定具体挑哪个节点出站。如果只写一个 select 类型的手动策略组,选路完全靠人工点选,节点挂了也不会自动切换。这就是为什么绝大多数配置都会额外准备几个自动化策略组——它们按各自的算法,把"挑节点"这件事交给程序而不是人。

mihomo 支持的自动化策略组主要有三种类型:url-test(自动测速)、fallback(故障转移)、load-balance(负载均衡)。三者共享一套健康检查机制,但判断逻辑和适用场景完全不同,混着用效果会打折扣。下面按参数、行为、场景逐一拆开讲。

url-test:按延迟自动选最快节点

url-test 是最常见的自动化类型,核心逻辑是:定期用组内每个节点去请求一个测试地址,记录响应耗时,然后把当前流量导向耗时最低的那个节点。它解决的是"这么多节点,哪个此刻最快"的问题,适合大多数以延迟为核心指标的日常场景。

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

url:测速请求打向的地址,通常用一个轻量、稳定返回 204 的地址,避免测试请求本身占用太多带宽或被墙干扰判断。
interval:两次测速之间的间隔,单位秒。上面示例是 300 秒测一次,间隔太短会让节点频繁被打测速请求,太长又会导致节点变慢后迟迟没被切走。
tolerance:容差值,单位毫秒。只有当新测得的最快节点比当前使用节点快出这个容差值以上,才会真正切换。设置容差是为了避免两个延迟接近的节点来回抖动切换,造成连接频繁中断。
lazy:为 true 时,只有组内有连接正在使用才会触发测速,后台空闲不测速,省流量也省节点压力;设为 false 则无论是否被使用都会按 interval 定时测速。

需要注意,tolerance 不是"延迟阈值",而是"切换门槛"。比如当前用的节点延迟 120ms,另一个节点测出 100ms,容差设的是 50ms,那么 20ms 的差距不够大,不会切换;只有差距超过 50ms 才会真正换节点。这个设计是为了避免为了几毫秒的差异反复跳来跳去。

fallback:第一优先级失效才换下一个

fallback 的判断逻辑跟 url-test 完全不同,它不比较谁最快,只关心"节点存活"。组内节点按配置顺序排出优先级,系统始终优先使用列表里排在最前面且健康检查通过的节点,一旦当前使用的节点测速失败(超时或连不上),才会依次往后尝试,直到找到一个能连通的节点。

proxy-groups:
  - name: 故障转移
    type: fallback
    proxies:
      - 主力节点-香港
      - 备用节点-新加坡
      - 备用节点-日本
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    tolerance: 0

这里的顺序就是优先级,主力节点-香港排第一,只要它健康检查正常,流量就一直走它,哪怕后面的节点延迟更低也不会抢占。这跟 url-test "谁快用谁"的逐利策略正好相反,fallback 追求的是稳定和可预期,适合你已经明确知道哪个节点线路质量最好、只是想在它偶尔抽风时有个兜底方案的场景,比如给某个固定专线节点配一到两个备胎。

fallback 里的 tolerance 参数意义不大,因为它不做"快慢比较切换",只做"能不能连通"的二元判断,大多数配置直接设为 0 或省略即可。真正起作用的是 url 和 interval,这两个参数决定了健康检查多久跑一次、往哪个地址跑,间隔太长会导致主节点故障后有一段时间流量还打在失效节点上。

load-balance:把流量摊开分给多个节点

load-balance 解决的是另一类问题——不是"选最快的一个",而是"把并发连接分散到多个节点上",常见目的是分摊单节点带宽压力,或者让多个相近质量的节点都有活干,避免某一个节点长期满载而其他节点闲置。

proxy-groups:
  - name: 负载均衡
    type: load-balance
    proxies:
      - 香港01
      - 香港02
      - 香港03
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

strategy 参数是这个类型的关键,mihomo 提供两种分配算法:

consistent-hashing(一致性哈希):按连接的源地址、目标地址等信息计算哈希值,固定分配到某个节点。同一个目标站点、同一个来源大概率始终落在同一节点上,好处是同一个会话不会中途换节点导致的登录状态丢失或下载中断,适合长连接、需要会话保持的场景。
round-robin(轮询):新连接依次轮流分配给组内节点,分配更均匀,但同一个网站的不同请求可能落到不同节点上,遇到对 IP 一致性敏感的服务(比如某些需要验证码或登录态绑定 IP 的站点)容易出问题。

需要提醒的是,load-balance 不会剔除已经失效的节点重新分配全部流量,它依然依赖健康检查判断节点是否存活,失效节点会被暂时跳过,但分配逻辑不做"故障转移优先级"那种排序处理。如果组内节点质量差异很大,负载均衡反而会让部分连接落到慢节点上,体验不如 url-test 稳定,所以这个类型更适合"节点质量彼此接近、想摊开压力"的场景,而不是"节点质量参差不齐、想要挑好的用"的场景。

注意三种类型的 url 测速地址必须能被节点正常访问且返回稳定,如果测速地址本身在某些地区被干扰,健康检查结果会失真,导致该切换的没切、不该切的乱切。建议固定用同一个测速地址,方便排查问题时对照。

三种类型怎么选:场景对照

类型	判断依据	典型场景	关键参数
url-test	延迟最低者优先	日常上网,追求最优速度	interval / tolerance
fallback	存活优先级顺序	已知优选节点 + 备胎兜底	proxies 顺序 / interval
load-balance	分散并发连接	多节点质量接近,想摊开压力	strategy

实际配置中,三种类型也可以嵌套组合。比较常见的做法是先用 url-test 建一个"自动选择"组作为默认出口,再单独给某些高优先级站点(比如流媒体、下载工具)配一个 load-balance 组分摊带宽,同时给关键节点配一个 fallback 组当保险。策略组之间可以互相引用——一个 select 组的选项里既可以放具体节点,也可以放另一个策略组的名字,这样上层规则只需要指向最外层的 select,内部的自动化逻辑由内层策略组承担,配置结构会清晰很多。

常见误区与排查思路

不少人反馈"配了 url-test 但节点一直不切换",大概率是 tolerance 设得过大,或者组内节点延迟本身差距不明显,系统判断没必要切换。可以临时把 tolerance 调小到个位数验证是否恢复切换,确认逻辑正常后再调回合理数值。另一个高频问题是 fallback 组"主节点明明连不上,却还在用它",这通常是 interval 设得太长,健康检查还没跑到下一轮,或者测速地址返回的不是预期的 204 而被误判为存活。

还有一类误区是把 load-balance 当成"更快的 url-test"来用,期望它自动挑最优节点,但它的设计目标是分摊而不是择优,如果组内混入一个明显更差的节点,部分连接体验会被拖累,这种情况应该把慢节点挪出组,或者干脆换成 url-test。排查这类问题时,建议客户端界面上留意各节点当前测速数值和策略组实际选中的节点,大多数图形客户端(如 Clash Verge、Clash for Windows 系客户端)都会在策略组界面实时显示每个节点的延迟和当前选中项,比盯着日志翻找更直观。

小结追求速度用 url-test,追求稳定用 fallback,追求分摊压力用 load-balance;三者可以嵌套组合,但不要指望一种类型解决所有选路需求。