结论：测试终止于你的使用体验（“奶昔还是非常卡顿”），已切回 wgetcloud。机器数据与这个体验方向一致，但它不足以独立支撑“奶昔比 wgetcloud 差”这个判断——窗口太短、混杂太多、且缺少最关键的一组对照。数据是佐证，你的体感是判据。
两条测量臂覆盖面不同，必须分开读：切换器是主动探针，每 60 秒一次，覆盖机器清醒的全部时间；会话记录是被动的，只有席位真正在干活时才可能留下错误。这三天 yara 的活动量很低，所以后者近乎失明。
| 机器 / 机场 | 切换尝试 / 成功 | 完全不通 | 死出口 | 会话记录 |
|---|---|---|---|---|
| yara · 奶昔（测试臂） | 72 / 36 | 334 | 33 | NET 2 条，活动分母仅 180/119/49 |
| pro · wgetcloud | 0 / 0 | 0 | 0 | 1 条凌晨瞬态，分母 1842 |
| air · wgetcloud | 0 / 0 | 0 | 0 | 1 条服务端 5xx，分母 541/342/200 |
| ethan · wgetcloud | 0 / 0 | 0 | 0 | 3 条服务端 5xx，分母 791/521/272 |
“卡顿”在日志里长什么样：不是断死，是每个节点都能连上、用一会儿就坏、切走再换一个。72 次尝试有 36 次成功——“能切成”恰恰意味着它一直需要切。作为对比，wgetcloud 在正常日通常是每天 1–16 次；而它 08-22 出的那次故障是另一种形态（三个节点全死、216 次尝试零成功），那次事后查明根本原因是 yara 的 WiFi 断了，与机场无关。
缺一组关键对照。要说“奶昔对 yara 更差”，需要同一台机器、同一时期、跑 wgetcloud 的数据。这个没有——yara 换机场之前那段时间里既有 WiFi 断线又有电池耗尽强制休眠，不能用作基线。
三台对照机不能替代它。pro/air/ethan 同期跑 wgetcloud 全部零故障，这能证伪“wgetcloud 全域有问题”，但它们不是 yara——不同机器、不同线路、不同活动量。
窗口太短且被污染。2 天 12 小时里，一整天（08-23）因为换订阅翻动、死出口、多段休眠而作废，真正干净的不足两天。
两条臂互相矛盾。切换器说 334 次完全不通，会话记录几乎全零——因为这几天 yara 的活动量本来就低。任何一条单独拿出来都会误导。
所以这份存档不给“奶昔更差”盖章。一个用户说“卡”，而机器数据方向一致，这已经是能拿到的最好证据；硬凑一个统计结论，反而是把你的体感拿去给数据背书。
这两天半从真实故障里长出来的，切回 wgetcloud 后全部保留：
切换次数不要用 grep SWITCHED 去数——日志里的文案是小写的 switching，用错关键词会得到一个恒为零的结果，而零看起来和"一切正常"完全一样。本页的 yara 数据取自切换历史文件（时间戳一行一次），三台对照机的数据经重数核对一致。同理，判断"是不是我们自己的新加坡节点"在 8/25 之前有两处不同写法，中文节点名会被其中一处漏掉；现已统一。