判定的两个条件

自动切换不是「谁分高换谁」。它需要两个条件同时成立才动手。下面把这两个条件分开讲，因为多数误解都来自把它们看成一件事。

条件一：分差要够大

新线路评分必须比当前线路高出 25% 以上。假设当前 80 分，新线路需要达到 100 分才够格切换。分差在 25% 以内时，客户端保持当前线路不动。

条件二：要连续成立

分差条件必须在连续三轮采样中都成立。中间任何一轮不成立，计数归零重来。这样可以滤掉偶然的尖峰读数。

两个条件的组合与结果

分差	连续轮数	是否切换	典型情形
< 10%	任意	不切换	两条线路基本持平
10%–25%	任意	不切换	分差不够明显
≥ 25%	1 轮	不切换	单次尖峰，需再确认
≥ 25%	2 轮	不切换	接近成立，再等一轮
≥ 25%	3 轮	切换	两个条件都满足

为什么分差用相对值

相对值比绝对值更合理。当前 60 分时提升 10 分是 17%，当前 90 分时提升 10 分只有 11%。用相对值能让低分线路更容易被替换掉，避免一直卡在一个刚够及格的线路上。

为什么需要三次确认

单轮采样可能撞上瞬时限速或一次路由抖动。三轮确认把「持续劣化」和「偶尔不好」区分开，代价是切换会晚 60 到 90 秒发生。

切换的代价

切换不是免费的。连接需要重建，正在进行的长连接会中断。了解代价之后，才知道什么时候该等自动切换，什么时候该手动处理。

切换期间会发生什么

客户端建立到新节点、重新协商、验证通路，然后恢复路由。整个过程通常 1 到 3 秒。期间已建立的 TCP 连接会断开，应用层会自动重连，但正在传输的文件需要重传。

哪些应用能承受切换

网页浏览、视频播放（起播阶段之后）、消息收发都能自动恢复。会议与游戏在切换瞬间会有可感知的中断，因此这两类用途更应该提前锁定节点。

下载时为什么不建议自动切换

下载是长连接加连续数据流。切换导致的重传成本高，而分差达到 25% 意味着新线路确实明显更好，多花几秒重传是值得的。前提是下载工具支持断点续传。

四种线型的比较

不同的使用者对「稳定」的定义不同。下面这四类线型对应不同的取舍，选错了要么感觉慢，要么感觉不稳。

四种连接线型的取舍

线型	切换行为	延迟表现	适合	代价
完全自动	按 25% 阈值自动切	跟随最优，波动较小	日常浏览、临时用途	偶发 1–3 秒切换
分组自动	组内自动切，不跨组	更稳定，牺牲跨区最优	偏好某个地区的用户	可能错过更优的邻近线路
手动锁定	不切换	完全可预期	会议、游戏、绑定出口的业务	节点劣化时需手动解除
分组 + 锁定	不切，节点固定	完全可预期	长时间任务	维护期间可能中断

分组自动的价值

默认的分组自动会先按用途分组，再在组内排序。它的好处是稳定：不会因为某个远端节点偶然测出低延迟，就把你拉过半个地球。

什么时候值得锁定

三种情况值得：会议与游戏这类对中断敏感的场景、绑定固定出口的业务系统、以及长时间上传或备份。其余情况保持自动更省心。

切���的三个判定细节

除两个主条件外，实际判定还有三个细节。知道它们，能解释一些「看起来不该切却切了」的现象。

细节一：分组边界不跨越

只在当前分组内部比较。东亚组的节点不会因为北美组节点分数更高而被选中，即使北美更优。跨组切换需要手动改分组。

细节二：锁定状态优先

一旦手动锁定，判定流程整体停止，连采样都不会用来触发切换。锁定期内采样照常进行，只是不用于判定。

细节三：切换有冷却时间

一次切换之后有 60 秒冷却期。这段时间内即使有更优线路也不会立即再切，避免连续抖动带来的连续中断。

三个判定细节与可观察现象

细节	规则	可观察到的现象
分组边界	只在组内比较	分数更高的其它组节点不会被选
锁定优先	锁定时判定流程停止	节点变差也不自动换
冷却时间	切换后 60 秒内不再切	短时间内的第二次换线会延后

弱网与网络切换

从 Wi-Fi 切换到蜂窝、或从室内走到室外，客户端会立刻感知到。这个场景的判定和拥塞判定不同，处理方式也不同。

网络切换时发生什么

本地链路变化会让已有连接直接失效。客户端在检测到后立刻进入重连，重连前会先做一次快速采样，选出适配新网络的线路，而不是沿用旧选择。

重连与自动切换的区别

重连是被动触发的——原连接断了才重连；自动切换是主动判断——原连接还能用，但发现更好的线路才换。前者不可避免，后者是优化。

为什么蜂窝网络上要区别对待

蜂窝网络按流量计费，且带宽波动比 Wi-Fi 大。在蜂窝上优先选低延迟低吞吐的节点，比选高吞吐节点更省流量也更稳定。

判定不成立时怎么排查

如果线路明显变差却没有切换，按下面四步排查。前三步能覆盖绝大多数情况。

1. 确认是否处于锁定状态：锁定时判定流程整体停止
   • 在节点列表看是否有锁定标记
   • 解除锁定后观察下一轮采样
2. 确认分组是否限制了候选：跨组候选不参与比较
   • 临时切到「全球均衡」分组观察
   • 若立即切换，说明问题出在分组边界
3. 确认分差是否达到 25%：分差不足时保持当前线路是有意为之
   • 对比当前节点与组内最优节点的评分
   • 当前 80 分时新线路需达 100 分
4. 确认是否处于冷却期：切换后 60 秒内不再切
   • 等待冷却结束后再观察
   • 冷却期通常不会超过一分钟

切换记录怎么看

客户端会在诊断里保留近七天的切换记录。这份记录能回答「为什么昨晚变慢了」这类问题，也是判断当前配置是否合适的主要依据。

切换记录里能读出的信息

记录项	含义	说明什么	建议动作
切换时间	发生切换的时刻	是否在高峰时段	对照高峰时段调整分组
切换方向	从哪个节点到哪个节点	是否跨组或跨区	跨区切换说明分组设置偏窄
触发原因	分差达标或重连	是优化还是被动	被动重连频繁说明本地网络不稳
间隔	两次切换之间的时长	冷却期后是否又切	间隔过短说明线路在剧烈波动
时长	切换耗时	重建是否顺畅	超过 5 秒需检查本地环境

什么样的记录算异常

一小时内置换超过五次，通常意味着当前线路在剧烈波动，或本地网络本身不稳定。这时应该先查本地，而不是继续调客户端。

五类场景的实际切换记录

下面是编辑部在同一账号上记录到的五组切换情况。每组对应一种典型用途，记录了切换次数、时间分布与触发原因。

五类场景的切换记录（连续三天观察）

场景	切换次数	多发时段	主要触发原因	平均耗时
网页浏览	4 次	晚高峰	分差达标	1.4 秒
视频播放	2 次	晚高峰	网络切换	1.8 秒
语音会议	1 次	—	本地网络切换	1.2 秒
游戏对战	0 次	—	已手动锁定	—
大文件下载	3 次	整点前后	分差达标	2.6 秒

为什么会议的切换次数最少

不是因为会议时线路更稳，而是因为会议通常在固定时段、单一网络下进行，客户端也往往被手动锁定。切换次数少是配置的结果，不是网络的表现。

下载的切换耗时最长

重建连接后需要重新协商传输窗口，这一步在大流量连接上更慢。2.6 秒的耗时里，有近两秒花在窗口协商上，而不是建连本身。

切换与业务连续性的取舍

每类业务对中断的容忍度不同。同一套切换机制，在不同业务上的表现差别很大。下面按容忍度从高到低排列。

业务的连续性容忍度与推荐配置

业务类型	中断容忍度	推荐配置	切换影响	备注
静态内容	很高	完全自动	无感	页面可能需刷新
网页浏览	高	完全自动	无感	恢复快
即时消息	高	完全自动	自动重连	历史消息不丢
流媒体	中	分组自动	需重新缓冲	起播阶段避免切换
大文件传输	中	分组自动	需断点续传	支持续传的工具更稳
语音会议	低	手动锁定	1–3 秒断续	锁定最稳
在线游戏	低	手动锁定	掉线重来	锁定最稳
支付与交易	很低	手动锁定	可能需重新验证	不建议切换

为什么支付类要锁定

交易过程中的会话与出口绑定，切换导致重新验证的代价很高。这类场景应该在开始前锁定节点，全程不切换。

流媒体的特殊之处

视频起播需要缓冲几秒，如果此时切换，已经缓冲的数据作废，需要重新起播。播放开始后缓冲需求下降，切换的代价反而变小。

切换的三个隐藏成本

除了刚才说的一到三秒重建，切换还有三个容易被忽略的成本。了解它们，能更准确地评估「该不该切」。

成本一：连接重建期间的空窗

重建期间流量走不出去，缓存的请求会堆积。如果这时正在做连续操作，用户感知到的是「点了没反应」，而不是「慢了一点」。

成本二：DNS 重新解析

新节点的出口 IP 不同，域名需要重新解析。解析本身通常在几十毫秒，但若本地 DNS 缓存失效，会叠加到首包延迟上。

成本三：应用层重连逻辑

TCP 断开后，各应用的重连策略不同。有的立即重连，有的等几秒，有的需要用户操作。这部分延迟不受客户端控制。

三个隐藏成本的范围与判断

成本	典型时长	影响对象	能否优化	表现
连接重建空窗	1–3 秒	所有应用	不能	点击无反应
DNS 重新解析	30–80 毫秒	首次请求	部分	首包变慢
应用层重连	0–10 秒	长连接应用	不能	需重新登录

为什么这三个成本无法消除

它们都来自「换一个出口」这件事本身。要消除只能不切换，而是否切换取决于线路质量。这个权衡没有完美解，只能按业务类型选择。

切换记录的时间分布

把三天内的切换按小时统计，能看出切换集中在什么时段。下面这组记录来自一个以网页浏览为主的账号。

切换的时段分布（三天合计 11 次）

时段	切换次数	占比	同期网络状态	解读
08:00–10:00	1 次	9%	平稳	偶发网络切换
10:00–12:00	0 次	0%	平稳	无
12:00–14:00	1 次	9%	平稳	偶发
14:00–18:00	0 次	0%	平稳	无
18:00–20:00	1 次	9%	开始波动	分差开始达标
20:00–22:00	6 次	55%	高峰拥塞	切换集中区
22:00–24:00	2 次	18%	回落	仍在调整

高峰期的切换为什么会变多

拥塞让各节点的评分差距拉开，25% 的阈值更容易被跨过；同时线路本身在波动，一轮不达标就重新计数。这两点叠加，使高峰期切换明显变密。

切换变密不一定是坏事

切换频繁说明引擎在积极跟随质量变化。真正需要担心的是切换之后依然卡，那才说明当前分组内的节点整体不够用，需要换分组或换方向。

把判定条件写成你自己能用的判断表

前面讲的规则，最终目的都是让你在没有客户端面板时也能推断行为。下面这张表把判定逻辑压缩成可以直接照着判断的形式。

看到现象后的推断对照

你观察到的	引擎内部状态	你该做什么
没换线路，且新节点分差 20%	未达 25% 阈值	等下一轮，或手动锁定新节点
没换线路，但新节点明显更快	可能在冷却期	等 60 秒再看
换线后立刻又换回	冷却期结束但分差反转	手动锁定更稳的那个
锁着不动且越来越慢	锁定状态，判定已停	解除锁定
每隔几分钟换一次	线路在阈值附近抖动	换分组或换方向
一小时内换五次以上	本地网络或上游剧烈波动	先查本地网络

这张表的使用方式

先看第一列找到你观察到的现象，再看第二列理解引擎在做什么，最后看第三列执行动作。多数情况能直接落到第三列，不需要深入了解打分算法。

引擎状态一览

客户端的判定流程有五个状态，每个状态对应不同的行为。把它们列出来，可以解释几乎所有「它为什么这么做」的问题。

五个引擎状态与对应行为

状态	触发条件	采样行为	判定行为	用户可见表现
空闲待机	未连接	每 5 分钟一轮	不判定	列表数字缓慢更新
已连接	连接建立	每 30 秒一轮	按阈值判定	节点与读数实时刷新
锁定状态	手动锁定	照常采样	判定停止	节点不变化
冷却中	刚完成切换	照常采样	延后处理	60 秒内不切换
重连中	连接失效	快速采样一次	不判定	状态显示重连

空闲待机为什么还采样

为了让连接时能立刻给出合适的候选，空闲期也在维持采样。空闲采样频率低，只维持一个大致的排序，不做精细判定。

冷却中与锁定的区别

冷却是系统主动设置的短暂限制，一分钟后自动解除；锁定是用户主动设定的持续状态，需要手动解除。混淆这两者会导致误判「为什么它不切」。

七条判定规则汇总

前面各节讲的规则分散在多处。这里集中列一遍全部七条，便于一次看完，也方便日后核对版本变化时逐条比对。

七条规则之间的关系

规则一与规则二构成主判定，规则三限定候选范围，规则四让用户可以完全接管，规则五防止连续中断，规则六处理外部变化，规则七负责节点自身的健康度。四者叠加，引擎既有自主性，又不会过度动作。

编辑器说明

本页的阈值与状态划分来自客户端 v4.2.0 的公开设置与实际观察。切换记录部分为本站在自有账号上的观察样本，用于说明分布规律，不构成对具体网络环境的承诺。

需要说明的是，本页刻意不写「什么情况下网络一定好」这类判断。网络质量受接入线路、时段、目标站点与本地负载共同影响，任何脱离这四项的结论都不成立。本页只写客户端的行为规则，这部分是确定的。

把切换记录用起来：一次完整的复盘

切换记录最有价值的用法是做复盘。下面按一个真实场景走完整流程：从发现「昨晚很卡」到定位到具体原因，全程不依赖猜测。

第一步：看切换次数

昨晚 21 点到 23 点之间切换了 7 次。数量本身还不算异常，但结合下一步就能判断。

第二步：看每次切换之后的读数

七次里有五次，切换后的延迟仍然在 120 毫秒以上。切换了但没变好，说明问题不在「当前节点不够优」，而在更上游的地方。

第三步：看分组

当时分组是「亚洲优先」，而实际卡顿的站点属于欧洲方向。这个站点的流量被错误地归进了亚洲分组，引擎只能在那组里挑，再怎么切也切不到对的方向。

第四步：改分组而不是改节点

把分组改成「全球均衡」后，同样的时间窗内切换次数降到 2 次，延迟回到 60 毫秒左右。问题定位在分组设置，不在节点质量。

一次完整复盘的四个步骤

步骤	看什么	本次读数	结论
一	切换次数	2 小时内 7 次	偏密，需继续查
二	切换后的读数	5 次仍 > 120 ms	切换了但没变好
三	分组设置	亚洲优先，与目标站点不符	候选范围错了
四	调整后复测	2 次，延迟 60 ms	分组是根因

这个复盘的价值

如果当时直接手动换节点，很可能换一个还是卡，因为根本问题是候选范围。复盘的价值在于把「感觉慢」变成「分组设置错误」这个可执行结论。

切换前后的对照读数

下面是编辑部记录的一组切换前后数据，用于说明「切换确实有效」与「切换也救不了」这两种情况的差别。

切换前后的对照读数（同一时段同一目标）

场景	切换前延迟	切换后延迟	切换前抖动	切换后抖动	结论
候选范围内有更优节点	126 ms	61 ms	34 ms	11 ms	切换有效
分组内无更优节点	128 ms	124 ms	36 ms	33 ms	切换无效，需改分组
本地出口拥塞	118 ms	117 ms	31 ms	30 ms	切换无效，需查本地
目标站点自身慢	142 ms	139 ms	22 ms	21 ms	切换无效，属目标侧

怎么看这张表

四种场景里，只有第一种切换后读数明显改善。这说明切换机制本身是有效的，若切换后没变化，根因在别处，不该反复手动切换。

判断口诀

切换后延迟降了，说明之前选错了候选；切换后没降，说明候选里没有更好的，得扩大范围或换方向。这个判断能省掉大量无效重试。

切换的必要条件清单

把「这次切换值不值得」拆成可以逐条核对的条件。下面这张表既可以用来判断当前该不该手动切换，也可以在复盘时反推历史切换是否合理。

一次切换值当发生的六项条件

条件	怎么判断	不满足时	影响
分组内有更优节点	对比组内前几名评分	改分组或锁定	切换无效
分差达到 25%	对比当前与最优评分	等待	切换太早
不处于冷却期	看上次切换时间	等待 60 秒	切换被延后
未处于锁定状态	看节点列表锁定标记	解除锁定	不会自动切
业务能承受中断	看用途类型	改用锁定	中断造成损失
本地网络正常	本地其他站点是否正常	先查本地	切换无效

这张表的实际用法

手动切换前扫一遍，六项里有任何一项不满足，这次切换很可能白费。条件全满足时再切，命中率会明显提高。

切换对不同连接类型的影响

客户端建立的连接不止一种，它们在切换时的表现差别很大。了解这一点，能解释为什么有时切换代价明显更大。

长连接与短连接

浏览器打开页面产生的是短连接，一次请求结束即断开。切换影响小。视频会议、游戏、长连接下载产生的是长连接，切换时必须重建，这类场景对中断最敏感。

UDP 与 TCP 的差异

基于 UDP 的传输在切换时不需要重新握手，重建更快，但丢失的数据无法补传。基于 TCP 的传输能保证顺序与重传，但重建时需要重新协商。

三类连接在切换时的差异

连接类型	典型应用	重建耗时	中断影响	建议
短连接	网页浏览	几乎无感	页面可能需刷新	放心使用自动
长连接（TCP）	消息同步、下载	2–4 秒	需重连或续传	用分组自动
实时流（UDP）	语音、游戏、直播	1–2 秒	瞬时中断明显	建议手动锁定

为什么实时流更怕切换

实时流没有缓冲可吸收中断，一帧数据丢掉就是丢掉。TCP 传输则会重传，看起来「慢一点」但内容完整；UDP 传输断了就是断了。

切换预算：一次连接能用多久

把切换成本与使用时长放在一起算，才能判断值不值得切。假设一次切换代价是 2.5 秒，那么它需要至少持续两分钟才划算。

切换代价与可用时长的对照

使用时长	切换占比	体感影响	是否值得切
10 秒	25%	明显中断，不划算	不切
1 分钟	4.2%	可感知，不划算	不切
2 分钟	2.1%	轻微，可接受	看分差
5 分钟	0.8%	几乎无感	值得切
30 分钟	0.14%	无感	值得切

这个对照的用法

短任务，比如查个资料就关掉，不值得为了几十毫秒的提速去承担一次中断。长任务，比如开一小时的会议中途重连一次，代价可以忽略。

按业务类型给一个粗略的取舍

语音会议一般持续 30 分钟以上，重连一次 2.5 秒完全可接受，游戏对局通常十几分钟，两者都可以容忍偶尔的切换。真正不能容忍的是支付与提交类操作，窗口只有几秒。

切换预算的算法

判断一次切换是否值得，可以用「分差百分比 × 预计使用时长」与「切换代价 × 60」相比。前者是能省下的时间，后者是切换消耗的秒数乘以分钟数，前者大于后者就值得切。

为什么这个算法只是参考

它假设分差能线性转化为体验提升，实际上并非如此。丢包与抖动带来的改善往往大于线性预期，而跨洲节点可能因为路径不同产生完全不同的体验。实际判断仍应看切换后的读数变化。

常见问题

下一步

判定机制清楚之后，接着看多设备情形：同一账号在五台设备上是怎么各自取线的。