两边看起来都正常

页面慢，我登机器看了一遍：CPU 不高、内存有余、负载正常，于是判定「服务器没问题，网络的事」。可同一时间外部测出来的首字节时间明显偏高。

两边都没说谎。问题在于我看的指标，和用户等的那段时间，不是一回事。

外部测的是等待，内部看的是资源

拨测记录的是请求在各阶段的等待：解析、连接、握手、首字节、下载。它不关心你机器里发生了什么。

服务器指标记录的是资源使用：CPU、内存、磁盘、连接数。它不关心用户等了多久。

把两者放在一起，才能回答「等的那段时间，机器在干什么」。这也是为什么很多「服务器明明很闲」的故障，最后查出来是数据库锁等待或者上游接口拖住了。

网站测速：多站点分段耗时与状态码

网站测速：多站点分段耗时与状态码

五段先定性

用宝塔拨测的网站测速跑多地区多运营商节点，看哪一段异常。

DNS 长，问题在解析；TCP 长，在线路和端口；TLS 长，在证书和协议；TTFB 长，请求已经到了后端；下载长，在带宽和资源。

前三段基本可以排除服务器内部，后两段才需要往里查。这一步能砍掉一半工作量。

服务端指标做定量

TTFB 高的时候，进机器看四样。

CPU 和负载都高，说明算力不够，或者某个进程在空转。CPU 低但 load 高，通常是 I/O 等待。

磁盘 await 高、读写队列长，说明存储是瓶颈，数据库和日志写入都会受影响。

连接数打满、线程池排队，说明并发到了上限，请求在等资源，而不是在等网络。

这些指标要和外部异常的时间点对上。对不上，就不能当因果。看指标也要带时间维度，瞬时值和一分钟平均值说明的问题可能完全不同，最好对着异常发生的那几分钟看。

一个常见的组合

TTFB 高、CPU 低、磁盘正常、连接数正常，这时候要怀疑外部依赖：数据库慢查询、缓存未命中、上游接口超时。

这类问题的特征是「机器很闲但请求很慢」。只看服务器资源永远找不到原因，得去看调用链和慢查询日志。

反过来，TTFB 正常但下载段长，别去调后端，去看带宽和静态资源。

复测和时间对齐

改完用同一批节点复测，同时记录改动时间。两边时间对齐，才能确认改善是这次改动带来的。

连续测两三次，排除抖动。只看一次，很容易把巧合当成因果。记录里写清楚改了什么、什么时候改的。

判断网络还是服务器，靠的不是谁看起来更可疑，而是两边的时间能不能对上。