68 万次探测复盘:7 家机场、15 天数据里的 5 个稳定性真相
本站的 节点状态页 上线半个月了。前两篇分别讲了 监控方法论 和 探针的实现,这篇是交卷时刻:用 15 天的真实数据回答一个问题——持续监控到底能看出什么?
先说口径,再看结论。
数据口径
| 项目 | 值 |
|---|---|
| 时间窗 | 2026-10-15 ~ 10-30(约 15 天) |
| 监控对象 | 本站测评的 7 家机场,订阅内共 612 个节点 |
| 探测方式 | 每 10 分钟对每个节点做一次 TCP ping(方法局限见 #1) |
| 探测总量 | 683,175 次 |
| 探针位置 | 美国 VPS,只代表国际方向连通性 |
真相一:在线率分层明显,头部到尾部差 21 个百分点
四家机场(一分机场、动力港、紅葉、飞兔云)站在 96% 以上,属于"平时无感"梯队;尾部两家(NanoCloud、WY Cloud)跌破 80%,意味着平均每天有 4-5 个小时,你的节点列表里有相当比例是死的。(NanoCloud 为剔除 IPv6 误报节点后的修正值,来龙去脉见文末"插曲")
注意一个细节:头部的 97.9% 而不是 100%。即使最稳的机场,半个月里也有三十多个小时的探测失败——100% 在线是不存在的,区别只在于失败是"零敲碎打"还是"成建制掉线"。
真相二:延迟低 ≠ 稳定,这是数据里最反直觉的一条
把两张图对照着看:
- NanoCloud 延迟最低(p50 仅 76ms,直连线路),在线率却排在倒数(修正后 79.8%)
- 一分机场延迟偏高(p50 184ms),在线率全场第一(97.9%)
原因不难理解:低延迟的直连线路暴露在封锁火力第一线,死得快;绕一点路的中转/专线节点反而活得久。"快"和"稳"在当前的对抗环境下经常是互斥的,选机场时要哪个,取决于你的用途。
拆协议看更有意思:NanoCloud 的 vless 节点在线率 99.8%,拖后腿的是 TUIC 节点(仅 62%)——UDP 在国际链路上更容易被运营商 QoS,且 UDP 探测本身的误差也比 TCP 大(收不到 ICMP 回包不等于节点一定死)。所以"UDP 协议节点偏不稳"这个结论,我们只敢下一半。
再补一刀 p99(最慢的 1% 探测):
| 机场 | p50 | p95 | p99 |
|---|---|---|---|
| 紅葉 | 226 | 245 | 307 |
| 飞兔云 | 210 | 271 | 408 |
| 动力港 | 211 | 297 | 420 |
| 牛逼机场 | 253 | 278 | 506 |
| WY Cloud | 212 | 274 | 943 |
| NanoCloud | 76 | 141 | 317 |
| 一分机场 | 184 | 389 | 8197 |
紅葉的 p99 只有 307ms,曲线最平滑,几乎不抽风;一分机场虽然在线率第一,p99 却高达 8 秒——偶尔会出现极慢的节点。中位数告诉你常态,p99 告诉你最坏情况,两个都要看。
真相三:节点多 ≠ 稳
WY Cloud 订阅里有 327 个节点,是第二名(72 个)的四倍多,在线率却只有 76.8%,全场垫底。看每日曲线更明显:10-22 到 10-24 连续三天走低(65% → 56% → 47%),直到 10-29 才恢复。
大节点池通常意味着节点来源杂、质量参差,还摊薄了维护精力。挑机场时"节点数量"是最不该看的指标——300 个节点里 250 个是炮灰,不如 20 个节点个个能打。
真相四:集体掉线是真实存在的,而且没人能独善其身
半个月里抓到两次波及多家机场的事件:
10-19 凌晨 05:20–08:00(北京时间):紅葉、飞兔云、动力港、WY Cloud 在 2.5 小时内反复"归零→恢复→再归零",呈震荡式劣化。这正对应 敏感时期自救 里描述的场景——封锁通常是分批、反复加压的,不是一刀切的。
10-24 15:11 → 10-25 02:00(北京时间):半个月里最大的一次。7 家中有 5 家同时归零,时间线:
| 时间(北京) | 全站平均在线率 |
|---|---|
| 10-24 12:00 前 | 91.5%(正常) |
| 10-24 15:00 | 11.4%(崩塌开始) |
| 10-24 15:00–21:00 | 6.7%(持续谷底) |
| 10-24 24:00 | 35%(缓慢恢复) |
| 10-25 03:00 后 | 91.5%(完全恢复) |
我们专门核对了各机场的节点 IP 段:7 家之间没有任何 IP 重叠,基础设施完全独立。独立的基础设施在同一分钟集体死亡,指向的结论只有一个——压力来自机场之外。
这里必须诚实交代一个监控盲区:当"所有"机场同时归零时,探针自身出口故障也会产生一模一样的数据。我们能确认探针服务器当时是活的(网站访问统计正常),但无法排除其国际出口短暂受限的可能。不过从持续 11 小时、分阶段恢复的曲线形态看,更像一次真实的封锁波而非单机故障。这也是为什么 敏感时期自救 强调"事前准备"——事件发生时,没有任何一家机场能保你。
另一个值得记录的现象:牛逼机场在事件后没有恢复。其他机场 10-25 起陆续回到 95%+,它从 10-23 起就卡在 83% 上下,至今没爬回来——一次大事件就是一面照妖镜,运维能力弱的机场,阵亡的节点没人补。
真相五:晚高峰什么样?数据给了半个答案
两条曲线各讲了一个故事:
- 在线率:北京时间白天(8–14 时)约 89%,晚高峰(19–23 时)降到约 84%,差 5 个百分点。晚间确实更容易死节点
- 延迟:全天中位数稳定在 210–218ms,晚高峰几乎不变
"延迟不变"不要误读:我们的探针在美国,测的是国际段,不经过国内晚高峰最拥堵的那段路。你在国内感受到的"晚上变卡",很大程度发生在家到机房的国内段,这是本探针看不见的。另外 15 天的样本还被上面两次事件污染(事件恰好发生在下午到凌晨),所以晚高峰在线率低 5 个百分点这个数,只能当方向性参考。
这些数据怎么用在自己身上
- 买前看趋势,不看截图:状态页有每家 7 天/30 天的历史,连续走低的直接跳过;别信 TG 群里的单次测速截图。如果机场提供官方客户端,探针数据权重要再降一档——它测不到私有调度线路
- 快和稳分开选:主用机场选在线率 96%+ 的,低延迟直连可以当备用(比如打游戏),但别指望它稳
- 大事件时躺平:看到多家同时归零,别急着换机场、换配置——等 12 小时,大概率自己恢复,折腾反而引入新问题
- 事件后观察恢复速度:谁先爬回 95% 说明谁在干活;一周内爬不回来的,考虑止损
插曲:监控自己也会犯错
本文第一版引用的 NanoCloud 在线率是 73.7%。发布当天核对原始数据时发现:它的 10 个 IPv6 节点全部为 TUIC(UDP)协议,而探针的 UDP 探测函数写死了 IPv4 socket,导致这批节点 2,844 次探测全部被误判为离线——用正确的地址族复测,节点实际是活的。
修复(按地址族选择 socket)已上线,本文数据已按修正后口径重算。这个小事故本身就是监控方法论的一部分:监控系统本身也需要被监控。当你看到"某类节点集体 0% 在线"时,值得先问一句——是节点死了,还是尺子坏了?
局限性(再次诚实)
- 单一探针位置(美国),只代表国际方向
- TCP 通 ≠ 能过墙、≠ 速度快(方法论详见 #1)
- 15 天样本,含两次大事件,统计结论偏保守
- 只覆盖本站测评的 7 家,不构成对任何未监控机场的评价
- IPv6 + UDP 协议节点在 10-30 之前的历史数据存在误报(本文已按修正口径统计;状态页自 10-30 起为修复后数据)
- 探针测的是"订阅里的裸节点",不代表完整产品体验:不少机场有自己的官方客户端,走的是私有中转/专线调度,实际体验可能远好于裸节点数据;反过来,节点数据漂亮但客户端稀烂、售后跑路的机场也存在。探针数据是选机场的重要参考,但不是唯一标尺——请结合客户端体验、客服响应、运营时长综合判断
数据的价值不在当下的红黑榜,而在时间维度上的趋势。状态页会持续跑下去,三个月后我们再做一次复盘,看看今天的结论哪些还成立。