复现不了，也要排查

用户说慢，我在自己电脑上打开，很快。差点回一句「没问题」。

后来问他所在的城市和运营商，再测一次，才看到差异。慢是有条件的，不是每次都有。那次我差点被自己的速度骗了。慢不是一种状态，是一段耗时，拆开之后问题就具体了。

把感受变成三个数字

第一，哪个地区、哪个运营商慢。

第二，状态码是什么。

第三，五段耗时里哪一段最长。

用宝塔拨测的网站测速跑多地区多运营商节点，这三个信息一次就能拿到。三个数字缺一个，判断都会偏。状态码异常时先别谈速度，5xx 是服务端，4xx 是请求或策略，这两种都不是优化能解决的。

四种典型的等

等解析：DNS 段最长。可能是解析商慢、CNAME 链太长、TTL 配置不合理。

等连接：TCP 段长。线路、丢包、防火墙，改代码没用。

等握手：TLS 段长。证书链、协议版本、会话复用。

等后端：TTFB 长。慢查询、缓存未命中、接口依赖。

等下载：资源大、带宽小、压缩没开。还有等跳转，一次 301 也算一段时间。

先排除假慢

本机插件、浏览器缓存、老设备、DNS 缓存，都会让「慢」只发生在一个人身上。同事的浏览器装了一堆插件，测出来比谁都慢。

换设备、换网络、无痕窗口，三步能排除大半本机因素。

都排除了，再谈服务端。

定位之后的动作

哪一段最长，只改那一段。一次改一处，改完记录时间和改动内容。别只测一次就下结论，单次结果很容易误导。跨地区的差异看分组最直观，平均值会把这些差异抹平。

别同时改 CDN、改代码、改配置，出了问题不知道是哪一步导致的。只改一处，是为了归因，归因清楚，优化才可复制。

复测

用同一批节点复测，对比同一段，不看总时长。有时候慢只在高峰期出现，那就换时间复测，这也是复测的一部分。

连测三次，稳定下降才算解决。最后一步才是改配置，前面的功夫都在缩小范围，范围小了改动才准，改动准了复测才有意义，这个链条别断。

用户感知和测量数据要能对上，否则只是数字好看。慢站的排查本质是排除法，排除到只剩一个答案就出来了，别急着猜，先测。用户说慢，先问三个问题：哪里、什么时候、打开的是什么，这三问能省一半时间。问得越具体，排查越快，别怕麻烦用户，他们提供的信息比日志还准。

把感受变成数字，问题就解决了一半。