502错误表示Nginx成功接收客户端请求，但无法从上游服务器获取合法HTTP响应，本质是代理链路中断；需分层排查：先查Nginx error.log定位具体错误类型（如connection refused、timeout等），再直连后端验证可用性，接着确认监听地址与端口匹配性，最后检查SELinux、防火墙或容器网络等系统级拦截因素。
502 错误本身不指向 Nginx 自身崩溃，而是明确表示：Nginx 成功接收了客户端请求，但在尝试与上游（后端）通信时，没拿到合法 HTTP 响应。所以它既不是纯 Nginx 配置错，也不是纯后端挂了，而是两者之间“链路断了”——定位关键在于分层验证通信是否真实通、是否真能响应、响应是否合规。
看 Nginx 错误日志里的第一句话
打开 /var/log/nginx/error.log，搜 502 或 upstream，重点关注最靠前的报错行，例如：
-
upstream timed out (110: Connection timed out)→ 后端没响应或连不上，问题大概率在后端或网络 -
no live upstreams while connecting to upstream→ upstream 列表里所有节点都被标记为不可用（如连续失败被踢出），先查健康状态 -
connect() failed (111: Connection refused)→ Nginx 根本连不上目标地址端口，后端进程未监听或地址写错 -
upstream sent no valid HTTP/1.0 header或upstream prematurely closed connection→ 后端返回了非法响应（如空包、截断、非 HTTP 协议数据），问题在后端输出逻辑或协议配置
这些信息直接告诉你故障落在哪一层。
直连后端：绕过 Nginx 测试真实可用性
在 Nginx 所在服务器上执行：
-
curl -v http://127.0.0.1:8080/health（替换为你的后端端口和健康路径）- 返回
200 OK+ 正常内容 → 后端活着且能响应，问题转向 Nginx 配置或超时 - 返回
Connection refused→ 后端进程没起来，或监听地址不对（比如只监听127.0.0.1，但 Nginx 配的是localhost解析成::1） - 返回
timeout→ 后端启动了但卡住，查其日志是否有数据库连接阻塞、死锁、OOM 被杀 - 返回
400/404/500→ 链路通畅，响应合法，502 就不可能是这里引起，应重点查 Nginx 的proxy_*_timeout是否太短
- 返回
检查后端是否真在监听对应地址和端口
别只看进程是否存在，要看它是否在 Nginx 认为的位置上“开着门”：
-
ss -tuln | grep :8080- 如果只看到
127.0.0.1:8080，而 Nginx 的proxy_pass写的是http://localhost:8080，在启用了 IPv6 的系统中可能解析为::1，导致连不上 - 推荐统一用
127.0.0.1显式指定，或让后端监听0.0.0.0:8080
- 如果只看到
-
systemctl status your-app或ps aux | grep node确认进程确实在跑，不是僵尸或僵死状态
验证 Nginx 到后端的“最小通路”是否受系统策略拦截
有些问题看似后端问题，实则是系统级限制：
- SELinux 启用时，默认禁止 Nginx 访问网络（包括回环），运行
setsebool -P httpd_can_network_connect 1临时放开 - firewalld 可能拦了
127.0.0.1上的端口（少见但存在），用firewall-cmd --list-all查看规则 - 容器环境注意：
proxy_pass http://host.docker.internal:8080在新版 Docker Desktop 中需手动启用；若用localhost，宿主机的localhost对容器而言是另一个网络命名空间，应改用宿主机真实 IP 或host.docker.internal
不复杂但容易忽略
