502错误根因是后端不可用或响应无效，需优先查Nginx error.log中“Connection refused”“upstream prematurely closed connection”等线索，再验证后端服务状态、端口监听、进程存活及OOM痕迹。
遇到 Nginx 返回 502 错误，首先要确认：这不是 Nginx 自身的问题，而是它在尝试把请求转给后端时，“人没找到”或“人找到了但答不上话”。后端崩溃或端口未监听，属于最基础也最常发生的两类根因。排查要快、准、稳，从日志切入，逐层验证。
看 Nginx error.log 中的错误类型
Nginx 的错误日志会直接告诉你问题出在哪一环：
- 出现 “Connection refused”（错误码 111）：说明 Nginx 尝试 connect 后端端口时被拒绝——后端根本没在监听该地址+端口，大概率服务没启动、端口配错、或防火墙拦了。
- 出现 “upstream prematurely closed connection”：说明连接建成功了，但后端在发响应头前就断开了——进程可能刚启动就崩溃、OOM 被杀、或处理中异常退出。
- 出现 “No route to host” 或 “Connection timed out”（113/110）：指向网络层问题，比如后端机器宕机、IP 不通、容器网络异常等，需先排除连通性。
查后端服务是否存活并监听端口
别只看 systemctl status 显示 “active”，要实锤它真在听请求：
- 用
systemctl status your-app.service确认服务状态，若显示inactive (dead)或failed，立即查日志：journalctl -u your-app.service -n 50。 - 检查端口监听：
ss -tunlp | grep ':8000'（把 8000 换成你配置的后端端口）。如果无输出，说明服务没监听，或监听了但绑定了 127.0.0.1 而 Nginx 从其他 IP 访问（注意 bind 地址是否为 0.0.0.0）。 - 本地测试连通性：
curl -v http://127.0.0.1:8000/health（假设有健康接口），或telnet 127.0.0.1 8000。能通说明服务活着且端口开着；不通则聚焦服务启动逻辑或权限问题。
确认后端进程是否存在且稳定
有时候服务“看似运行”，实则已僵死或反复重启：
- 运行
ps aux | grep your-app-name，看主进程 PID 是否存在、运行时间是否合理（比如刚启动几分钟就换 PID，可能是崩溃后被 systemd 拉起）。 - 检查是否有 OOM 痕迹：
dmesg -T | grep -i "killed process"。若看到类似Killed process 12345 (node) ... anon-rss:6.2GB，说明内存爆了被系统干掉，不是配置或网络问题。 - 观察资源水位：
free -h看内存是否耗尽，df -h看磁盘是否写满（尤其日志盘满会导致服务无法写日志而卡死）。
核对 Nginx 配置中的 upstream 地址和协议
一个字母写错就会导致“找不到人”：
- 检查
proxy_pass指向的地址是否拼写正确，比如http://127.0.0.1:8000写成http://127.0.0.1:800（少个 0）。 - 确认协议一致：后端是 HTTP 就别配成 HTTPS；用 Unix Socket（如
unix:/var/run/app.sock）时，检查路径是否存在、权限是否允许 Nginx 用户读写（ls -l /var/run/app.sock）。 - 运行
nginx -t验证语法，再nginx -s reload生效，避免旧配置残留干扰。
