区分 502 与 504 的成因，按上游、超时、连接数、资源四层给排查顺序。下面按“先判断、再动手、最后验证”的顺序展开，每一步都给出可核对的检查点。
涉及 Nginx 502、Nginx 504、网关错误 的关键动作都写成了具体命令或配置项，可以照着走，也可以当检查表用。
502 是上游返回无效响应或连接被拒；504 是上游超时没回，两者的第一条排查路径完全不同。
php-fpm 进程没起、监听地址与 nginx 配置不一致、socket 权限不对；先看 error.log 里的 connect() failed。
脚本执行超时、数据库慢查询、上游被限流；先看 php-fpm 的 slow log 而不是 nginx 日志。
fastcgi_read_timeout 与 request_terminate_timeout 要匹配，只调一边会出现「nginx 还在等，php 已杀」。
pm.max_children 按内存除以单进程占用估算，排队请求看 listen backlog 与 nginx 的 upstream 队列。
| 环节 | 关键动作 |
|---|---|
| 先分清语义 | 502 是上游返回无效响应或连接被拒；504 是上游超时没回，两者的第一条排查路径完全不同 |
| 502 常见原因 | php-fpm 进程没起、监听地址与 nginx 配置不一致、socket 权限不对；先看 error.log 里的 connect() failed |
| 504 常见原因 | 脚本执行超时、数据库慢查询、上游被限流；先看 php-fpm 的 slow log 而不是 nginx 日志 |
| 超时配置 | fastcgi_read_timeout 与 request_terminate_timeout 要匹配，只调一边会出现「nginx 还在等，php 已杀」 |
Q：按文中写法改完，怎么确认真的生效？
不要只看配置文件，用对应的验证命令或从外部视角复测一次；改完先小流量观察一段，再全量推进，出问题能马上回退。
Q：按文中的步骤做完，还需要注意什么？
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录，比重查一遍快得多。
Q：业务规模小，也要按这套标准来吗？
不需要一次到位。先把影响最大的两项做到位，剩余的随着业务增长逐步补齐，比一开始就追求完美更容易落地。
回到这篇的 5 个环节：先分清语义、502 常见原因、504 常见原因、超时配置、连接数。把这几个动作写进检查表，下次遇到同类问题按顺序过一遍，比凭经验跳步骤稳。
相关阅读：防火墙配置：firewalld与iptables怎么选、systemd服务管理：从单元文件到日志、Linux常用命令速查：文件、进程、网络。
延伸阅读：MySQL慢查询定位与索引优化、systemd服务管理：从单元文件到日志、内存占用高排查：从free到smem。
微信公众号
微信客服
