网站超时，八成不是服务器的锅

网站超时八成不是服务器锅——这话从一个天天跟机器打交道的人嘴里说出来是有点反常，但我见得实在太多了：页面一转圈，第一反应就是配置不够，钱一交，机器升了一档，结果第二天该转圈还是转圈。超时这事的本质是什么？是链条上某一环等得太久了。服务器只是这条链上的一节，而且常常是最老实、最没事的那一节。

网站超时八成不是服务器锅，先弄明白是谁在等

得把这个概念掰开看。用户看到的”超时”，其实是好几个不同层面的东西被混成一句话：浏览器等响应等烦了，网关等上游等烦了，PHP 等数据库等烦了，反过来数据库等锁也等烦了。每层都有自己的计时器，Nginx 有 fastcgi_read_timeout，PHP 有 max_execution_time，MySQL 有 wait_timeout 和锁等待超时。哪个先到点，报出来的错就长什么样。所以看到”超时”两个字先别慌，先问一句：是谁在等谁？

慢和等不到，完全是两回事

连接超时和响应超时，处理方式南辕北辙。连接超时是说包发出去，对面连握手都不给你，常见于防火墙丢了包、安全组少放了一条规则、源站端口没监听、DNS 解析指到了一个已经不用的 IP。响应超时是连接通了，请求也发过去了，对面吭哧吭哧算半天给不出结果。前者去查网络和端口，后者去查程序和数据库，混着查就是浪费时间。我习惯先 curl 一下，命令里带上 -w 把 DNS 解析、建连、首字节、总耗时分开打出来，几秒钟就知道卡在哪一段，比盯着监控图猜半天靠谱。

数据库这条线，最容易把人拖死

程序本身写得挺快，页面就是不出来，八成在数据库那儿。一条没走索引的查询，数据量小的时候看不出来，表涨到一定规模就原形毕露，平时几十毫秒的请求拖到几秒。还有锁等待，两个事务互相等着对方松手，谁也不让，最后只能靠超时解开。连接池也是个坑，池子开小了，请求排长队；池子开大了，数据库自己先扛不住。这些症状有个共同点：CPU 和内存看着都不高，机器闲得很，但页面就是慢。所以别光看机器负载，慢查询日志该开就开，开完记得回头看。

程序里那些外部请求，一个比一个坑

现在做个网站，谁还不接几个第三方：短信、支付、地图、对象存储、推送。这些调用只要有一个没设超时时间，就等于把自己的响应时间交给了别人。对面接口抖一下，你的页面就跟着卡一片。更隐蔽的是 DNS：服务器上配的解析器要是反应慢，每次调外部域名都要多等一会儿，单看一次不多，一个页面请求里串上七八个外部调用，时间就叠起来了。写代码的时候给 curl 加个明确的上限，失败就走降级，别让一个不重要的第三方接口把整页拖死，这是最基本的自保。

CDN 和回源之间，也会卡一道

挂了 CDN 的站，超时有时候发生在回源那一段。缓存没命中，CDN 老老实实回源站取，源站慢，CDN 那边就先超时了；源站前面要是还有 WAF 或者负载均衡，规矩多一层，慢的概率也就多一层。另外一种是反过来的：CDN 把静态资源缓存住了，看着挺快，动态请求全都回源，压力一点没少。这时候看现象很怪——首页秒开，点进内页就转圈，用户还以为是你程序有问题。

真要怀疑服务器，就看这几个数

说服务器完全没关系也不对，只是它排在后面。真要查机器，几个指标够用了：负载和 CPU 的 steal 值，steal 高说明宿主机在抢资源；内存有没有开始用 swap，一 swap 就什么都慢；磁盘 iowait 和 await，机械盘或者云盘被打满的时候，整个系统像冻住一样；还有带宽有没有跑满，出口打满的表现跟死机差不多。top、iostat、sar 这几个老工具就够，不用非得上多花哨的平台。虚拟主机或者共享型实例上，邻居吵闹也会拖累你，这种情况自己怎么优化都有限，以服务商的说明和监控数据为准，必要时提工单问清楚。

日志比监控图更会说人话

监控图告诉你”慢了”，日志告诉你是”哪一步慢”。Nginx 的 access.log 里如果配了 upstream_response_time，一眼就能看出来是后端慢还是 Nginx 自己慢；PHP-FPM 的 slow log 能抓到具体哪个脚本跑了多久；MySQL 的 slow query log 连 SQL 都给你留着。翻日志要有耐心，把超时那个时间点前后的记录拎出来对一对，跟访问量高峰对一对，通常十几分钟就能锁定方向。我见过不少人一上来就重启服务，重启完不慢了，就以为修好了——那是把现场给毁了，过两天它还会回来。

排查顺序：从外往里，别一上来就重启

顺序其实很简单：先在本地和几个不同网络环境 curl 同一个地址，看是不是只有某个地区慢；再用 mtr 看链路丢不丢包；然后 dig 确认解析结果是不是你预期的那台机器；进服务器看 Nginx 和 PHP 的错误日志；最后才动数据库和配置。整个过程别急着改东西，先看清楚。还有个小提醒：超时阈值别拍脑袋调大。把前端超时从几秒改到几十秒，用户早就关页面了，问题还在，只是从报错变成了白屏，更难查。

回到开头那句结论：网站超时八成不是服务器锅，真正吃掉时间的往往是那些看不见的等待——一条没走索引的 SQL、一个没设超时的接口、一次没命中的回源。下次页面上再转圈，先别急着掏钱升配，按上面的顺序走一遍，很多问题在自己代码和配置里就能找到答案。真查完一圈还是机器的事，再升级也不迟，那时候花的钱才花得明白。