负载均衡与故障转移：让多个节点撑起稳定连接
只用一个节点，迟早会遇到它限速、抽风甚至掉线的时候。fallback 和 load-balance 这两种代理组类型，就是为了让"某个节点出问题"不再等于"整个网络出问题"。这篇讲清楚它们各自的判断机制、配置写法，以及怎么把多种策略分层组合成一套真正稳定耐用的配置。
为什么单节点扛不住
节点不是恒定不变的："服务商临时维护""上游线路波动""同时在线人数太多导致限速"，这些情况即便节点本身没有下线，也会让实际体验明显变差。
如果代理组用的是 select 手动模式，节点出问题时你只能自己发现、手动切换，中间这段时间的所有连接都会跟着卡顿甚至超时。fallback 和 load-balance 分别从"故障时切换"和"压力分摊"两个角度解决这个问题，二者可以同时使用，覆盖不同场景。
fallback 故障转移的判断机制
fallback 组会按你配置的节点顺序，持续对排在前面的节点做健康检查，一旦当前使用的节点被判定为"不健康"，才会切换到顺序里的下一个：
proxy-groups:
- name: 故障转移
type: fallback
proxies: [主线路, 备用线路A, 备用线路B]
url: "https://www.gstatic.com/generate_204"
interval: 300
max-failed-times: 3几个关键字段：
url：健康检查请求的目标地址，通常用一个体积极小、全球可达性好的测试端点，避免检查本身占用太多流量或因为该网址被限制而误判interval：健康检查的周期（秒），太短会增加不必要的探测流量，太长又会导致故障恢复不及时，300 秒是比较常见的折中值max-failed-times：连续失败多少次才判定为"不健康"，避免一次偶发超时就误切换
fallback 只在"当前节点不健康"时才会切换，即便备用节点延迟更低，只要主节点健康检查正常，也不会主动切过去——这是它和 url-test 最大的行为差异，适合你想固定一个"主力线路"、其他节点仅作为应急备份的场景。
load-balance 的两种分摊策略
load-balance 不是"择优使用"，而是把不同的连接主动分散到组内多个节点上，通过 strategy 字段决定具体怎么分：
consistent-hashing 一致性哈希
- 根据连接的源地址计算哈希，同一个来源大概率固定分到同一个节点
- 对需要"会话保持"的场景更友好，比如某些网站/游戏对连接跳变敏感
- 某个节点被移除时，只有映射到它的一小部分连接受影响，不会全局重新分配
round-robin 轮询
- 新连接依次轮流分配给组内节点，分摊更均匀
- 不保证同一个来源始终落在同一个节点，可能出现"会话跳变"
- 更适合大量短连接、彼此独立、对会话保持没有要求的场景
proxy-groups:
- name: 负载均衡
type: load-balance
strategy: consistent-hashing
proxies: [节点A, 节点B, 节点C]
url: "https://www.gstatic.com/generate_204"
interval: 300没有特殊需求的话，consistent-hashing 通常是更稳妥的默认选择，因为它对连接稳定性的影响更小。
实战：分层组合出一套稳定配置
三种策略并不互斥，实际配置里常见的做法是分层嵌套——外层用 select 给自己留一个手动总开关，中间层用 url-test 或 load-balance 做自动调度，再让 fallback 兜底应对极端情况：
proxy-groups:
- name: PROXY
type: select
proxies: [智能调度, 手动指定]
- name: 智能调度
type: fallback
proxies: [高速分组, 备用线路]
url: "https://www.gstatic.com/generate_204"
interval: 300
- name: 高速分组
type: load-balance
strategy: consistent-hashing
proxies: [节点A, 节点B, 节点C]
url: "https://www.gstatic.com/generate_204"
interval: 300这样一套配置的效果是：日常情况下"高速分组"把连接分摊到三个节点上，一旦这一层整体出现异常（比如所在机房故障），最外层的 fallback 会自动切到"备用线路"，而你在 PROXY 这一层始终保留手动介入的能力。
常见误区
- 把健康检查地址设成访问频率很低的普通网站：这类地址响应时间波动大，容易把"正常节点"误判为"不健康"，务必用轻量、稳定的测试端点。
- load-balance 里混用速度差异很大的节点：轮询/哈希分配不会考虑节点速度，混用会导致部分连接体验忽好忽坏，尽量让同一个负载均衡组内的节点线路质量相近。
- interval 设置过短：频繁的健康检查本身也会消耗节点资源和你的流量，多数场景下不需要低于 300 秒。
如果配置之后发现切换行为和预期不一致，可以对照进阶手册的代理组章节重新核对各字段含义，或打开 Dashboard 面板直接观察每个代理组当前的健康状态。