先别急着登服务器

页面偶尔转圈、过一会儿又正常，我以前的第一反应是登机器看负载。CPU、内存、连接数全都在正常范围，人反而更慌。后来才慢慢摸出顺序：测速结果不是给你一个「快慢」的结论，而是给你几组能互相印证的信号，先分清链路还是源站，再决定要不要登机器。

状态码先把通不通说清楚

用宝塔拨测的网站测速跑一次，结果里最先该看的是 HTTP 状态码。200 只说明这次请求被正常回应；5xx 代表请求已经到了源站或中间层，但后端处理出了问题；4xx 多半是配置、权限或者拦截规则在起作用；超时和连接失败，则是根本没走到应用层。

这一步的价值在于分叉。状态码异常，先往服务端和配置上查；状态码全绿但仍然慢，才轮到速度本身。顺序反了，就很容易在健康的机器上翻半天日志。

五段耗时告诉你慢在哪一层

响应时间拆开看是五段：DNS 解析、TCP 连接、TLS 握手、首字节时间、内容下载。它们各自对应不同的责任方。

DNS 段长，查解析服务和记录配置；TCP 连接段长，多半是线路质量、丢包或者防火墙；TLS 握手段长，看证书链、协议版本和加密套件；TTFB 长，说明请求已经进了后端，程序或数据库在拖；下载段慢，则是带宽不足、文件太大、图片没压。有用的是「哪一段独占大头」，不是总时长。

节点分布比平均值有用

平均、最快、最慢三个数摆在一起，差距大就说明不稳定。这时候要往下看按地区和运营商分组的结果：所有节点一起慢，源站嫌疑最大；只有某个运营商或某个地区慢，问题更可能在链路互联、CDN 调度或者地方解析上。

我吃过一次亏，就是盯着平均值判断「整体正常」，忽略了最慢节点集中在某一类线路。可用户投诉的从来不是平均值，是他们自己走的那一条路。

复测是为了排除偶发

单次结果只能算一个样本。同一时间连续复测几次，如果每次都慢在同一段，基本可以定性；如果忽快忽慢，先怀疑网络抖动、限速或者源站瞬时压力，而不是马上去改配置。

复测还能反过来验证判断。你改了解析、换了 CDN 节点、调了后端参数，再跑一轮，看的是同一段耗时有没有真的降下来。没有对照的「优化」，多数是心理安慰。

我的判断顺序

先看状态码确认请求是否走通，再拆五段耗时定位慢在哪一层，然后用节点分布判断影响范围，靠连续复测确认不是偶发。这几步走完，网络问题和服务器问题基本能分开，剩下的才是具体去查哪台机器、哪条线路。