502错误是Nginx作为反向代理未能从上游获取合法HTTP响应，需依错误日志线索（如connection refused、timed out、prematurely closed）分层排查连通性、超时、后端稳定性及配置合规性。
502 错误不是前端问题，也不等于后端服务“挂了”，而是 Nginx 作为反向代理，在和上游服务通信时拿不到合法 HTTP 响应。判断关键在于：看请求是否能通到后端、后端是否真在响应、响应是否合规。
看 Nginx 错误日志，锁定第一线索
错误日志（通常是 /var/log/nginx/error.log）会直接告诉你问题出在哪一环：
- 出现
connect() failed (111: Connection refused)→ 后端没监听端口，可能服务根本没启，或只监听了127.0.0.1而 Nginx 配的是内网 IP - 出现
upstream timed out→ 连得上，但后端处理太慢或卡死，超时断开 - 出现
upstream prematurely closed connection→ 后端进程已启动，但响应发一半就崩了（比如 OOM 被杀、线程池满、PHP-FPM 子进程耗尽） - 出现
no live upstreams→ upstream 里所有节点都被 Nginx 标记为不可用（常因max_fails触发，但节点实际还活着）
在 Nginx 服务器上直连后端，绕过代理验证
登录运行 Nginx 的机器，执行：
curl -I http://127.0.0.1:8080/health
替换成你后端的真实端口和健康检查路径。注意：
立即学习“前端免费学习笔记（深入）”；
- 必须用
127.0.0.1或localhost，避免走网络栈和防火墙 - 如果返回
Connection refused或超时 → 后端没起来，或监听地址配置错误 - 如果返回
200但耗时 >5 秒 → 后端负载高或存在阻塞逻辑 - 如果返回
500/404/400→ 链路通畅，问题不在连接层，而在业务响应内容或超时设置
检查后端服务本身的状态和资源
不要只看 systemctl status xxx 显示 active，还要确认：
-
ss -tlnp | grep :端口号→ 是否真有进程绑定该端口，且监听地址是0.0.0.0或对应 IP -
free -h和top→ 内存是否被吃光，有没有进程被 OOM killer 杀掉（查dmesg -T | grep -i "killed process"） -
journalctl -u your-service --since "2 hours ago"→ 查后端服务自己的启动失败原因，比如数据库连不上、配置文件缺失、类加载异常
区分 502 和 504 很重要
- 502 = Nginx 收到了上游的响应，但格式非法（如缺少状态行、头太大、连接提前关闭）
-
504 = Nginx 等了很久，上游根本没给任何响应（纯超时）
如果 error.log 里反复出现upstream timed out，优先调大proxy_read_timeout；如果全是prematurely closed，重点查后端崩溃日志和资源瓶颈。
不复杂但容易忽略
