策略组进阶：负载均衡与故障转移怎么配置

先回顾一下三种基础策略组

url-test（自动选择）会定期测速，始终使用当前延迟最低的节点；select（手动切换）完全由用户指定；这两种是最常见的默认配置。当节点数量变多、使用场景变复杂之后，load-balance 和 fallback 这两种类型能解决更具体的问题。

load-balance：把流量分摊到多个节点

load-balance 组会把不同的连接请求分配给组内的多个节点，而不是像 url-test 那样始终只用「最优」的那一个。这样做的好处是可以分摊单个节点的带宽压力，尤其是在多设备同时使用同一订阅、流量较大的场景下比较有意义。它有两种分流策略，通过 strategy 字段指定：

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

• consistent-hashing —— 按目标地址做一致性哈希，同一个目标始终分配到同一个节点，适合需要「会话保持」的场景（比如某些网站会因为来源 IP 频繁变化而触发异常验证）；
• round-robin —— 按请求顺序依次轮询组内节点，分摊更均匀，但同一个目标地址不保证每次都走同一个节点。

不确定选哪个的话，优先用 consistent-hashing，多数场景下体验更稳定。

fallback：主节点挂了自动补位

fallback 组会按配置顺序依次检查节点是否可用，正常情况下始终使用列表里第一个可用节点；一旦当前使用的节点测速失败（判定为不可用），立即自动切换到下一个可用节点，等主节点恢复后再切回去。这与 url-test「谁延迟低就用谁」不同，fallback 更强调「优先用首选节点，不行了才退而求其次」：

proxy-groups:
  - name: 故障转移
    type: fallback
    proxies: [主节点, 备用节点A, 备用节点B]
    url: http://www.gstatic.com/generate_204
    interval: 300

组合起来用

实际配置中，这几种策略组类型经常是嵌套使用的——比如先用 url-test 从同一地区的多个节点里选出延迟最低的，再把几个不同地区的 url-test 组作为整体，用 select 手动选择当前使用哪个地区；需要分摊带宽的场景则可以把一组节点单独设为 load-balance，再和其他策略组并列放进最终的手动选择菜单里，按需切换。

别忽略 tolerance，它能减少无意义的切换

url-test 和 load-balance 组还有一个经常被忽略的参数——tolerance（延迟容差，单位毫秒）。如果不设置，客户端会严格按「谁延迟最低就用谁」的逻辑执行，而测速结果本身存在天然的抖动，两次测速之间几毫秒的波动很常见，如果没有容差缓冲，会导致节点在几个延迟接近的候选之间频繁来回切换，反而影响使用体验（尤其是正在进行的下载或视频会因为切换瞬间产生短暂卡顿）。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies: [节点A, 节点B, 节点C]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

设置 tolerance: 50 之后，只有新节点的延迟比当前节点低了至少 50 毫秒，客户端才会真正触发切换，否则会继续沿用当前节点，即便测出来的瞬时延迟略高一点。这个值不需要设得很大，通常 50～100 毫秒就能过滤掉大部分无意义的抖动切换。

该用哪一种，看你的实际问题

回到最开始的问题：如果只是延迟切换太频繁，先加 tolerance 就能解决，不一定要换成更复杂的策略组类型；如果是希望把多设备的流量分摊到不同节点、降低单节点压力，才需要用 load-balance；如果关心的是「主节点挂了能不能自动补位」，答案是 fallback。三个问题、三种方案，不需要一次性全部用上，按实际遇到的情况对症配置即可。想了解更多策略组参数，可以查看进阶配置文档。