节点延迟很低，速度却很慢 —— 为什么
延迟测的是握手要多少毫秒，带宽测的是持续拉数据有多快，两者可以完全无关。我们有一条线路延迟 236ms、丢包 0%、探针全绿，真实下载只有 0.47 Mbps。本文讲清楚为什么，以及怎么自己测。
客户端里那个「测速」按钮转一圈，显示 48ms，绿的。你点开 YouTube，转圈。
这不是矛盾，是你测的东西和你想知道的东西不是一回事。
延迟和带宽测的是两件事
客户端的「延迟」测的是：向一个地址发一个很小的请求，多久收到回应。整个过程传输的数据量通常不到 1 KB。
而你看视频、下文件时，要的是持续拉数据的能力。
这两件事之所以可以完全无关，是因为中间那些让你变慢的东西，几乎都不影响小包：
- 限速器按速率掐流量。一个 1 KB 的请求根本跑不到速率上限，所以它畅通无阻；而一个持续的下载从第一秒就撞在限速上。
- 共享队列在拥堵时丢大包、缓冲大包。小包优先穿过去了，大包堵在后面。
- 丢包对小包只是偶尔重发一次，对 TCP 下载是毁灭性的 —— 拥塞控制会一路降速。
所以「延迟绿」只能告诉你这条路通，说明不了这条路有多宽。
一组我们自己的实测
这是我们排查一条香港线路时的真实数据：
- 探针报告 27/28 全绿
- 延迟 236ms，丢包 0%，抖动很小
- 同一时刻真实下载：0.47 Mbps
同一轮里另一条美国线路，延迟 235ms —— 几乎一样 —— 真实下载 46 Mbps。
延迟几乎相同，带宽差了近 100 倍。 如果只看延迟，这两条线是一样的。
后来查明是入口被按单条连接限速：单条 0.5 Mbps，开四条合计 1.9，线性叠加。这也解释了为什么有人觉得「多线程下载还行，但看视频就是卡」—— 视频播放器通常只开一两条连接。
怎么自己测
不要用 fast.com 或 speedtest。 它们会同时开几十条连接，刚好把「单连接被限速」这个问题掩盖掉 —— 测出来是所有连接的总和，看着还行，而你实际用的时候只有一两条连接。
正确的做法是单连接拉一个大文件，看平均速度。随便找一个大文件直链，或者用命令行：
输出的是字节每秒，乘 8 除以一百万就是 Mbps。
测之前先验测速目标本身。 我们吃过这个亏：一直用的某个 CDN 测试文件某天开始返回 403，于是所有节点都显示 0 Mbps，差点据此换掉一台好机器。先确认目标返回 200，再去比较节点。
还有一层：在哪测的
同一批节点，我们在机房探针上测出 0.5 Mbps，在家庭宽带上测出 35~41 Mbps。差了 80 倍，而且方向相反。
机房的路由和家宽的路由是两条完全不同的路。所以任何「我们测过很快」的宣传，都该先问一句：在哪测的？
反过来也成立 —— 如果你在自己家测出来很慢，那就是慢，不用怀疑自己。你家的网才是唯一算数的那个。
一张自查清单
- 别看延迟，拉一个大文件，单连接
- 先确认测速目标本身返回 200
- 同一时刻测两条不同线路做对照 —— 只有一个数字说明不了问题
- 如果单连接慢、多连接快，基本可以确定是按连接限速，换线
- 如果两条线都慢，先排除你本地的问题（换个时间、换个网络再测一次）
我们怎么做这件事
我们对每个节点做的是真实请求测试，不是探测端口通不通，结果逐节点公开在状态页上，买之前就能看。
延迟数字我们也显示，但从不拿它当卖点 —— 上面那条 236ms 全绿的线路就是教训。
相关：ChatGPT / Claude 在国内频繁弹验证怎么办 · 怎么判断一个机场是不是真的「三网优化」
状态页：status.tianjiyun.org
数据来自我们自己节点的实测，写于 2026-10-03。
← 全部文章