502表示nginx收到后端无效响应，504表示等待响应超时；需依序检查nginx错误日志、node服务状态、直连测试、资源配置及proxy_pass/超时/keepalive等配置匹配性。
遇到 Nginx 代理 Node.js 应用时返回 502 或 504，本质是通信链路出了问题，但两类错误指向完全不同的环节：502 是“收到了坏响应”，504 是“根本没等到响应”。排查不能靠猜，得顺着请求路径一层层验证。
先看日志，定位第一现场
Nginx 错误日志（通常是 /var/log/nginx/error.log）里那几行字，就是最直接的线索：
- upstream prematurely closed connection → 典型 502，Node 进程提前断开了连接，可能是崩溃、OOM 被杀、或未正确处理长连接
- upstream timed out (110: Connection timed out) → 明确指向 504，Nginx 等待上游响应超时
- Connection refused → Node 服务根本没在监听，端口错、进程没启、防火墙挡了
- Permission denied while connecting to upstream → SELinux 或文件权限限制了 Nginx 访问 socket 文件（如果用 Unix domain socket）
确认 Node 服务真实状态
别只看 ps aux | grep node，要验证它是否真在工作：
- 用
curl -v http://127.0.0.1:3000/health直连 Node 端口（绕过 Nginx），看能否收到有效 HTTP 响应（注意状态码和 header 格式） - 检查 Node 进程资源：内存是否接近上限？
top或htop观察 RES 和 %MEM；CPU 是否持续 100%？可能卡在同步阻塞或死循环 - 查 Node 日志（如 pm2 logs、systemd journalctl -u my-node-app），找 unhandledRejection、worker timeout、数据库连接池耗尽等报错
- 如果是 cluster 模式，确认 master 进程存活且 worker 没大量退出；用
pm2 show或systemctl status看服务健康状态
核对 Nginx 与 Node 的关键配置匹配
很多 502 其实源于配置不一致，尤其在超时和连接管理上：
-
proxy_pass 地址必须准确：写成
http://127.0.0.1:3000就别漏掉http://；用域名要确保 DNS 可解析；用 socket 要确认路径和权限 -
超时时间需协同设置：Node 的
server.setTimeout()（默认 0，即不限制）应 ≥ Nginx 的proxy_read_timeout；否则 Node 主动关连接，Nginx 就报 502 -
连接复用要打开：在
upstream块中加keepalive 32;，并在location中配proxy_http_version 1.1;和proxy_set_header Connection '';，避免频繁建连压垮 Node -
body 大小要放开：Node 接收大文件上传时，Nginx 需设
client_max_body_size 100M;，否则 413 请求体过大可能被截断引发后续异常
多级代理场景下特别注意超时传递
如果请求经过不止一层 Nginx（比如 CDN → 边缘 Nginx → 应用 Nginx → Node），各层 timeout 必须形成梯度：
- 边缘层（离用户近）可设较短 timeout（如 15s），快速失败，避免用户长时间等待
- 应用层 Nginx 的
proxy_read_timeout应略大于 Node 实际最长处理时间（比如 Node 最慢接口 8s，这里设 12s） - Node 自身的超时（如 Express 的
server.timeout）必须比 Nginx 层更大，否则它先断开，Nginx 就收不到完整响应而判为 502 - 所有层都只设自己的 timeout，不依赖上游默认值，避免某层卡在 60 秒，导致整条链路响应不可控
