负载均衡和故障切换有什么作用 ​

客户端的策略组里有好几种类型，名字看起来差不多，行为却完全不同。选错了，效果可能和你预期的相反。

用一句话区分这两个核心概念：

负载均衡关心的是"分摊"，故障切换关心的是"兜底"。

负载均衡：把压力分开 ​

负载均衡的做法是把连接分散到组内的多个节点上，而不是全部压在一个上面。

分配方式通常有几种：

• 轮询 —— 依次使用组内节点
• 按哈希 —— 根据目标地址计算，同一个目标固定走同一个节点
• 按权重 —— 按预设比例分配

它解决的问题： 单个节点的连接数和带宽是有限的。所有流量都走同一个节点时，这个节点就成了瓶颈。

它的代价： 不同连接走不同节点，意味着你的出口 IP 不固定。这对某些场景是问题——例如需要保持会话一致性的网站，可能会因为 IP 变化而要求重新登录或触发验证。

故障切换：出问题时接管 ​

故障切换（fallback）的逻辑不同：平时只用第一个节点，只有它不可用时才切到下一个。

它的工作方式：

优先节点 A ──健康检查──> 正常 → 继续用 A
                      └─> 异常 → 切到 B
                                   ↓
                            A 恢复后可能切回

它解决的问题： 单个节点临时故障时，不需要你手动干预就能继续使用。

它的代价： 切换依赖健康检查，而健康检查有间隔。在检查到异常之前的这段时间里，连接仍然会失败。

三种自动策略的对比 ​

延迟优先 vs 故障转移 ​

这两个最容易混淆，但行为差别很大：

延迟优先（url-test） 会持续测试所有节点，主动切换到延迟最低的那个。即使当前节点完全正常，只要另一个变得更快，它也会切过去。

• 优点：总是用相对较快的节点
• 缺点：出口 IP 会变；延迟低不等于速度快，可能切到一个延迟低但拥塞的节点

故障转移（fallback） 只在当前节点不可用时才切换。节点正常就一直用，哪怕别的更快。

• 优点：出口 IP 相对稳定，行为可预测
• 缺点：不会主动优化，可能一直用着一个"能用但不快"的节点

实用的组合配置 ​

大多数配置文件会提供多个策略组供你选择。一个实用的用法：

• 日常上网用延迟优先组，省心。
• 需要稳定 IP 的场景用手动选择，指定一个固定节点。
• 对中断敏感的长连接用故障转移组，保证有兜底。
• 大流量下载手动选一个当前空闲的节点，避免自动切换打断传输。

健康检查的局限 ​

无论哪种自动策略，都依赖健康检查来判断节点是否可用。这里有两个固有限制：

一是有间隔。 检查每隔一段时间执行一次。在两次检查之间节点出问题，客户端不会立刻知道。

二是判定标准有限。 健康检查通常只验证"能不能建立连接"，不验证"速度好不好"。一个能连上但极慢的节点，在健康检查看来是正常的。

所以自动策略不能替代人的判断。发现异常时，手动切换往往比等待自动切换更快。

注意事项 ​

• 策略组的具体类型和命名由配置文件决定，不同订阅提供的组可能不同。
• 自动策略的切换有延迟，不能保证无感知的故障恢复。
• 频繁的自动切换本身也会带来体验波动，不是越智能越好。

常见问题 ​

为什么自动选择的节点很慢？

延迟优先只看延迟，不看带宽。延迟低的节点完全可能正在拥塞。见节点延迟为什么不能代表实际下载速度。

用了故障转移为什么还是断了？

健康检查有间隔。在检查到异常之前，连接仍然会失败。切换不是瞬时的。

负载均衡会不会导致登录失效？

有可能。不同连接走不同出口 IP，对 IP 变化敏感的服务可能要求重新验证。这类场景建议用手动选择。

该用哪个策略组？

不确定时用延迟优先或手动选择。需要稳定 IP 时用手动选择。见节点地区与使用场景说明。

能不能自己创建策略组？

取决于客户端和配置文件的结构。Clash 系和 Quantumult X 都支持自定义，但需要编辑配置文件，见 Clash Verge Rev 导入教程与 Quantumult X 导入方法。