看到「请求超时」，很多人的第一反应是把超时时间调长。调长只是让等待变久，报错本身没消失。网站请求超时怎么解决，得先看它卡在哪一道时间闸上。

一次请求从头到尾，要过几道时间闸。闸口的时间值各家不一样，先记住自己这一套。下面按时间顺序走一遍。

卡在哪 表现 先看哪
解析一直等到超时也没有 ip记录、生效时间、解析链路
连接有 ip，握手前就断端口、防护、绕行
握手连上了，证书或协商没通过证书链、协商、队列
首字节连上了，迟迟等不到回应脚本、数据库、上游进程
下载有回应，传不完体积、请求数、出口带宽

请求出去后的头一秒，先看有没有解析结果

<figure><img src="https://image.bt.cn/20261112/1607519d6369c7eeaada2f782431e717.svg" alt="示意图：请求超时的三道时间闸，头一秒看解析，十秒看连接，三十秒在看首字节" loading="lazy" width="1200" /><figcaption>停在哪一档，就知道卡在哪一段。</figcaption></figure>

头一秒里该出结果的是解析。一秒都过去了还停在原地，先怀疑解析。

那么先看记录有没有、改了多久、有没有生效。再看换一台机器是不是也一样。

一台机器解不出，是那台机器的事；所有机器都解不出，是解析链路的事。

等到第十秒、第三十秒，是两道常见的时间闸

多数请求在这两个时间点附近被放弃，具体秒数按你这一套配置来对。看它停在哪一道，就知道卡在哪一段。

停在第十秒左右，多半是连接没建立起来。那么先看端口通不通，再看这一趟要不要绕很远。

用宝塔拨测的网站测速跑一次，五段耗时是分开给的，先看哪一段最长，再看那一段是不是超时的那一段。

停在第三十秒左右，多半是连上了但等回应。那么看首字节那一段，再往脚本、数据库、上游进程看。也可能只是网关的超时值比上游的实际耗时短。

第二天同一时段再看，才知道是不是偶发

超时最爱在高峰出现。晚上八点正常、早上九点超时，多半是负载的事，也可能是那个时段线路有变化。

那么第二天同一时段再跑一次。两次都在同一段超时，才算结论。只出现一次，先记下来。记时刻、记地区、记那一段的耗时。

有一处我还没确认：各家网关报超时时，会不会带上游那一段的耗时。如果有，就直接看那一段；如果没有，只能靠五段耗时反推。我手上没有统一字段。