机场节点策略组怎么选？自动选择、故障转移和负载均衡的区别
机场客户端里有“自动选择”“故障转移”“负载均衡”，到底该点哪一个？先看自己的目标：想按探测延迟挑节点，看自动选择；想保留主用与备用顺序，看故障转移；想把不同连接分配给多个节点，再考虑负载均衡。
它们都是选择出口的方法，没有一种设置适合所有场景。下面以 Mihomo 的策略组为例，解释怎么判断。不同客户端的中文名称可能不同，最终要看实际类型和配置。
先分清组名和策略类型
名叫“自动”的组，不一定真的自动选节点；组名可以自行修改。检查配置中的 type，才能知道它做什么。
| 常见类型 | 主要作用 | 更适合的需求 |
|---|---|---|
手动选择 select |
由你指定节点或下一级策略组 | 固定条件做对照测试 |
自动选择 url-test |
根据探测延迟与切换容差选择节点 | 减少手动比较延迟 |
故障转移 fallback |
根据可用状态与候选顺序选择备用 | 明确主用、备用的优先级 |
负载均衡 load-balance |
按策略为不同连接分配节点 | 有多个可用出口并愿意验证兼容性 |
策略组还可以包含其他策略组。因此，看到上层选中了“自动”，仍要继续看它最终用了哪个节点。Mihomo 通用字段文档说明了组名、类型与候选成员的关系。
自动选择：比较探测表现，不是下载比赛
url-test 的选择依据包括对测试地址的延迟结果。它并没有替你下载大文件，也没有测遍你常用的所有网站。
其中，tolerance 是切换容差，单位为毫秒。结合当前实现来看，当原节点仍可用时，新候选只快一点，不一定触发更换。这能减少为了微小延迟差反复切换的情况。查看自动选择文档及对应选择逻辑。
所以，“列表里另一个节点数字更小，为什么没切过去”不一定是故障。先确认测试时间、测试地址和容差设置，再判断结果。实际应用顺畅时，也没必要为了一个更好看的数字不断刷新。
故障转移：先想清楚谁是主用
fallback 更关注候选顺序。官方说明指出，当前节点超时后，会按顺序选择第一个可用节点。查看自动回退文档。
假设你更喜欢节点 A 的使用体验，把 B 留作备用，就需要核对组内的实际顺序。不要期待 B 的延迟偶尔更低，策略组就一定切过去。
也不要把“能切到备用”理解成“正在进行的通话和下载绝不会中断”。已有连接是否能继续、应用是否会重新连接，还取决于故障位置与应用行为。重要任务开始前，先确认备用节点能单独正常使用。
负载均衡：分配连接，不是把带宽相加
负载均衡容易被误解成“两个节点同时给一个下载加速”。它的核心是分配请求与连接，不能据此推算单条连接会获得两个节点的速度之和。
Mihomo 提供不同分配策略，例如轮流分配，以及让相同目标地址倾向于使用同一个节点的策略。配置不同，观察到的出口分布也会不同。查看负载均衡文档。
一个应用可能同时连接多个域名。即使采用按目标分配的方式，也不应直接推断整个应用的所有请求都会使用同一出口，更不能保证出口 IP 永远不变。
如果更换策略后出现页面状态异常或反复重连，可以暂时固定一个节点，保持其他条件不变再测试。这个对照能帮助缩小范围，但不能单凭恢复正常就断定问题一定来自负载均衡。
自动切换不符合预期，先检查四项
- 连接是否进入了这个组。 查看连接记录，确认目标应用实际命中的策略，而不只看首页开关。
- 组里是否有合适的候选。 过滤条件可能排除节点，嵌套组也可能改变你以为的选择范围。
- 探测是否覆盖了这些节点。 官方文档区分组内直接列出的节点和通过代理集合引入的节点；后者应核对集合自身的健康检查配置。
- 探测何时更新。 检查测试间隔与懒惰测试设置；未使用的组可能不会持续测试，界面上的旧数字不能当成实时状态。
这些检查项可对照Mihomo 策略组通用字段逐项确认。测试越频繁，产生的请求也越多；不要把缩短间隔当作修复所有问题的办法。
普通使用者可以怎样做选择
先用手动模式确认几个候选节点在自己的网络下可用，再决定是否需要自动化。浏览资料时，可以比较自动选择与固定节点的体验；有明确主备偏好时，重点验证故障转移；考虑负载均衡时，则先确认多个候选都满足自己的应用需求。
每次只改变一个设置，记录时间、当前出口、使用的应用和异常现象。短时测试正常，只能说明这次条件下可用，不能替代长期观察。
想弄清策略组与规则、全局模式的关系，可以继续看新手分流指南；想判断延迟与实际体验的差别，可以看节点测速记录方法。
拿不准自己该选哪种策略组，可以通过 Telegram 联系我交流。 告诉我客户端名称、主要用途和遇到的现象即可，无需发送完整订阅或账户密码。