自动回退与负载均衡：代理组应该怎么选

摘要：按主备切换、请求分配和会话稳定性三种需求，理解代理组策略的适用范围。

代理组里放了多个节点，究竟会优先使用一个，还是轮流分配请求？这取决于组的类型。日常浏览、长期会话和多项下载，对切换行为的要求不同。先明确想解决的是断线后的备用连接，还是多条连接的分配，再选择策略，通常比堆更多节点更有效。

Mihomo的自动回退文档说明，当前节点超时后，会按配置中的代理顺序寻找第一个可用节点。因此，列表顺序表达了优先级，并非延迟排名。

例如，你希望平时用甲，甲不可用时改用乙，就把甲排在乙前面。备用节点也应具备访问目标的条件，否则切过去仍然失败。不要把“检测页能打开”理解成所有网站都可访问，选择前还应检查目标业务。

回退可以帮助后续请求选择出口，却不应被当作既有会话无缝迁移的承诺。聊天、上传或远程连接中断后，应用是否重连、能否续传，要看应用本身；观察到切换成功，也不代表原来的任务已经恢复。

负载均衡文档列出三种策略。轮询会将请求分配给组内不同节点；一致性哈希倾向于让相同目标使用同一节点；粘性会话结合来源与目标选择节点，缓存十分钟后过期。目标为域名时，文档注明按顶级域名匹配，不能理解成逐条网页地址固定出口。

这种分配不等于把几条线路的带宽合成一条。单个下载是否建立多条连接，以及远端是否允许分段，是另外的问题；仅修改代理组，就期待速度翻倍，缺少依据。

经常使用需要持续会话的服务，可以先固定一个合适节点，或采用明确的主备顺序。若确实需要分散多条独立连接，再考虑负载均衡，并留意出口变化是否影响服务体验；粘性策略也不能保证永不换节点。

如果某个任务不适合频繁切换，就先为它指定单个节点，并保留重连的操作入口。

调试时只改变一个组的类型，保留原列表和检测设置，用几次公开网页请求观察连接日志。确认每次选中了谁，而不是只看组名上的绿色图标。不要通过高频检测或反复切换制造额外负担，记录行为符合预期后，再逐步调整。