一句「异常」，三种现场

同事说测速结果异常，我问是哪一种，他愣了一下，把报告甩过来。

点开一看：一条是超时，一条是 502，还有一条直接 0 毫秒失败。这三种碰巧都叫异常，修法差得很远，混在一起讨论只会越说越乱。

先用状态码分流

这一步三十秒，能砍掉一半无效排查，也能让沟通有共同语言。

0 或者直接失败：请求根本没发出去，多半是解析没结果，连目标地址都没拿到。

403、429：请求到了，被明确拒绝，属于策略和限流这一层，改服务器配置没用。

5xx：服务端自己出了问题，跟网络关系不大，先去翻应用日志。

200 但很慢：这一类才需要往分段耗时里看，也是最多人卡住的一类。

四层，一层层往下

每一层都有自己的证据，别跨层猜，猜出来的结论经不起复测。

解析：DNS 段耗时长，或者直接解析失败，问题在解析链路，换服务器解决不了。

连接：TCP 段超时，说明网络不通、端口没开，或者被中间设备直接丢了包。

握手：TLS 段失败或明显偏长，重点看证书链是否完整、加密套件是否匹配。

应用：TTFB 和下载段慢，属于服务端处理或者内容体积的问题，这一段最长也最值得优化。

用宝塔拨测的网站测速跑多地区多运营商节点，状态码和五段耗时一起列出来，再按地区和运营商分组，断在哪层、影响到谁，基本一眼能看出来。

别被平均数骗了

范围判断错了，后面全是白工，还会让本来没问题的一方背锅。

平均正常、最慢节点很差，说明是局部问题，别按全局故障处理，否则动作一定过头。

所有节点都在同一段慢，才更像共性原因，比如源站处理慢或者出口带宽被打满。

按运营商分组，只有一家慢，先怀疑互联，不要急着改代码，改了也不一定见效。

复测怎么安排

复测是为了排除偶然，不是为了凑数据，也不是为了让报告好看。

同一组节点、同一个地址，连测三次，条件尽量别变。

每次都停在同一层，才算稳定结论，一次的异常先记下来观察，别急着报故障。

改完一处再测同一段，不然根本不知道是哪一步起效，下次也没法复用。

别急着定责

定责之前，先把事实摆齐，事实齐了，责任自然清楚。

异常不等于故障，有时只是某个节点抖了一下，尤其跨运营商的那几个。

先把层次和范围定下来，再谈是谁的问题，比开会争论有用，也更容易收尾。

这一层一层下来，异常总能找到落点。