网站一直504网关超时是怎么回事？原因和排查思路一篇讲清

网站打不开，屏幕上跳出一行英文，504 Gateway Timeout，这种经历干站长的基本都遇过。有些站还特别闹心，白天好好的，一到某个点就犯病，刷新几下又恢复，过一阵子再犯，气得人牙痒痒。其实504没你想的那么严重，它跟服务器彻底挂掉、数据全没是两码事，多数时候只是网关等后端等得太久，等不到结果就自己先放弃了。今天这篇文章，咱们就把504网关超时是怎么回事讲透，把常见的坑一个个摆出来，再给你一套照着做就行的排查顺序，让你下次再碰到，心里有数，手上有招。

一、504网关超时到底是什么意思

先搞明白请求是怎么走的。用户在浏览器里敲网址，请求先到网关或者反向代理这一层，nginx就是最常见的反向代理，网关再把请求转给后头的程序去处理，程序处理完返回结果，网关原样送回浏览器。正常情况下这一来一回很快，你几乎感觉不到中间还有一层。可要是后端程序处理得太慢，超过了网关设置的等待上限，网关就不会继续傻等，直接给浏览器返回一个504状态码。504的全称叫Gateway Timeout，翻译过来就是网关超时。拿饭馆打比方，网关好比传菜的服务员，后厨半天不出菜，服务员总不能一直干站着，只能告诉客人这单暂时上不了，504就是服务员那句等不及了。

二、504和502、500的区别先分清

不少站长把502和504混在一起，排查时来回折腾。其实这仨看着像，意思差得远。500是服务器内部错误，通常是程序代码本身出了问题，比如抛了异常、配置写错，程序自己都跑不起来。502是网关收到了后端给的错误应答，最常见的是PHP-FPM进程挂了或者崩了，nginx从后端拿不到正常的响应。504不一样，后端程序还活着，也没报错，就是干活太慢，超过了网关愿意等的极限。再打个比方，502像是后厨直接把锅烧了，没法出菜，500像是菜谱本身有问题，怎么做都不对，504则是后厨忙得团团转，出菜太慢，客人等不及先走了。分清这三者的区别，起码能少走一半弯路。

三、最普遍的原因就是反向代理超时

对用nginx做网关的站来说，504出现最频繁的原因，就是反向代理这一层的超时时间设得太短。nginx里跟代理转发有关的超时参数主要有三个，proxy_connect_timeout是跟后端建立连接的超时，proxy_send_timeout是发送请求数据的超时，proxy_read_timeout是从后端读取响应的超时。其中跟504关系最大的就是proxy_read_timeout，它规定了nginx向后端发起请求之后，两次读取之间最多能等多久。默认情况下这个值往往只有几十秒，页面要做个耗时长的导出、大批量数据处理，或者传大文件，时间一超，nginx立刻回一个504。遇到这类情况，先想想业务场景里有没有长时间请求，再决定要不要把超时调大，思路很直接，但很多人第一步就卡在不知道还有这么个参数。

四、PHP-FPM处理太慢也会报504

要是网站跑的是PHP，比如WordPress，请求到了nginx之后还得交给PHP-FPM去处理。PHP-FPM是PHP程序的处理进程，页面里只要有一块耗时的操作，比如生成报表、批量发邮件、同步第三方接口数据，PHP-FPM就得一直干活。活干不完，nginx等着等着就超时了，504就这么来了。另外还有两层时间限制容易被忽略，一是PHP自己配置里的max_execution_time，管的是单个脚本最长能跑多久，二是PHP-FPM的request_terminate_timeout，管的是一个请求最多能处理多久，这两个值设得太小，脚本跑到一半被强杀，页面上一样会出现各种异常。排查的时候记得开PHP-FPM的慢日志，把执行超过几秒的请求都记下来，再结合日志看看是哪个页面、哪个接口在拖后腿，问题往往就藏在这里。

五、数据库卡住和服务器负载过高是隐形杀手

504的锅有时候不在程序，而在程序依赖的东西上。数据库就是头号嫌疑犯。表被锁住、慢查询堆积、连接数被打满，都会让程序卡在等数据库这一关，页面迟迟出不了结果，网关那头自然就超时了。服务器本身负载过高也一样，CPU跑满、内存不够用，进程排队等着调度，本来一秒能干完的活拖成十秒，想不超时都难。遇到504，建议先登服务器看一眼负载，再查查是哪个进程在吃资源，同时翻翻数据库的慢查询日志，看看有没有大查询一直在跑。之前有个站每到下午固定时段就报504，查了半天，最后发现是数据库的定时备份任务跟业务高峰撞在了一起，把备份时间错开，问题当场消失，可见根因往往藏在这些不起眼的地方。

六、用了CDN，回源超时这一层别忘了

现在很多站都接了CDN，好处是访问快了、扛得住流量，但排查504的时候也多了一层麻烦。用户访问的是CDN节点，节点拿不到缓存，就得回源到你的服务器取数据，回源这一段同样有超时限制。有时候你的源站处理本身没问题，只是个别请求耗时太长，超过了CDN回源超时的上限，CDN节点就会直接给用户返回504，锅还得源站背。遇到这种疑似情况，可以先把域名解析临时指到源站IP，绕开CDN直连测试，要是直连源站一切正常，一走CDN就504，那问题多半出在回源环节，要么找CDN服务商把回源超时调大，要么检查源站上有没有响应特别慢的请求，把慢的根源处理掉才是治本。

七、nginx超时参数这样调才靠谱

原因摸清了，再说说具体的配置思路，很多教程爱直接丢一段配置让你抄，其实关键是要理解每个参数干嘛用的。在nginx的server或者location配置块里，可以给代理转发单独设超时，比如把proxy_connect_timeout设成60秒，proxy_read_timeout设成120秒，proxy_send_timeout设成120秒，要是业务确实需要更长的处理时间，再根据实际情况往上加。如果代理的是PHP请求，还要注意fastcgi那一组参数，fastcgi_connect_timeout、fastcgi_read_timeout、fastcgi_send_timeout，思路跟代理参数一模一样。改完配置千万别忘了先检查nginx配置语法对不对，确认没问题再重新加载配置，然后反复去点刚才报504的页面，看到底还犯不犯。这里多说一句，超时时间不是越大越好，调得过大，后端要是真卡死了，用户会一直在那儿干等，体验更差，所以调参数的同时，一定要配合后端慢日志一起看，找到真正拖慢的环节。

八、照着这个排查顺序来，别走弯路

真碰上504，别慌也别瞎重启，按顺序一步步来。第一步，看监控或者访问日志，统计504出现的时间段，判断是持续报错还是偶尔抽风，这个信息能帮你缩小范围。第二步，登录服务器，看CPU、内存和系统负载，先把资源被占满这个可能排除掉。第三步，打开nginx的错误日志，仔细看504前后都记了啥，日志里一般会写明是跟后端连接超时还是读取超时，方向一下子就清楚了。第四步，翻PHP-FPM的慢日志和数据库的慢查询日志，把处理慢的请求一个个揪出来。第五步，针对找到的环节下手，该调超时的调超时，该优化代码的优化代码，改完再复测几轮。日志不会骗人，顺着日志一层一层往下查，大部分504都能在半小时内找到根因，切忌东一榔头西一棒子地乱试。

总结一下，504网关超时看着吓人，本质就是网关等后端等得太久，耐心耗尽了。它跟502、500的区别，在于后端程序到底还活着没有、是不是真的出了错。常见的坑不外乎那么几个，反向代理超时设置太短、PHP-FPM处理太慢、数据库卡住、服务器负载过高，要是接了CDN，还得加上回源超时这一层，挨个排查基本都能解决。调超时参数要结合自己业务的真实情况，别一股脑往大了调，更重要的是配合日志看，找到真正的病根再下手。希望这篇能帮咱们站长下次再碰到504的时候心里有底，手上有招，三下五除二把问题摆平，让网站安安心心转起来，用户开开心心访问，别再被那一行英文吓得够呛。