转圈三分钟，连报错都没有

客户发来截图，页面一直转，浏览器既不说无法访问，也不给错误码。

这种最难查，因为没有报错信息，只有「没回来」这个事实，也很难向别人描述。

无响应和慢的区别

一句话就能分开，但很多人一开始就混了，于是改了一堆不相干的东西。

慢是请求有去有回，只是回来得晚，最后能拿到内容。

无响应是请求发出去，等不到结束，可能卡在连接、可能卡在响应、也可能卡在传输，三种修法不一样。

区别在于「有没有结束」，处理方式完全不同，别用同一种手段硬套。

三种停住的位置

位置不同，负责的人也不同，找错人就会一直等。

停在 TCP：连接建不起来，一直等握手，通常是端口不通、中间丢包，或者对端 accept 队列满了。

停在 TTFB：连接建好了，服务端迟迟不返回第一个字节，属于被 hold 住，这时候查网络是白费。

停在下载：响应头回来了，内容传到一半断掉，传输被掐断或者源端没写完。用宝塔拨测的网站测速跑一轮，五段会告诉你停在哪一格。

服务端为什么会 hold 住

这一类最像「玄学」，其实机制很具体，查日志就能看到线索。

连接池被占满，新请求排队排到超时，表现就是少数用户一直转圈。

慢查询或锁等待，数据库不返回，应用只能干等，日志里往往只看到「请求超时」。

同步调用一个外部接口，对方不响应，自己跟着卡住，这类最容易被误判成自己慢。

这几类通常表现为「重启就好，过一会儿又来」，因为重启只是清空了队列，根因没动。

用多节点判断范围

范围定不下来，就只能靠猜，猜错的代价往往是几天。

所有节点都无响应，问题在站点，别怀疑本地网络，也别先怀疑工具。

只有部分运营商无响应，先看链路和中间设备，这类找运营商更直接。

复测与动作

能重复出现，才值得动手，偶发的先记录再观察。

同一地址连测三次，确认是稳定无响应还是偶发，偶发的先记着观察。

改完再看同一段耗时，别只看「能打开了」，能打开和恢复原状是两件事。

重启只是清场，不是修复，把根因和触发条件记下来，才算真正收尾。

无响应这类问题，最怕的是没有证据就重启。

留下证据，下次就不用从头再猜。

证据在手，判断才站得住。

站得住，才敢跟业务方说已经处理完。

处理完并且有据可查，这才叫解决。

这两个字，比任何汇报都好用。

下次再遇到转圈，先别急着重启。