502错误源于Nginx作为网关无法从上游获取有效响应，排查核心是查error.log定位错误类型，再验证上游服务状态、端口监听、资源占用及超时配置是否合理。
502 错误不是 Nginx 自己挂了，而是它作为“中间人”联系不上后端服务，或收到了后端发来的无效响应。排查核心是顺着 Nginx 的视角，看它连谁、怎么连、等多久、收到什么。
先看 Nginx error.log，锁定具体错误类型
这是第一步，也是最关键的一步。别猜，直接查日志：
- 运行 tail -f /var/log/nginx/error.log 实时观察
- 重点找含 upstream、Connection refused、Connection timed out、reset 的行
- 例如：connect() failed (111: Connection refused) while connecting to upstream → 表明 Nginx 根本连不上后端端口
- 又如：upstream timed out (110: Connection timed out) while reading response header → 表明连上了，但等响应超时，更倾向 504 或配置过短
检查上游服务是否存活且监听正确端口
Nginx 配置里写的 proxy_pass http://127.0.0.1:8000 或 fastcgi_pass 127.0.0.1:9000，后端必须真正在这个地址和端口上听着：
- 用 ss -tlnp | grep :8000（或 netstat -tlnp | grep :8000）确认端口是否被进程监听
- 如果用的是 UNIX socket（如 fastcgi_pass unix:/run/php/php8.1-fpm.sock），检查 socket 文件是否存在、权限是否允许 Nginx 用户（通常是 www-data 或 nginx）读写
- 手动用 curl -v http://127.0.0.1:8000/health 测试上游能否返回正常 HTTP 响应
确认后端服务资源是否充足
服务虽在，但可能已不堪重负：
- PHP-FPM 场景：运行 systemctl status php8.1-fpm 看状态；用 pm.status_path 配置的 status 页面（如 curl http://127.0.0.1/fpm-status）查 active processes 是否接近 max children
- Node.js/Python 应用：用 ps aux | grep node 或 htop 看进程 CPU、内存占用是否爆满
- 通用检查：运行 uptime 和 free -h，确认系统整体负载、内存是否告急
核对关键超时与连接配置是否合理
即使后端正常，参数太小也会触发 502：
- proxy_connect_timeout：Nginx 连接上游的最长时间，建议设为 5–10s
- proxy_read_timeout：Nginx 等待上游响应头的最长时间，若后端有慢查询，需调大（如 60–300s）
- fastcgi_read_timeout：专用于 PHP-FPM，逻辑同上
- 若用了 upstream 块，检查 max_fails 和 fail_timeout，避免健康检查误判导致节点被剔除
