自动选择并不等于绝对无感，更不能保证永不断线。本文从健康检查URL、测速间隔与容差阈值三项核心参数切入，深入对比url-test与fallback的行为模式与适用场景。
在网络代理的使用过程中，“自动选择”往往被很多用户寄予厚望，认为只要勾选了自动选择，网络就会永远保持在最快状态且永不掉线。然而在实际使用中，部分用户却常常抱怨：“为什么开着自动选择，在线会议依然偶发卡顿？”或者“为什么网页访问时常频繁要求重新登录验证码？”要解决这些困扰，必须客观理解 Clash/Mihomo 内核中“自动选择”（url-test）与“故障回退”（fallback）的真实运作机理。
首先看“自动选择”（url-test）。它的工作逻辑可以概括为“定期探针测速，优胜劣汰”。客户端会按照配置中设定的时间间隔（interval，通常以秒为单位），并发或依次向指定的测试地址（如 Google 或 Cloudflare 的测试探针）发起轻量级 HTTP HEAD 请求。内核记录下每个候选节点从发起请求到收到首包响应的往返时间（RTT），然后将当前策略组的实际出站出口自动切换至当前耗时最低的节点。
但很多用户忽略了一个关键参数：容差阈值（tolerance）。如果未配置容差或容差设为 0，当节点 A 延迟为 120ms，节点 B 延迟为 118ms 时，一次微小的网络波动就会导致出口在 A 和 B 之间反复跳跃。由于不同服务器的公网出口 IP 完全不同，这种频繁的 IP 跳变会直接触发目标银行、论坛或协同办公系统的风控机制，导致用户的登录凭据频繁失效。合理的做法是配置 50ms 到 100ms 的容差，只有新节点的延迟显著优于当前节点时才触发切换。
再看“故障回退”（fallback）。它的工作逻辑是“优先稳定主用，故障依次替补”。在 fallback 策略组中，节点的排列顺序至关重要。排在列表第一位的为首选主用节点，后面的节点均为备用冗余。在日常状态下，只要首选节点的健康检查保持连通（即 HTTP 响应状态码正常且未超时），无论其延迟是 50ms 还是 150ms，系统都会始终坚守在该节点上发包。只有当首选节点发生彻底断流或超时被标记为不可用时，系统才会顺次切换至备选的第二节点；一旦首选节点恢复健康，流量通常会再次切回主用节点。
为了帮助大家更清晰地在两类策略间做出取舍，请查阅下方的核心机制比对：
| 特性维度 | 延迟自动优选 (url-test) | 故障顺序回退 (fallback) |
|---|---|---|
| 调度目标 | 始终追求最低的瞬时响应延迟 | 始终追求出站 IP 与会话的长效稳定性 |
| 出站选择依据 | 候选池中所有存活节点的 RTT 测速排序 | 按照配置文件中的节点物理顺序自上而下 |
| 切换敏感度 | 较高，受网络抖动与测试间隔影响较大 | 较低，仅在存活状态变更时触发切换 |
| 出口 IP 稳定性 | 易发生动态漂移（建议配合 tolerance） | 极高，主节点正常时不发生无谓漂移 |
| 适用业务场景 | 大文件分段下载、网页快速检索、轻量浏览 | 远程办公登录、游戏联机、流媒体长会话 |
需要特别强调的是，技术上不存在所谓的零断线神话。无论 url-test 还是 fallback，它们感知节点异常都依赖周期的健康探测。如果测试周期设置为 300 秒，而节点在第 10 秒发生骨干网单向丢包，那么在接下来的 290 秒内，内核依然会认为该节点可用，直到下一次探针超时或底层 TCP 连接彻底重置。因此，追求绝对高可用时，应将探测间隔与容差参数调整到平衡状态，而非盲目迷信自动切换。