502 与 504 的排查顺序：从 php-fpm 到 upstream 超时

502 Bad Gateway 和 504 Gateway Timeout 长得很像，成因完全不同：前者是"后端连接不上或提前断开"，后者是"后端连上了但迟迟不返回"。

先分清是哪一种

看 Nginx 错误日志里的 upstream 那一行：

tail -50 /www/wwwlogs/*.error.log | grep upstream

出现 connect() failed 或 Connection refused 是 502；出现 upstream timed out 是 504；出现 recv() failed (104: Connection reset by peer) 通常是后端进程崩了，也是 502。

502 排查顺序

• 后端服务活着吗：systemctl status php-fpm 或 ps aux | grep php-fpm。
• 监听地址对不对：Nginx 转发到 127.0.0.1:9000，而 php-fpm 监听在 socket 上，就会一直 502。
• 进程池够不够：pm.max_children 打满时，新连接直接被拒，日志里会看到大量 connect failed。
• 权限问题：socket 文件属主不对，同样连不上。

504 排查顺序

• 先看是哪一层超时：Nginx 的 fastcgi_read_timeout、PHP 的 max_execution_time、数据库的慢查询，三层都可能。
• 找出慢请求：开 slowlog 记录超过 5 秒的脚本，比盲调超时时间有效得多。
• 如果是采集、导出这类确实耗时的任务，正确做法是转异步队列，而不是把超时从 60 秒调到 600 秒。

一个容易忽略的点

502/504 有时是"间歇性"的：高峰期才出现。这类问题先看监控里的并发曲线，再对应进程池设置，往往比逐条翻日志快。真正稳定的站点，pm.max_children 应该按内存反推：单个 PHP 进程约 30-50MB，4G 内存的机器给 60-80 个子进程比较稳，留足给数据库和系统的余量。

本文首发于 izzsj.com，作者保留全部权利。未经书面授权，禁止任何形式采集、转载与镜像；转载请注明来源并保留原文链接。