稳定机场怎么判断?五项自己就能复测的指标
一句话结论
稳定和速度是两回事。判断稳定性至少要看五项:一小时内断流次数、持续 Ping 的丢包率、延迟抖动幅度、长连接能维持多久不掉、以及晚高峰相对白天的衰减比例。测速软件跑出的峰值带宽几乎不反映这五项,需要在工作日晚 20:00–23:00 连续记录多天才有参考价值。
大部分人判断一家机场稳不稳,靠的是「昨天晚上看视频没卡」这种记忆。这类印象最大的问题不是不准,而是无法复核——换一个人、换一个晚上,结论可能完全相反,而你没有任何材料去分辨到底是机场变了还是自己那天运气好。
要让判断可复核,就得先把「稳定」这个词拆成能被记录下来的量。拆下来一共五项:一小时内主动断流的次数、持续 Ping 的丢包率、延迟抖动的幅度、单条长连接能维持多久不掉、以及晚高峰相对白天的性能衰减比例。这五项都不需要专业工具,一台电脑加系统自带的命令就够,代价只是要花几个晚上。
需要先泼一盆冷水:本站尚未完成 16 家的统一实测,下文出现的所有区间都是按常见网络环境给出的参考范围,不同城市、不同运营商、不同时段测出来的数字会有明显差异。这套方法的价值在于你用同一套口径去量两家机场,而不在于把某个数字当成及格线。
速度快就等于稳定吗?两者到底差在哪里
速度衡量的是「最好的时候能跑多快」,稳定衡量的是「最差的时候会差到什么程度」。测速软件天然测的是前者:它同时建立多条并发连接、只持续十几秒、最后取峰值。这个场景恰恰是最容易被针对性优化的。
| 维度 | 速度指标 | 稳定性指标 |
|---|---|---|
| 测量时长 | 10–30 秒 | 1 小时起,跨多天 |
| 关注的统计量 | 峰值 / 平均带宽 | 波动幅度、失败次数 |
| 典型工具 | 测速网站、客户端测速 | ping、长连接会话观察 |
| 受落地负载影响 | 中等 | 极大 |
| 对晚高峰敏感 | 部分体现 | 完全体现 |
一条晚高峰跑 80Mbps 但每十分钟断一次的线路,和一条常年 25Mbps 从不断的线路,测速截图上前者压倒性获胜,实际用起来后者远好于前者。这也是为什么在读任何带测速截图的推荐时,都值得先按核验推荐可信度的六个信号确认对方有没有公开测试条件。
五项指标分别对应什么使用体验
指标本身没有意义,能对应到具体的难受感受才有。
| 指标 | 怎么量 | 参考区间(经验值) | 不达标时的直接体验 |
|---|---|---|---|
| 断流次数 | 1 小时内连接完全中断的次数 | 0 次;1 次可容忍 | 网页突然打不开,需手动切节点 |
| 丢包率 | 持续 ping 的 packet loss | 低于 1% | 视频会议卡顿、游戏瞬移 |
| 延迟抖动 | 最大延迟与中位延迟之差 | 小于中位值的 50% | 语音断续、页面加载忽快忽慢 |
| 长连接存活 | 单条连接不中断的时长 | 2 小时以上 | AI 工具输出中断、SSH 掉线 |
| 晚高峰衰减 | 晚间带宽 ÷ 白天带宽 | 高于 60% | 白天正常,晚上几乎不能用 |
五项里最容易被忽略的是长连接存活。它和其他四项不同:即使丢包率、延迟都很漂亮,一条会在四十分钟后被中间设备回收的连接,照样会让所有流式任务反复重来。
怎么用持续 Ping 记录丢包和抖动
Ping 是这套方法里最便宜的一步。要点是持续时间要长,且必须在代理生效的情况下测目标站点,而不是测节点服务器本身。
- 先在客户端里固定一个节点,不要开自动切换,否则记录到的是多个节点的混合结果,无法归因。
- 打开终端执行持续 ping,让它跑满至少十分钟。时间太短,偶发丢包会被平均掉。
- 记录结束时输出的统计行,重点看 packet loss 和 min/avg/max 三个值。
- 同一时间段对另一家机场重复一次,两组数字必须来自同一晚,跨天比较没有意义。
# 结构示例:地址一律用 example.invalid,实际请换成你常访问的目标站点
# macOS / Linux:发送 600 个包,约 10 分钟
ping -c 600 example.invalid
# Windows PowerShell:-n 指定包数
ping -n 600 example.invalid
统计行大致是这个形态:
600 packets transmitted, 594 received, 1.0% packet loss
round-trip min/avg/max/stddev = 62.1/78.4/389.7/31.2 ms
这一行里 1.0% packet loss 是丢包率;max 减去 avg 得到 311ms,远大于 avg 本身,说明抖动很大——即使平均延迟只有 78ms,实际体验也会明显发飘。平均延迟漂亮但 max 值离谱,是最常见的一种「参数好看、用着难受」。
提示:ping 走的是 ICMP,部分节点和目标站点会限制或降权处理 ICMP,导致丢包率虚高。如果 ping 显示丢包严重但网页、视频都正常,先换一个目标站点复测,不要直接下结论。
长连接存活测试怎么做,为什么它对 AI 工具特别关键
AI 对话、代码补全、在线协作文档这类任务,靠的都是一条长时间不关闭的连接持续推送数据。链路上任何一个环节把闲置连接回收掉,表现出来就是「输出到一半停住」或者「刷新后重来」。
最省事的测法是找一个会持续输出的任务,让它跑着,你去做别的事:
- 选定节点后,打开一个需要长时间保持连接的会话(长时间的流式对话、远程终端、在线文档协作都可以)。
- 记下开始时刻,中途不要切换节点、不要让设备休眠,笔记本要插电并关闭省电策略。
- 中断发生时立刻记下时刻,算出存活分钟数;若两小时内没断,记为「>120min」即可。
- 同一节点重复两次,取较短的那次作为记录值——稳定性看的是下限。
如果多次测试都稳定卡在某个接近的时长(比如都在 25 到 35 分钟之间断开),大概率是链路上存在固定的空闲超时策略,而不是随机故障。这种情况换节点往往有效,换协议有时也有效,可以顺带看看两种伪装思路的协议差异。
晚高峰衰减比例怎么算,衰减多少算不能接受
跨境线路的拥堵有很强的时间规律,工作日 20:00 到 23:00 是压力最大的窗口。衰减比例的算法很简单:
晚高峰衰减比例 = 晚间实测带宽 ÷ 同日白天实测带宽 × 100%
要注意两个前提:两次测试必须用同一个节点、同一个测试目标,且白天那次最好选在 14:00 前后,不要用清晨的数据去抬高分母。
| 衰减比例 | 含义 | 建议 |
|---|---|---|
| 80% 以上 | 线路余量充足 | 可作主力 |
| 60%–80% | 有拥堵但可用 | 可接受,注意观察 |
| 40%–60% | 晚间体验明显下降 | 只适合轻度用途 |
| 40% 以下 | 晚间基本不可用 | 不建议作主力线路 |
衰减严重通常指向两件事之一:线路走的是公网国际出口且没有足够余量,或者该节点被超售得太厉害。前者属于线路结构问题,可以对照中转与直连的路段差异去理解;后者属于成本结构问题,低价机场把成本省在哪里那篇讲得更细。
节点数量多、延迟低,是否就代表稳定
不代表,而且这两个数字恰恰是最容易做漂亮的。
节点数量是套餐页上的营销数字。同一台落地服务器换三个入口、开三种协议,就可以变成三个节点名。一份 200 节点的列表里,真正独立可用的落地可能只有二三十个。判断的方式是看落地地区的分布广度,而不是条目总数。
客户端显示的延迟则是一次瞬时握手的耗时,测的是「建立连接快不快」,和「传输过程稳不稳」是两件事。一个刚上线、还没什么人用的节点延迟一定很低,用的人多起来之后延迟未必变化很大,但抖动和丢包会先恶化。所以延迟只适合用来做第一轮粗筛,把明显绕远的节点排掉,不能用来排序。
同一份记录表怎么用来横向对比两家机场
单看一家机场的数据几乎没法判断好坏,因为你不知道自己所在网络环境的基准线在哪。所以这套方法真正的用法是并行:同一台设备、同一个晚上、同一个测试目标,两家轮流测,再把结果填进同一张表。
| 记录项 | 机场 A | 机场 B |
|---|---|---|
| 测试日期 / 时段 | 08-12 21:00 | 08-12 21:40 |
| 节点(地区 / 类型) | 香港 中转 | 香港 中转 |
| 10 分钟丢包率 | 0.5% | 3.2% |
| avg / max 延迟 | 78 / 390 ms | 65 / 210 ms |
| 1 小时断流次数 | 0 | 2 |
| 长连接存活 | >120min | 34min |
| 晚间 / 白天带宽 | 42 / 55 Mbps | 70 / 130 Mbps |
| 衰减比例 | 76% | 54% |
这张表里 B 的延迟更低、峰值更高,如果只看测速截图它会赢;但断流两次、长连接 34 分钟就掉、衰减到 54%,说明它的落地负载已经吃紧。表格的价值就在这里:把互相矛盾的观感摊平成同一口径的几行数字。
口径提示:两家机场的节点地区、线路类型必须尽量对齐,用香港中转对比日本直连得出的结论没有意义。如果两家的可选节点差异太大,就在表里注明,不要硬凑。
测出问题后,怎么区分是机场问题还是本地网络问题
数据难看不等于机场的锅。排除本地因素只需要三个动作,按顺序做,先便宜后麻烦:
- 换目标不换节点:ping 另一个目标站点。两个目标都差,问题更可能在链路;只有一个差,是目标站点或它的 CDN 的事。
- 换节点不换机场:切到同机场的另一个地区节点。全部节点都差,指向机场整体或你的本地出口;只有个别节点差,就是那台落地的负载或线路问题。
- 换网络不换机场:把设备切到手机热点再测一次。热点下明显变好,说明是你原本那条宽带的国际出口在晚高峰被压住了,这种情况换机场帮助有限。
三步做完还是差,才值得下判断。顺带一提,第三步经常能解释「同一家机场别人说好用、我用着不行」这类分歧——两个人的本地出口根本不是一回事。真的确认是连接层面的故障,可以再对照连接失败的排查流程逐项过一遍。
小结
稳定不是一个形容词,是五个可以被记录的数字:断流次数、丢包率、抖动幅度、长连接存活时长、晚高峰衰减比例。这五项都不需要付费工具,代价只是要连续测几个晚上。真正让判断成立的不是数字本身,而是同一晚、同一设备、同一目标的并行对比,以及先排除本地网络再下结论的顺序。测完之后你手上会有一张能给别人看、也能过几个月自己复核的表,这比任何一句「我用着挺稳的」都有用。带着这套方法去看按稳定性维度筛过的候选名单,效率会高很多。
常见问题
测几天才够得出稳定性结论?
至少覆盖两个工作日晚高峰加一个周末晚高峰,也就是三次记录起步。只测一次的结果和抽签差不多,因为跨境线路的拥堵有明显的日内和周内周期,单次采样无法区分“这家不行”和“今晚不行”。
测速软件跑出的数字为什么参考价值有限?
测速工具默认建立多条并发连接、只跑十几秒、取的是峰值带宽,这恰好是最容易被优化的场景。断流、抖动、长连接掉线这几件真正影响体验的事,都发生在十几秒之外。
丢包率多少算不能接受?
看用途。纯网页浏览时百分之二到三察觉不到,视频会议和游戏在百分之一以上就开始出现卡顿和回声,AI 工具的流式输出在百分之三左右会明显出现中断重连。给不出一个通用阈值,只能对着自己的主要用途定。
节点显示延迟只有 60ms,为什么用起来还是卡?
客户端显示的延迟通常是一次 TCP 握手或 HTTP 请求的耗时,是瞬时值。它不反映持续传输时的抖动,也不反映落地服务器的并发负载,低延迟和高稳定完全可以不同时出现。