Nginx 502 Bad Gateway 怎么排查：从 upstream 到应用端口一步步定位

线上页面突然变成 502 Bad Gateway，很多人第一反应是“网关坏了”。但在 Nginx 反向代理场景里，502 更常见的含义是：Nginx 收到了请求，却没能从上游应用拿到正常响应。

这篇文章按常见问题排查路线来走：先看页面现象，再读错误日志，接着检查 upstream、端口和应用服务，最后修复配置并重新访问验证。重点不是背结论，而是知道每一步能排除什么。

问题现场：页面突然变成 502

假设用户访问 https://example.com/api/user，页面返回 502。浏览器只能告诉我们“网关没有拿到好结果”，不能告诉我们上游到底哪里断了。我们先把排查链路画出来：

这个时候不要急着重启所有服务。正确做法是先确认三件事：

1. Nginx 是否收到了请求。
2. Nginx 连接的 upstream 是哪个地址和端口。
3. 上游应用是否真的在这个地址端口监听。

初步判断：502 通常卡在网关到上游应用之间

Nginx 返回 502，通常说明网关层已经工作，但它连接 upstream 时失败，或者上游应用提前断开连接。我们先把方向缩小到“网关到应用”这一段。

常见原因有这几类：

动手验证：先看错误日志和 upstream

第一步看 Nginx 错误日志。不同系统路径可能不同，常见路径如下：

tail -n 80 /var/log/nginx/error.log
tail -n 80 /usr/local/nginx/logs/error.log

如果看到类似下面的信息，基本可以判断 Nginx 连不上上游应用：

connect() failed (111: Connection refused) while connecting to upstream,
client: 10.0.0.12, server: example.com,
request: "GET /api/user HTTP/1.1",
upstream: "http://127.0.0.1:8080/api/user"

这一步说明：请求已经到达 Nginx，失败发生在连接 127.0.0.1:8080 这个 upstream 的时候。接下来就不是盲目改页面，而是检查这个端口是否有应用在监听。

定位原因：端口错、服务没起、配置没生效

现在用端口命令验证：

ss -lntp | grep ':8080'
curl -i http://127.0.0.1:8080/api/user

如果 ss 没有输出，说明 8080 没有服务监听；如果 curl 也失败，就说明不是浏览器问题，而是 Nginx 指向的上游不可用。

接着检查应用服务状态：

systemctl status app.service
journalctl -u app.service -n 80 --no-pager

如果应用实际监听的是 8081，而 Nginx 配置仍写 8080，就要回到站点配置里确认 proxy_pass：

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
    }
}

这一段配置的关键是：proxy_pass 的地址、端口、路径拼接方式，要和应用真实监听方式一致。

修复方案：按日志、端口、配置和应用四层处理

修复时不要只改一处就结束，要按链路逐层处理：配置校验、应用启动、端口监听、重新加载、访问成功。

如果应用没有启动，先启动应用并确认状态：

systemctl start app.service
systemctl status app.service
ss -lntp | grep ':8080'

如果端口配置写错，修改 Nginx 配置后先做语法检查：

nginx -t

通过后再重新加载：

nginx -s reload

如果使用 systemd 管理 Nginx，也可以用：

systemctl reload nginx

这里的顺序很重要：先确认应用端口真的通，再加载 Nginx。否则即使配置语法正确，502 还是会继续出现。

验证结果：返回 200 才算真正恢复

修复后不要只刷新一次浏览器。建议用命令同时验证本机 upstream 和外部入口：

curl -i http://127.0.0.1:8080/api/user
curl -i http://example.com/api/user

如果 upstream 返回正常，但外部入口仍然 502，就继续看 Nginx 配置是否加载到了正确站点，或者是否还有负载均衡、容器网络、防火墙等中间层。

最后再看日志确认没有新的错误：

tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/nginx/access.log

总结清单

总结一下，Nginx 502 排查不要从“重启一切”开始，而要顺着请求链路走：页面现象、错误日志、upstream、应用端口、配置加载、最终访问。只要每一步都能给出证据，502 就会从一个模糊报错变成可定位、可修复的问题。