异常不是「数字大」，而是「不该大的地方大了」。

判断的依据是分布和阶段：同一个阶段在所有节点都异常，还是只在一部分地区异常；异常出现在前端网络阶段，还是后端处理阶段。

情况一：某个地区 TTFB 极高，其它地区正常

这是最常见的一种。

典型表现：全国平均 TTFB 0.3 秒，但某几个节点 2 秒以上，DNS、连接、TLS 都正常。

原因多半有两个：该地区到源站的链路质量差，或者 CDN 调度没把用户引到就近节点。前者找运营商，后者找 CDN 厂商看调度配置。

判断动作：对这个地区单独跑一次路由追踪，看第几跳开始延迟暴涨。

情况二：所有节点都慢

如果连最快的节点都是 1.5 秒，那就不是网络问题。

优先排查三件事：

  • 源站负载：CPU、内存、连接数是否打满
  • 数据库：慢查询、锁等待
  • 后端接口：外部依赖超时、串行调用过多

这种情况换 CDN、加带宽都没用，因为瓶颈在服务器内部。

情况三：DNS 耗时普遍偏高

DNS 段动辄 0.3 秒以上，其它阶段正常。

两个可能：权威解析服务本身慢，或者 没有接入就近的解析节点。国内用户解析到海外权威服务器，延迟高是必然的。

可以拿 DNS 查询对比各地运营商返回的结果和耗时，看是权威解析慢，还是递归解析慢。

情况四：只有 HTTPS 慢，HTTP 正常

这个对比一做，问题基本锁定在证书和加密协商上。

常见原因：

  • 证书链不完整或过长，客户端要多拉几次中间证书
  • 加密套件协商开销大，没开 TLS 1.3
  • 没开 OCSP Stapling，每次握手都要额外查询
  • 用了不匹配的证书，触发重协商

开 TLS 1.3 和 OCSP Stapling，通常能把握手耗时砍掉一半以上。

情况五：状态码异常但耗时正常

能返回 403、502 而且很快，说明链路是通的，问题在应用层配置。

  • 403：WAF、防盗链、IP 白名单、UA 限制
  • 502 / 504：反向代理到后端超时，或后端进程挂了
  • 499：客户端主动断开，常见于超时设置过短
  • 503：服务不可用，可能是限流或上游未就绪

这时候测速工具的价值是排除网络因素——网络既然没问题，就不用再折腾线路了。

一个判断顺序

遇到异常，按这个顺序走，基本不会跑偏：

  1. 看是全体异常还是局部异常
  2. 局部异常 → 查链路和调度；全体异常 → 查源站
  3. 再看是哪一段耗时异常，定位到具体层面
  4. 最后看状态码，确认是网络问题还是应用问题