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

大多数订阅默认生成的策略组类型是 select（手动选择）或 url-test（自动测速选最优），这两种已经能覆盖日常需求。但如果你手上有很多节点、或者对稳定性要求更高，fallback 和 load-balance 这两种类型能提供更好的容错和分摊效果。

01四种策略组类型速览

类型	选择逻辑	适用场景
select	完全手动选择，内核不做任何自动切换	你想自己精确控制用哪个节点
url-test	定期测速，自动选延迟最低的一个节点使用	日常使用，追求省心，多数订阅的默认设置
fallback	按列表顺序使用第一个可用节点，当前节点失败才切到下一个	有明确的"主备"节点优先级，希望优先用某个节点
load-balance	按算法把不同连接分摊到多个节点上，同时使用	多节点、希望流量分摊、避免单节点过载

02Fallback 故障转移配置示例

Fallback 会按你填写的节点顺序尝试连接，只要列表里第一个节点还能用，就一直用它；一旦检测失败才会切换到下一个，因此节点顺序本身就是优先级。

proxy-groups:
  - name: "Fallback-Group"
    type: fallback
    proxies: ["HK-主", "HK-备", "SG-备"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

上面的例子里，只要"HK-主"这个节点探测正常，流量就一直走它；探测失败时才依次尝试"HK-备""SG-备"。

03Load Balance 负载均衡配置示例

Load Balance 会把不同的连接（不是同一个连接内的数据包）分配给组内的多个节点，达到分摊流量的效果，同时也天然具备一定的容错能力——某个节点失效时，新连接会分配给其他健康节点。

proxy-groups:
  - name: "LoadBalance-Group"
    type: load-balance
    proxies: ["HK-01", "HK-02", "HK-03"]
    strategy: consistent-hashing
    url: "http://www.gstatic.com/generate_204"
    interval: 300

strategy 字段的两种取值

consistent-hashing：根据连接的目标地址做一致性哈希，同一个目标大概率始终走同一个节点，适合需要"会话保持"的场景（比如某些网站对来源 IP 敏感）。
round-robin：按顺序依次轮询分配给组内节点，分摊更均匀，但不保证同一目标始终走同一节点。

提示：负载均衡不是"多个节点一起加速同一个连接"，而是"不同连接分给不同节点"，所以单个大文件下载的速度不会因为组里节点多就变快，它优化的是多任务并发时的整体吞吐与稳定性。

04该怎么选

如果你只有 1～2 个稳定节点，url-test 已经足够；如果你明确知道某个节点质量更好、希望优先用它、其他节点仅作备用，用 fallback；如果你手上有多个质量相近的节点、担心单节点扛不住多设备同时使用，load-balance 是更合适的选择。三种类型也可以嵌套组合，比如把一个 fallback 组作为另一个策略组的候选项之一，具体取决于你的实际节点情况。

05健康检测相关的两个字段

fallback 和 load-balance 都依赖后台的健康检测来判断节点是否可用，这个检测行为由 url 和 interval 两个字段共同控制，配置不当会导致切换不及时或者检测过于频繁浪费流量。

url：健康检测请求访问的地址，一般用轻量的测速地址（如 http://www.gstatic.com/generate_204），返回成功即视为节点可用，不需要换成真实业务网站。
interval：检测间隔（单位：秒），数值太小会让客户端频繁发起探测请求，增加不必要的流量与耗电；数值太大则节点故障后要等更久才会被发现并切换，一般 300 秒左右是比较均衡的选择。

提示：如果发现 fallback 组"明明节点已经失效了却还是很久才切换"，优先检查 interval 是否设置得过长，这是最常被忽略的一个细节。

06常见问题

Q：load-balance 组里的节点数量有上限吗？
没有硬性上限，但节点数量越多，健康检测的开销也越大；实践中 3～6 个质量相近的节点通常就能取得不错的分摊效果，节点太多反而不利于问题排查。

Q：策略组切换的时候会不会断线？
fallback 和 load-balance 只影响"新连接"分配到哪个节点，已经建立的连接通常不会被强制中断，但如果原节点已经失效，该连接本身大概率也已经无法正常使用，需要客户端重新发起请求。