一句话答案：TCP 测速跑到三次握手就收工，网站测速还得把 DNS 解析、TLS 握手、发送请求、等服务端吐出第一个字节全部走完。同一时段对 www.bt.cn 各跑一次，TCP 连接耗时中位数 50.3 毫秒，网站测速总耗时中位数 356.3 毫秒，多出来的部分几乎全压在「首字节」。只想验证端口和线路，用 TCP 测速；想知道用户真实打开体验，用 网站测速。
群里经常有人问：443 端口用 TCP 测速看是通的，耗时也不高，换网站测速测同一个域名，数字直接翻了几倍，是不是哪里配错了？
大概率没配错，是两次测的东西根本不在一个层面。下面这组对照来自 2026-10-06 下午对 www.bt.cn 的两次独立拨测，各自调度到 356/357 个节点成功、覆盖 59 个省份/地区，正好能把差距摊开看。
先看对照：同一域名、同一批节点，两套数字
两次拨测的目标都是 www.bt.cn，一次只测 443 端口的连接，一次跑完整的 HTTPS 请求，结果如下：
观察项
| TCP 测速（www.bt.cn:443）
| 网站测速（https://www.bt.cn）
| 成功节点
| 356 / 357（成功率 99.7%）
| 356 / 357（成功率 99.7%）
| 总耗时中位数
| 50.3 毫秒
| 356.3 毫秒
| p95
| 400.6 毫秒
| 1385.7 毫秒
| 官方平均
| 124.9 毫秒
| 467.8 毫秒
| 最快 / 最慢节点
| 0.7 / 4996.3 毫秒
| 59.1 / 6231.4 毫秒
|
同域名、同一批探针，连接耗时的中位数只要 50.3 毫秒，完整请求却要 356.3 毫秒，差出约 7 倍。这不是网络突然变差了，而是「测的终点」不同：TCP 测速握手成功就结束，网站测速要继续把请求链路走完。
多出来的 300 毫秒，压在「首字节」这一段
网站测速会把一次请求拆成若干阶段，各阶段中位数如下：
阶段
| 中位数耗时
| DNS 解析
| 17.2 毫秒
| TCP 连接
| 40.6 毫秒
| TLS 握手
| 58.1 毫秒
| 首字节
| 356.2 毫秒
| 传输
| 0.1 毫秒
|
三段握手（DNS 17.2 + TCP 40.6 + TLS 58.1）合计约 116 毫秒，只占总耗时的一小截；真正的大头是首字节 356.2 毫秒，也就是服务器拿到请求之后，处理完并把第一个字节送回来的那段时间。
所以结论挺直白：端口通、握手快，跟网站快不快是两码事。网站测速慢，问题多半落在服务器这一侧，而不是端口或线路上。
唯一失败的节点，卡在解析而不是握手
两次拨测的成功率一模一样，都是 356/357，失败的也恰好是同一个节点「湖北-孝感-联通」。有意思的是它给出的原因：
- 网站测速记的是 HTTP_DNS_TIMEOUT，错误信息为 lookup www.bt.cn: i/o timeout；
- TCP 测速记的是 TCP_TARGET_INVALID，错误信息同样是 lookup www.bt.cn … i/o timeout。
换句话说，这个节点在域名解析这一步就超时了，三次握手压根没轮到。这也提醒一句：目标填域名时，探针自己也要先做解析，探针侧 DNS 超时同样会让 TCP 测速失败，跟你服务器端口开没开没有关系。
两种测法怎么分工
排查时按「想验证什么」挑工具就行：
- 只想确认端口通不通、到服务器的网络延迟大概多少 → 用「TCP 测速」。它只关心三次握手，结果干净，不受业务逻辑干扰。
- 想确认网站能不能正常打开、整条链路是否通畅 → 用「网站测速」。DNS、TLS、HTTP 请求全覆盖，能暴露 TCP 层看不见的问题。
- 想持续盯住这两项 → 在控制台建定时拨测任务并挂上告警，具体用法与计费见官方文档《使用宝塔拨测》。
一句话收个尾：TCP 通了，说明端口和网络这一层是没问题的；网站测速慢或者失败，多半是后面的 TLS 协商、服务端响应这些环节出了状况。别把「端口通」直接当成「网站通」。
本组数据采集于 2026-10-06 下午，只代表当时的情况。节点池和线路是动态调整的，隔天复测数字对不上很正常。
常见问题443 端口能连上，是不是就说明网站一定能打开？
不能这么推。TCP 测速只验到握手这一步，证明探针能连上服务器那个指定端口；网站测速还要接着完成解析、TLS 协商、发送 HTTP 请求、等首字节返回，任何一环出问题都会失败。这次两个拨测虽然都是 356/357，但失败的恰好是同一个「湖北孝感联通」节点，而且都是解析超时——它连握手都没开始。
为什么 TCP 测速几十毫秒，网站测速要好几百毫秒？
因为终点不一样。前者握手成功即止，本次连接中位数 50.3 毫秒；后者要跑完整条 HTTPS 请求，总耗时中位数 356.3 毫秒，相差约 7 倍。多出来的时间花在解析、TLS 协商、发请求和等服务端响应上。
网站测速慢，到底是网络的锅还是服务器的锅？
把 356.3 毫秒拆开看就清楚了：DNS 17.2、TCP 40.6、TLS 58.1、首字节 356.2、传输 0.1 毫秒。三段握手加起来才 116 毫秒左右，占小头；首字节 356.2 毫秒才是大头，而首字节反映的是服务端处理请求的速度。所以慢在服务器响应，不在网络。
只想确认端口和线路，该用哪个测速？
用 TCP 测速。它只关心三次握手，最能干净地反映「这个端口从外部能不能连上、连上要多久」。要判断网站整体可用性、状态码、首字节，再换网站测速。
两种测法的失败原因一致吗？
不完全一样，但都要先解析域名。这次唯一失败的那个节点，TCP 测速报 TCP_TARGET_INVALID、网站测速报 HTTP_DNS_TIMEOUT，可具体错误信息都是 lookup www.bt.cn i/o timeout，卡点都在解析。也就是说，哪怕只做 TCP 测速，探针自己的 DNS 超时也会让任务失败，跟端口状态无关。
能不能直接用网站测速的数字减掉 TCP 测速的数字，得出「服务端耗时」？
不建议这么算。这是两次独立运行，节点返回本身有波动。要拆分就看同一次网站测速内部的分段数据（它自带 TCP 连接段），或者拿两轮各自的中位数做粗略比较。本文里网站测速内部的 TCP 段是 40.6 毫秒，单独跑 TCP 测速是 50.3 毫秒，同一数量级，但确实是两次不同的运行。
有问题欢迎回帖。
|
|
运维要高效，装宝塔
