负载均衡与故障转移：多节点如何智能调度

四种策略组类型对比

类型	行为	适合场景
select	手动选择，只用你点的那个节点	习惯固定使用某个节点
url-test	定期测速，自动切到延迟最低的节点	希望始终使用当前最快的线路
fallback	按列表顺序使用第一个可用节点，当前节点故障才切下一个	有明确的主 / 备节点优先级
load-balance	按策略把请求分散到多个节点，分摊连接压力	节点数量充足，希望分摊带宽压力

左右滑动查看完整表格

url-test：自动追着低延迟走

url-test 会按设定的间隔对组内所有节点发起一次测速请求，并自动切换到延迟最低的一个，不需要你手动点测速按钮。

url 是测速时请求的目标地址，通常用一个响应很轻的地址；interval 是测速间隔（秒），太频繁会增加不必要的请求，一般设置成几分钟一次即可。

fallback：主备节点的故障转移

fallback 按你写入 proxies 列表的顺序，优先使用排在前面的节点；一旦当前使用的节点测速失败（不可用），会自动切换到列表中下一个可用的节点，直到主节点恢复。适合你明确知道「哪个节点线路更好，哪个是备用」的场景。

load-balance：把压力分摊出去

load-balance 不追求「选出最好的那一个」，而是把不同的请求分散到多个节点上，常见的分配策略有按连接的一致性哈希（同一个目标始终走同一节点，避免会话中断）和轮询。适合你有多个节点、且都还算稳定，希望分摊带宽和连接数压力的情况。

常见调优建议

把策略组用起来之后，还有几个细节值得留意，能让自动调度的效果更贴近预期：

• 测速地址选轻量目标：url 字段建议使用响应体很小、几乎不占带宽的地址（例如返回 204 状态码的健康检查接口），避免测速本身消耗过多流量。
• 合理设置 interval：间隔太短会让节点被过于频繁地测速请求打扰，太长又会导致故障发现不及时，几分钟一次是比较常见的折中方案。
• tolerance 容差：部分实现支持设置一个容差值，只有新节点的延迟比当前节点低出这个差值才会触发切换，避免延迟在阈值附近抖动时反复切换节点。
• 组内节点数量：load-balance 组内节点太少时分摊效果不明显，节点数量充足才能真正体现出「分摊压力」的价值。

常见问题

为什么 url-test 组里的节点一直在跳来跳去？

这通常是几个节点的延迟非常接近，每次测速的微小波动都足以改变「最低延迟」的排名。适当调大 interval，或者使用带 tolerance 容差的配置，能有效减少这种频繁切换。

fallback 组里的节点全部显示不可用怎么办？

先确认测速地址本身是否可以正常访问——如果测速目标地址被防火墙拦截，所有节点都会被误判为不可用。也可以尝试更换一个更稳定、访问量更小的测速地址。

能不能把 select、url-test、load-balance 组合起来用？

完全可以，而且这是比较推荐的做法：按地区把节点分成几个 url-test 子分组（比如「香港自动选择」「日本自动选择」），再用一个最外层的 select 分组手动选择地区，既保留了手动控制的灵活性，也享受到了组内自动优选的便利。

小结

如果只有一两个节点，select 手动切换已经够用；节点数量上来以后，url-test 能省去手动测速切换的麻烦，fallback 适合有明确主备关系的场景，load-balance 则更适合把压力分摊到一批质量相近的节点上。