网站报错504：多半卡在网关那一环

504 这行字蹦到浏览器上，八成不是页面写错了，而是中间那个负责传话的等后端等到没耐心，直接把请求掐了。网站报错504 在后端日志里通常对应一句 upstream timed out，位置大致在 Nginx 的 error.log，或者负载均衡、CDN 的回源日志里。先把这个位置记住，比背一堆教程管用。

网站报错504，卡住的到底是哪一环

一个请求不是一步到位的。浏览器出去，先过 CDN，再到负载均衡，落到 Nginx，转给 PHP-FPM 或者后端应用，最后摸到数据库、缓存、第三方接口。504 的本质就是这条链上前面那一环，等后面那一环等超了。顺手分一下 502 和 504：502 更像上游直接撂挑子，进程崩了、端口没通、socket 连不上；504 是上游机器还活着、端口也通，就是不给你回话。分不清这两个，排查方向就会跑偏。

网站报错504最常见的三种场景

第一种，后台跑长任务。导出一张几万行的表、批量采集、生成静态页、压缩图片，这类活儿的耗时取决于数据量和机器，前端就那么干等着，等到网关设定的上限就断了。第二种，进程池排满了。PHP-FPM 的子进程被几个慢请求占死，后面的请求全都堵在门外，进去的也没人处理，表现出来同样是 504。第三种，外部接口卡住。支付回调、短信、地图、对象存储，任何一家响应变慢，你这边就跟着干等；如果代码里没设连接超时，它能把整条链路一起拖住。

先翻日志，别上来就改超时值

error.log 里那句 upstream timed out 后面会跟一个上游地址。看清楚了：是 127.0.0.1:9000 这种本地 FPM，还是某个内网 IP 上的后端服务，方向立刻不一样。前者往 PHP 和应用上查，后者往网络和那台机器上查。再看一眼 PHP-FPM 的慢日志，把 request_slowlog_timeout 打开，慢请求的调用栈会直接告诉你是哪一行代码在磨蹭。数据库的慢查询日志也顺手开一下，有些 504 的源头就是一条没走索引的 SQL 把表锁住了。

调大超时只是止血，治不了病

Nginx 的 proxy_read_timeout、fastcgi_read_timeout，改大一点页面确实能打开，很多人到这一步就收工了。问题是请求还在那儿跑，还占着进程，等于把病灶往后推，等流量高峰一起爆。还有一组容易打架的参数：PHP 的 max_execution_time 和 FPM 的 request_terminate_timeout，谁先生效决定你看到的是 504 还是 502，两个都乱设会让人怀疑人生。改之前先把这三个值的实际生效顺序在心里过一遍。

进程池不够，也会披着超时的皮

pm.max_children 设得太小，pm 用 dynamic 时 start_servers 又给得抠，请求一多就排队。表现是同一个页面刷两下好了、再刷又 504，看着像玄学。把 FPM 的 status 页开出来看 active process 和 listen queue，队列数字一直在涨，那就别再怀疑代码了，先扩容进程数或者加机器。

几个特别容易被忽略的角落

CDN 的回源超时往往设得比源站还短，源站慢一点点，用户那头已经是 504，查日志怎么都查不到，因为请求根本没到源站。大文件上传和后台导出也常撞这条线，尤其跨地域线路抖一下。还有一个很隐蔽的：PHP 的 session 文件锁，同一个用户开多个标签页并发请求，后面的全卡在锁上，单个测都正常，一并发就超时。

下次再遇到，按这个顺序走

先确认是所有页面都 504，还是某一个功能 504，这一步能砍掉一半工作量。再看日志里超时的是哪一环，是 FPM 还是后端服务还是外部接口。然后对着那一环查：进程数够不够、慢日志里谁在拖、外部调用有没有设超时。最后才是调参数，而且调完记一笔，方便以后回滚。整套下来，多数情况不用半小时就能摸到病灶。

还有个判断技巧值得记住：刷新就好和刷新也好不了，是两种病。前者多半是排队或者偶发的接口抖动，后者才是真的卡死在某一步。别把 504 当成一个可以靠调大超时糊弄过去的报错，它更像一个提醒，告诉你链路上有一环的活儿超出了它该承担的份量。把长任务挪到队列里后台跑、给外部请求设上连接超时、按并发量重新算一遍进程池——这三件事做完，504 出现的频率会明显降下来。参数怎么设，以你所用面板或服务商的官方说明为准，不同版本默认值不一样，别照抄别人的截图。