测速结果页上数字不少，先看哪几个决定了判断方向。

测速结果表：按运营商与地区列出最快、最慢与平均响应

测速结果表：按运营商与地区列出最快、最慢与平均响应

先认五个阶段

每一行节点数据背后，都是五段耗时：DNS 解析、TCP 连接、TLS 握手、TTFB、内容下载。对应关系很直接：

  • DNS 解析耗时：域名解析快不快
  • 连接耗时：网络能不能到
  • TLS 握手耗时：证书和加密协商开销
  • TTFB：服务端处理请求用了多久
  • 下载耗时：响应体多大、带宽够不够

哪一段占大头，问题就出在哪一层。

再看三个汇总值

结果页顶部会给三个数：平均响应时间、最快节点、响应最慢的节点。

它们的用法不是「看最慢的那个有多慢」，而是看差距有多大：

  • 平均 0.2 秒、最快 0.05 秒、最慢 0.9 秒，属于正常波动
  • 平均 0.2 秒、最慢 3 秒，说明有个别地区明显异常，值得单独查
  • 平均 1.5 秒，最快也 1.2 秒，那就是整体慢，问题在源站

单看任何一个都会误判，三个一起看才有意义。

状态码怎么读

  • 200：正常，重点看耗时
  • 301 / 302：跳转，本身不是错误，但跳转链太长会拖慢速度
  • 403：通常是 WAF、防盗链或权限策略拦截
  • 404：路径不对，检查是不是填错了 URL
  • 502 / 504：网关到后端超时或后端不可用，查反向代理和上游服务
  • 超时无响应：连不上，用 TCPing 确认端口通不通

一条经验：能返回状态码，说明链路是通的，问题在应用层；连状态码都没有，才是网络层问题。 这两类故障的处理路径完全不同。

一个具体的读法示例

假设某次结果：DNS 均 0.02 秒，连接均 0.03 秒，TLS 均 0.05 秒，TTFB 均 1.4 秒，下载均 0.1 秒。

结论很清楚：网络和证书都没问题，慢在服务端——TTFB 占了总耗时的九成。这时候去优化 CDN、换线路都是白费力气，该查的是数据库查询、后端接口和程序逻辑。

反过来，如果 TTFB 只有 0.05 秒而下载耗时 2 秒，那就是页面体积或带宽的事，和服务器性能无关。

别踩的两个坑

只看总耗时。 总耗时 1.5 秒这个数字，什么都说明不了。

只看一个地区。 上海 0.9 秒而全国平均 0.2 秒，说明是上海那条链路的问题，不是网站的问题。