拨测的「平均响应」为什么偏高？少数超慢节点拉高了平均值

用宝塔拨测（t.bt.cn）跑完一次测速，结果页上最显眼的数字往往是「平均响应」。很多人会拿它和自己打开网站的感受对：结果写着平均 95 毫秒，自己却觉得网站挺快——这中间差在哪？

答案藏在「平均」这两个字里。平均值会被少数几个极慢的节点拉高，而绝大多数节点的真实耗时其实低得多。下面用 2026-10-06 上午对 www.baidu.com 的一次 TCP 拨测（357 个节点成功、覆盖 59 个省份/地区）讲清楚这个「长尾」现象。

平均 95.7ms，但中位数只有 31.1ms

同一次 TCP 拨测，用两种方式描述「典型耗时」，结果差出近 3 倍：

指标	本次实测值
目标	www.baidu.com:443（TCP 测速）
成功节点	357 / 358 选中（成功率 99.7%）
官方平均响应	95.7 毫秒
连接耗时中位数	31.1 毫秒
连接耗时 p95	302 毫秒
最快节点	福建泉州移动 0.6 毫秒
最慢节点	广东汕头移动 7524.8 毫秒

同一个目标、同一批节点，平均响应是 95.7 毫秒，但把 357 个成功节点的耗时从小到大排个序、取正中间那一个（中位数），只有 31.1 毫秒。也就是说，超过一半的节点连接耗时都在 31 毫秒上下，网站的「典型」速度其实是 31 毫秒，而不是 95 毫秒。

是谁把平均拉高了近 3 倍

差距来自最慢的那几个节点。这次拨测里，最慢的 5 个节点是：

节点	连接耗时
广东-汕头-移动	7524.8 毫秒
重庆-电信	4042.4 毫秒
山东-临沂-电信	1034.5 毫秒
河北-保定-联通	1028.2 毫秒
新西兰	714.6 毫秒

这几个节点数量只占 357 个成功节点的一小部分，但它们的耗时时普通节点的几十倍甚至上百倍。算术平均把每个节点的耗时都「一视同仁」地加进去再除，于是这少数几个超慢节点就把整体平均值明显抬了上去——这就是统计里常说的「长尾拖累平均」。

反过来看最快的一批节点，才是大多数节点的真实水平：福建泉州移动 0.6 毫秒、北京电信 2.7 毫秒、香港腾讯云 3 毫秒、新加坡 3 毫秒。绝大多数节点都集中在这个「几十毫秒以内」的区间。

PING 拨测也一样：平均 39.9ms、中位数 22ms

同样的现象在 PING 拨测里也能看到。对 www.baidu.com 的 PING 拨测（353 个节点成功）：

指标	本次实测值
往返时延（RTT）中位数	22 毫秒
平均往返时延	39.9 毫秒
最快 / 最慢节点	0.5 / 441.1 毫秒

中位数 22 毫秒、平均 39.9 毫秒，又差近一倍。原因还是同一个：少数节点丢包或绕路导致往返时延飙到几百毫秒，把平均抬了上去。

怎么正确读「平均响应」

既然平均值会被长尾干扰，读结果时建议这样用：

• 判断「多数用户体验」：看中位数（或直接看「最快」那一批节点），它更接近大多数用户打开网站的真实速度。
• 判断「最坏情况」：看最慢节点和 p95，它回答「运气最差的那批用户会慢到多少」。
• 看「平均」的用法：适合做不同时间、不同目标之间的大致趋势对比，不适合单独拿来下「网站变慢」的结论。

一句话总结：平均响应被少数超慢节点拉高是正常现象，不是你的网站真的那么慢。 想看清真实水平，优先看中位数和最慢节点，而不是盯着平均值。

（本文数据来自 2026-10-06 上午对 www.baidu.com 的真实拨测，只代表采集时刻的情况；节点池和线路是动态的，跨天复测数据不同属正常。）