自动选择、故障转移与负载均衡：策略组应该怎样理解？

订阅中一个看似普通的节点按钮，背后可能是包含多个节点的策略组。组的任务是决定连接交给谁，而不同组采用不同决策方式。使用之前应先了解它根据什么选择，以及这种选择能否满足自己的任务要求。

手动选择适合明确需要的去向

手动组把选择权交给使用者，适合你已经确认某条路径适用于当前任务的情况。它的优势在于选择容易理解和复查，但选中的节点出现问题时，是否自动改变仍取决于配置，不能仅凭组名判断。

切换之前记下当前选择和正在进行的任务。长时间下载或会话中的旧连接可能不会按你期待的方式迁移；应关注新的连接实际用了哪个节点，而不是只看按钮文字是否变化。

以常见的 url-test 策略为例，程序通过指定测试地址获得响应信息，并结合组设置作出选择。探测目标、间隔及切换容差都影响行为，自动选择并不等于对全部互联网业务实时评分。

某个节点访问测试地址很快，却可能在你要使用的网站上表现不同。应把自动探测看成一项参考，再确认实际任务。频繁调整测试间隔或追求很小的延迟差，也未必能改善使用体验。

常见 fallback 策略在当前节点超时后，按配置的顺序寻找可用节点。列表顺序表达的是优先级，不能把它理解为每次一定选择延迟最低者。备用节点也要满足你的基本任务条件。

如果主要路径和备用路径在地区、协议支持或倍率上不同，切换可能改变其他条件。使用前先检查候选范围，避免只关注“还能连上”，却没有注意到新的流量扣量或功能支持差异。

负载均衡策略可以按不同方式把请求交给多个节点。有的按轮转分配，有的利用目标信息保持一定的一致性。具体行为取决于内核和策略配置，应阅读对应说明。

它不自动把多个节点的带宽合并成单次下载的速度，也不改变服务商的额度计费规则。不同连接可能使用不同出口，尤其需要稳定路径的任务，应先确认组的行为与业务条件是否相容。

一次健康检查成功，说明在该时刻、该目标和相应检测方式下取得了预期结果。它不证明所有目标网站可访问、UDP 业务正常、账号具备权限或文件下载达到某个速度。

遇到“显示可用但任务失败”，可以分别记录检测结果与业务结果，不需要先否认其中一个。确认两者是否使用相同组和节点，再检查测试目标与实际任务之间的差别，通常更容易找到线索。

可以把需求写成三句话：哪些条件必须保持、哪些条件可以自动变化、出现失败时希望怎样处理。再据此决定手动选择、自动选择、备用顺序或连接分配是否合适，不必为了看起来高级而全部启用。

完成后检查组内候选、实际节点和新连接结果，保留原配置以便恢复。若订阅更新改变了组成员，也要重新核对。策略组减少手动操作，但不能替代对任务、计费和服务条件的基本判断。