mylogs.cn

测速跑满600M还是卡？这几个指标才是元凶

2026 年 8 月 1 日

发布于

宽带测速结果好看，网页却半天不出图、视频通话时不时糊成一片、游戏莫名其妙地“瞬移”一下——这种“数字很快、体感很慢”的落差几乎人人遇到过。原因在于，测速页面上那两个巨大的 Mbps 数字只回答了一个问题：管道有多粗；而决定一条连接跟不跟手的，是延迟、抖动、丢包，以及管道被填满之后会发生什么。

MakeUseOf 撰稿人 Gavin Phillips 为此做了一组对照测试：先跑 Ookla 测速，同时让 WinMTR 在后台记录，空闲状态跑五分钟，再在测速运行时跑一次，最后补上 Waveform 的缓冲膨胀（bufferbloat）测试。他那条线路的 Ookla 成绩是下行 617.5Mbps、上行 577.7Mbps，足够快，但这远不是全部真相。

第一步：先把测速页上最小的那行字看完

延迟是往返一次所需的时间，页面加载是否“秒开”、通话是否自然、游戏是否跟手，都由它决定，而吞吐量几乎管不着——1Gbps 的线路照样可能延迟高得难受。多数测速工具其实会给出延迟值，只是它被排版成结果页上最小的一行字。这个数字越低越好，超过 100ms 就会明显影响在线服务，尤其是网络游戏。

在上述测试中，Waveform 测得空闲延迟 34ms，WinMTR 显示每一跳约 9 到 11ms，属于不会拖累游戏的水平。

第二步：换一个会报抖动和丢包的测速工具

抖动指的是每次 ping 之间的波动幅度，而不是某一次 ping 的数值。平均延迟漂亮却抖动剧烈，正是视频通话忽然卡顿、对局中莫名掉帧的元凶。测试中 Waveform 记录的抖动只有 4.1ms，看着平平无奇；但最初那次 Ookla 上行延迟 10ms、抖动 11ms，峰值却冲到 298ms——平均值把问题抹平了，体感却是不稳定。

丢包则是干脆没送到、需要重传的数据，直接对应通话冻结和跳帧。麻烦的是，Ookla、谷歌自带测速、Netflix 的 Fast 等主流工具通常都不显示丢包。想看这两项，可以改用 Cloudflare 的测速页（speed.cloudflare.com），它会同时给出抖动、丢包等信息。

第三步：跑一次满载测试，看延迟涨多少

测速工具默认测的是单台设备的独享速度。一台设备在线时它相当准，可到了晚上八点、全家人同时看剧打游戏开语音，画面就完全不同了——这类网络拥塞，普通测速根本不衡量。

缓冲膨胀测试正是用来补这一课的：它在把带宽压满的同时观察延迟涨幅。测试中，负载一上来，Waveform 记录到下行延迟增加 29ms、上行增加 5ms，仍能拿到 A 级；WinMTR 的满载追踪也印证了这一点，每一跳的最差值都随之上升（其中一跳从 60ms 涨到 72ms），但各跳平均值几乎没变。

第四步：用 WinMTR 定位是哪一段出问题

WinMTR 是一款免费开源工具，相当于把 ping 和 traceroute 合成一个界面，能实时看到数据经过的每一跳，从而判断速度是在哪一段被拖慢的。用法是先在空闲状态跑上五分钟做基线，再一边跑测速一边记录，两份数据对照着看。

注意：某一跳 100% 丢包，未必是线路坏了

测试中每一次 WinMTR 追踪都会出现一跳显示 100% 丢包，单看那一行足以让人以为线路已经瘫痪，可测速全程顺利完成。原因在于 ping 和 traceroute 走的是 ICMP 协议，而许多路由器会限速甚至直接忽略发给自己的 ICMP 请求——因为回应这些请求会挤占它转发流量的本职资源——但真正的数据包仍会照常走另一条内部路径转发。只要追踪能跑到最后一跳且末跳有正常数据，中间这种“黑洞跳”就不必紧张。