响应时间过长，页面就是不出来

客户截图过来，浏览器一行灰字：响应时间过长。服务器没挂，SSH 能连，CPU 也不高。

这种情况下重启一下，有时候还真好了。所以很多人就养成了先重启的习惯，也包括我。

先问一句：等在哪

问清这一点，比急着动手重要，也能避免把别人的问题当成自己的。

响应时间过长，本质是「某个环节等超时了」，不是「服务器死了」，两件事的处理方式完全不同。

请求可能停在解析、停在建连、停在握手，也可能到了服务端却迟迟不返回，每种停法对应的人都不一样。

不切开这段等待，重启只是把现场清掉了，下次还会再来，而且可能来得更突然。

五段分别对应谁

五段不是概念，是五个可以分别验证的位置，每一段都能单独测。

DNS：解析没结果或者很慢，页面连目标地址都拿不到，浏览器只能转圈。

TCP：连接建不起来，卡在网络上，或者对端端口根本没人接。

TLS：握手完不成，浏览器会给一个证书警告，这个最好认。

TTFB：连上了，服务端迟迟不给第一个字节，问题多半在应用逻辑或者数据库。

下载：内容开始传了却传不完，卡在带宽、丢包重传，或者资源本身就太大。

用多节点把范围定下来

范围不定，结论就没法用，说出去也没人服。

单点超时，可能是你自己的网络，也可能是那一个节点的问题。

多地同时超时，才是面向所有人的问题，这时候才值得按故障处理。

用宝塔拨测的网站测速跑多地区多运营商节点，同时看状态码和五段耗时，再按地区、按运营商分组，很快能分清是局部链路还是源站，这一步比重启有用得多。

重启为什么偶尔有效

知道它为什么有效，才知道它为什么不解决问题，这中间差着一整套排查。

重启清掉了卡住的连接和积压的请求，看起来是恢复了，但只是把时钟拨回了零。

但根因还在，只是被暂时清空，流量一上来又会复现，而且往往在半夜。

所以恢复之后要补一次复测，把当时的五段数据留下来，这才是下次的判断依据。

复测与留证

留证不是为了追责，是为了下次更快，也能让新人有据可查。

同一地址、同一组节点，连测三次，别换条件。

每次都超在同一段，结论就站得住了，也敢拿去跟别人解释。

把时间、节点、状态码、五段耗时记下来，下次再出现，对照一下就知道是不是同一个毛病，不用从头查起。

下次再看到那行灰字，先想五段，不要先想重启。