网站超时3个常见原因；第2个最坑

网站超时3个常见原因；第2个最坑——这话摆出来有点像标题党，但确实是被拉去救火时反复见到的排位。浏览器转圈转到自己放弃，弹个 504，或者干脆白屏一片，大多数人的第一反应是「带宽不够吧」「是不是被人打了」，于是一头扎进网络层，换 DNS、查线路、找运营商，折腾一圈回来页面还在转。问题常常不在你盯着的那个地方。

先分清是连不上，还是连上了不给东西

超时这两个字盖着两种完全不一样的病。一种是连接超时，TCP 三次握手都没完成，请求连服务器的门都没摸到，多半出在解析、防火墙、安全组、端口没放行、IP 不通这一串上。另一种是响应超时，门进了，请求也发出去了，服务器迟迟不吐数据，浏览器等到自己放弃，504 大多属于这一种。分不清这两者，后面全是瞎猜。

有个命令能帮你一眼看出差别：curl -o /dev/null -s -w “connect:%{time_connect} start:%{time_starttransfer} total:%{time_total}\n” https://example.com/ 。connect 那项就很大，别怀疑后端，去查线路和防火墙；connect 很小、starttransfer 很大，就是应用或者数据库在磨蹭，跟带宽关系不大。

网站超时3个常见原因第2个最坑，坑在数据库

排第二这个之所以最坑，是因为它从头到尾都在装成网络问题。页面能打开，HTML 也开始返回了，标签页上的小圈一直转，用户跟你喊「网站卡死了」。你去看带宽——闲着；看 CPU——不高；ping 一下——通。于是顺手把锅甩给机房，机房说线路正常，两边来回踢，谁都不服。

真实情况往往是一两条没走索引的慢 SQL。数据量涨上来之前，这查询零点几秒，没人管；涨上来之后每次都得扫一遍，几个用户同时点，线程就堆在那儿。再加上凌晨的备份、白天的报表导出、某个插件偷偷跑的统计任务，全在抢磁盘 IO。连接池被占满以后，新请求全在门外排队，表现出来就是转圈、然后超时。

想让证据自己说话，把慢查询日志开起来（slow_query_log），看看排在前面的语句长什么样；数据库控制台里 show processlist 瞄一眼，有没有一堆状态卡在 Sending data 或者 Locked 的线程。看到这些，就别再纠结带宽了。

第一个原因，出口被吃满，还不一定是你的流量

带宽打满是老生常谈，但很多人只想到「套餐买小了」。首页那几张没压过的大图、自动播放的视频、一堆字体图标，手机端用户等得直骂人。也可能压根不是你自己的流量——接口被人刷、内容被批量采集、碰上流量型攻击，都能把出口占死。看监控里出网流量的曲线，是不是贴着上限走、有没有明显尖刺，比凭感觉靠谱得多。

第三个原因，后端进程不够用，或者被一个慢请求占死

php-fpm 的 max_children 设得保守没关系，设得太小就有关系。几个导出、搜索、生成报表之类的慢请求同时进来，进程池瞬间满了，后面的一律排队，排到超时。这种超时有个特点：间歇性发作，一会儿好一会儿坏，负载看着还不高，特别容易让人误判。node 或者 Python 的服务也类似，单个线程被重任务堵住，整个服务的响应跟着掉，外表和「服务器挂了」几乎一样。

办法就是看进程池状态，再按接口把耗时拉出来对比，谁慢谁心里有数。

三步把责任划清楚，别在群里互相甩

第一步，浏览器 F12 的 Network 里看那条请求的 Timing，时间花在 Waiting(TTFB) 还是 Content Download，指向完全不同的方向，TTFB 特别长基本就是后端的锅。第二步，在服务器上直接 curl 本地地址，绕开 CDN 和公网，快说明问题在外面，一样慢说明问题在屋里。第三步，翻日志：web 服务器的处理时间、数据库慢日志、进程池状态，三份摆一起看。三步做完，剩下的是修，不是猜。

还有几个爱冒充的配角

解析慢、SSL 握手拖拉、CDN 回源超时、安全组改完没生效、域名同时挂着 IPv6 记录但那条路根本走不通。这些不算高频，可赶上了特别折腾人，因为表面症状和前三种一模一样，连报错都懒得换个花样。对付它们的办法很土：直连源站 IP 试一次，把中间环节全绕开，快慢立判。

顺手说说日常怎么少踩

把慢查询日志当成常开项而不是出事才开；给定时任务挪到凌晨并且限制并发；图片上传时就压掉，别指望前端临时缩；监控里至少盯住三根线：出网流量、TTFB、数据库连接数。这几件事花不了多少功夫，但能让你在半夜少接几个电话。

要让我给个动手顺序：先量 curl 那三个数，确定是连接慢还是响应慢；响应慢就先翻数据库，别急着升级套餐；数据库干净了，再回头看带宽和进程数。超时这毛病，改对地方一次就完事，改错地方能陪你一整年。