Clash自动选节点和故障切换有何区别？url-test与fallback怎么选

Clash类客户端里的自动选节点与故障切换，解决的是不同问题。在Mihomo配置中，url-test比较指定测试的延迟，fallback按候选顺序寻找可用节点。一个像挑当前较快的收银台，一个像常去的窗口关门后再找下一家。

url-test：根据测试结果选择

Mihomo的url-test文档定义了自动测速组，并提供测试地址、间隔和切换容差等设置。其当前实现会考虑节点是否可用和最近测试延迟；手动固定选择也可能影响结果。

容差可以理解为“快一点点时，先别搬家”。小幅差异未必触发切换，有助于避免节点来回跳。界面上的“自动”只是名称，实际策略仍应看组类型，不能根据名字猜功能。

fallback文档说明：当前节点超时时，按配置顺序选择第一个可用候选。因此，把哪条线路放前面会影响选择；它不负责持续寻找最低延迟。

需求	优先了解的策略
希望依据指定测试的延迟选线	url-test
希望保留首选，异常时换备用	fallback

这只是选择依据，不保证所有网站和游戏都达到最佳表现。把自动测速组当成万能导航，就像拿超市排队速度预测高速公路堵车，热心，但跨度有点大。

初次设置时，可以先选少量熟悉的候选线路，记录组类型、测试目标、选中节点与实际访问结果。候选越多不等于判断越准；名单里混入用途完全不同的线路，也会让自动结果难以理解。

先看目标连接是否真的使用这个策略组。如果规则指向另一个手动组，当前组测速再积极也帮不上忙。规则与全局模式的关系可参考本站Clash模式选择指南。

再检查测试间隔和lazy设置。通用组配置说明指出，lazy开启时，未被选用的组可以不执行测试；由提供者引入的节点，其健康检查还需核对提供者配置。不能只修改一个数字，就假定所有节点都在实时体检。

观察切换时留意最近测试时间，别把昨天的数字当作现在的路况。调整前保留原配置，一次只改一项，再做同条件对照；有正在进行的会议或下载时，先避免频繁手动切换。

测试地址、游戏服务器和视频服务的网络路径可能不同。节点能访问测试页，不代表目标业务同样顺畅；低延迟也不能直接换算为高下载速度。

记录实际出问题的应用、时段和所选出口，用目标业务做对照，再决定调整候选顺序或测试配置。更多区别可看节点延迟与游戏卡顿。把策略当助手，别把它当会读心的网管。

作者：仓老师机场观察