机场延迟高怎么解决:延迟、抖动、丢包要分开测

客户端节点列表右边那个数字,承担了远超它能力范围的期待。人们盯着它挑节点、用它判断线路好坏、拿它解释卡顿——可它只是一次探测的往返耗时,既不告诉你这个数字稳不稳,也不告诉你有多少包根本没回来。

时延质量至少要三个指标才能描述完整。延迟是平均往返时间,决定你按下一个键到看见反应之间的空档;抖动是这些往返时间之间的波动幅度,决定体验是匀速还是忽快忽慢;丢包是没能回来的比例,决定连接会不会中途断掉。三者独立变化,一个好不代表另外两个也好。

分不开这三样,排查就会变成盲目换节点:延迟从 90 降到 70,以为改善了,结果游戏照样飘,因为真正的问题是每分钟几次的尖峰。下面按指标逐个说清楚它的含义、正常区间和测法。

三个指标,分别对应什么体验#

第四行放进来是为了对照。带宽属于吞吐维度,和前三者的成因、测法、解决办法都不一样,如果你的困扰是下载慢而不是操作有延迟,应该转到慢的排查流程。

一个反直觉但重要的事实:抖动往往比延迟本身更能解释「体验差」。人对稳定的 120ms 适应得很快,对在 40ms 和 300ms 之间乱跳的链路则完全无法适应。

多少算正常:延迟必须按地区分档看#

拿同一把尺子量所有节点是最常见的错误。延迟的下限由物理距离决定——光在光纤里的传播速度是有限的,跨太平洋往返本身就要一百多毫秒,再优秀的线路也压不下去。

下面是按物理距离与常见路由路径推算的参考区间,属于参考值而非实测结论,实际数值受你的接入运营商、所在城市和线路类型影响,差异可能很大:

抖动和丢包则不分地区,标准是统一的:

判断一条线路好不好,先问它是哪个地区的。一个 190ms 的美西节点很正常,一个 190ms 的香港节点说明路径出了问题——同样的数字,结论相反。

客户端里的那个延迟测试,测的到底是什么#

多数客户端的延迟按钮做的是这件事:通过该节点向一个内置的探测地址发一次请求,记录从发出到收到响应的耗时。这个数字包含三段——你到入口机、入口机到落地机、落地机到探测目标——但界面上只显示一个合计值。

它有几个必须知道的局限:

• 它是一次采样,不是统计。 单次结果的偶发波动很大,连点三次可能得到三个差很远的数字。
• 它包含目标站点的响应时间。 探测地址如果本身在抖,数字也会跟着抖,这和你的线路无关。
• 探测地址可能被屏蔽。 某些网络会屏蔽特定探测地址,于是全部显示超时,而实际转发完全正常。
• 它不反映丢包。 只要有一次回来了就显示数字,回来了几次、丢了几次,界面不区分。

所以它适合用来做粗筛——在几十个节点里快速排掉那些明显不可用的——但不适合用来做判断。真要判断,得自己测。

抖动和丢包怎么测#

核心思路是把一次采样换成连续采样。用系统自带的 ping 就够了,关键是次数要够多,让统计量有意义。

# 结构示例,目标地址换成你实际使用的节点域名
# macOS / Linux:连续 100 次,间隔 0.2 秒
ping -c 100 -i 0.2 node-hk-01.example.invalid

# Windows:连续 100 次
ping -n 100 node-hk-01.example.invalid

跑完看汇总行:丢包率直接给出,抖动看最大值与最小值的差,或者标准差那一项。要注意的是,直接 ping 一个公网地址走的可能不是代理链路,具体取决于你的客户端是否接管了 ICMP 流量。虚拟网卡模式通常会接管,系统代理模式通常不会。

要看清是哪一跳出问题,用路径追踪工具更直接:

# 结构示例,地址请换成你实际使用的节点域名
mtr --report --report-cycles 100 node-hk-01.example.invalid

输出里每一跳都有自己的丢包率和延迟。读的时候记住一条规则:中间某一跳丢包但后续跳数正常,那是该路由器对 ICMP 的限速策略,不是真丢包;只有从某一跳开始丢包率一路延续到最后一跳,才是真正的问题点。

第三行值得单独留意。第一跳就丢包意味着问题在你的局域网内,换多少节点都没用,先去看无线信号和路由器;如果换网络才复现,那属于换网络就失效的场景。

线路类型对时延的影响权重#

同一个「香港节点」,不同线路结构下的时延表现可以差出一倍,而节点名上往往看不出来。

差别的根源在于走不走公网国际出口。晚高峰的抖动与丢包几乎都发生在那一段,绕开它,三个指标会同时变好。这也是为什么对时延敏感的用途值得为专线多付钱——它买的不是更低的平均延迟,而是更小的波动。结构上的差异在中转与直连的对比里讲得更细,专线两个缩写的真实定义则在IEPL 与 IPLC 的说明。

延迟很低,下载速度却上不去#

这个组合每天都有人问,它其实不矛盾。延迟低只说明数据包往返快,不说明这条管道有多粗。常见的四种成因:

1. 套餐带宽被限速。 阈值卡在某个数值上,延迟不受影响,吞吐被压死。
2. 落地机的单用户限速。 同一节点上人多时,每人分到的上限很低,而 ICMP 探测包太小,感受不到拥挤。
3. 单连接的窗口限制。 高延迟链路上单条 TCP 连接跑不满带宽,这是协议机制,不是故障,多线程测一次就能区分。
4. 本地瓶颈。 无线信号弱、设备 CPU 跑满、后台在同步文件,和线路无关。

判据很简单:延迟正常而多线程下载也上不去,才是线路容量问题;多线程能跑满,那就是单连接的正常表现,不必处理。

协议会不会改变时延#

会,但幅度远小于多数人的预期,而且作用点不在延迟上。

• 平均延迟: 几乎不受协议影响。传播时延由物理路径决定,加解密带来的处理耗时通常在个位数毫秒。
• 抖动: 有一定影响。拥塞控制策略更激进的协议在链路波动时恢复更快,体感上更稳。
• 丢包造成的卡顿: 影响最大。基于 UDP 的协议在高丢包链路上不必等待 TCP 的重传与拥塞退避,表现明显更好。

所以结论是:低丢包链路上换协议基本不会有感知,高丢包链路上换协议可能立竿见影。UDP 系协议之间的取舍——高丢包和频繁切换网络分别该选谁——在Hysteria2 与 TUIC 的对比里。

换协议之前先确认本地网络没有对 UDP 做限速。校园网和公司网这么做的相当常见,在这类网络里换到 UDP 系协议只会更差。

换地区还是换服务#

三个指标测完,决策条件就很清楚了:

前四行都能靠换节点解决,成本极低,应该先穷尽。只有最后一行才涉及换服务,而且下结论前要连续观察几天,排除掉临时的线路调整。挑节点时该看哪些标记,可以顺带看看节点该怎么选;如果确实需要对时延要求高的专线线路,专线维度的排行榜是个起点。

小结#

延迟、抖动、丢包是三个独立指标,只盯客户端里那一个数字必然误判。延迟必须按地区分档比较,190ms 在美西正常、在香港说明路径出了问题。抖动和丢包要靠连续一百次的采样来看,单次探测提供不了统计量;路径追踪里中间跳的丢包通常是 ICMP 限速,只有一路延续到终点的才算数。协议对平均延迟几乎没有影响,只在高丢包链路上改善明显。真正决定这三项的是线路是否绕开公网国际出口,所以换地区、换线路类型的性价比,通常远高于换一家机场。