Nginx 502 Bad Gateway 怎么排查？从错误日志到上游服务的完整清单

Nginx 页面突然显示 502 Bad Gateway，很多人第一反应是重启 Nginx。可 502 的核心通常不是 Nginx 自己坏了，而是它作为网关访问后端服务失败：上游端口没监听、PHP-FPM 挂了、应用进程退出、连接超时、配置指向了错误地址。本文把排查过程整理成一套可复用清单。

先说结论：遇到 502，不要先盲目改配置。更稳的顺序是：看 Nginx 错误日志，确认失败原因；检查 upstream 或 fastcgi 指向的地址；确认端口是否监听；检查后端服务状态；最后再看超时和权限。每一步都有明确检查点，问题会收敛得很快。

目标和边界：502 说明哪一段出了问题

502 表示 Nginx 已经收到了浏览器请求，但它转发给后端时没有拿到合法响应。后端可能是 PHP-FPM、Node 服务、Go 服务、Java 服务，也可能是另一个反向代理。换句话说，浏览器到 Nginx 这一段通常是通的，重点要查 Nginx 到上游服务这一段。

全流程总览：Nginx 502 排查路径

推荐把 502 排查拆成五步：访问页面确认现象，查看错误日志，检查上游端口，确认服务状态，最后恢复访问并做复查。

这条路径的好处是不会乱。日志告诉我们是连接被拒、连接超时、上游提前关闭，还是找不到 socket；端口检查告诉我们服务有没有在预期地址上监听；服务状态和应用日志则能解释为什么服务不可用。

阶段一：先看错误日志，不靠猜

第一阶段目标是拿到证据。先看 Nginx 错误日志：

tail -n 80 /var/log/nginx/error.log

常见关键词可以这样理解：

• connection refused：上游地址存在，但端口没有服务在监听。
• timed out：Nginx 等后端响应超时，可能是接口慢、队列堵、数据库慢。
• no such file or directory：如果使用 unix socket，socket 文件路径可能不对。
• upstream prematurely closed connection：后端进程提前断开连接，要看应用日志。

检查点：日志里的 upstream 地址要和配置里的一致。如果日志显示连的是 127.0.0.1:9000，而你的服务实际跑在 127.0.0.1:9001，那就不用继续猜了。

阶段二：检查上游端口和服务状态

第二阶段目标是确认后端服务是否真的活着。先看端口：

ss -lntp | grep 9000
ss -lntp | grep 8080

如果是 PHP-FPM，可以看服务状态：

systemctl status php-fpm
systemctl status php8.2-fpm

如果是业务应用服务，同样看对应服务状态和应用日志。端口没监听时，不要只改 Nginx；先让后端服务启动并监听正确端口。

阶段三：确认超时、权限和配置重载

第三阶段处理那些“服务活着但仍然 502”的情况。常见检查点包括：

• 后端接口是否耗时过长，超过 Nginx 读取响应的等待时间。
• PHP-FPM 的进程数量是否不足，队列是否堆积。
• unix socket 文件权限是否允许 Nginx 用户访问。
• Nginx 配置改完后是否通过检查并重载。

nginx -t
systemctl reload nginx

如果你调整了超时配置，也要配合应用日志验证接口为什么慢。只把超时调得很大，可能会掩盖真正的慢查询、远程调用阻塞或队列堆积。

我的推荐流程：从页面异常到恢复访问

实战中可以按下面顺序走：

1. 浏览器或 curl 确认返回 502，并记录发生时间。
2. 查看 Nginx 错误日志，定位 upstream 地址和错误类型。
3. 用 ss 检查端口是否监听，或检查 unix socket 是否存在。
4. 查看后端服务状态和应用日志，确认是否崩溃、重启或超时。
5. 修复后运行 nginx -t，再重载配置。
6. 再次访问页面，确认返回 200，并观察错误日志是否停止增长。

这套流程的重点是每一步都有证据。不要只看到 502 就重启所有服务，否则短期可能恢复，长期仍然不知道根因。

常见误区与速查表

常见误区有四个。第一，只重启 Nginx，不检查上游服务；第二，配置里端口改了，但应用服务仍监听旧端口；第三，使用 socket 时忽略文件权限；第四，把所有 502 都当成超时，直接把等待时间调大。

总结一下：Nginx 502 的排查主线，是确认 Nginx 到上游服务之间哪里断了。先看日志，再查端口，再看服务，再检查超时和权限，最后用页面响应和日志增长情况确认恢复。按这条线走，502 就不再是一个模糊错误，而是一条可以逐段验证的链路问题。