502 Bad Gateway本质是Nginx与上游服务“传话失败”，需从错误日志切入，分层排查连接、超时、响应格式、SSL协商、资源瓶颈及配置匹配问题，避免盲目重启。
502 Bad Gateway 不是后端挂了就一定报，而是 Nginx 和上游服务之间“传话失败”——可能连上了但没回话，回了但格式错，或者回了一半断了。排查要从日志出发，分层验证，避免盲目重启。
看 Nginx 错误日志，定位第一线索
错误日志是排查起点，它会明确指出问题类型：
- connect() failed (111: Connection refused) → 后端根本没监听端口，服务未启动或端口配置错误
- upstream timed out (110: Connection timed out) → 网络不通、防火墙拦截、或后端卡死无响应
- recv() failed (104: Connection reset by peer) → 后端进程崩溃、主动断连，或响应体过大被截断
- no live upstreams → upstream 中所有节点都不可用，可能是健康检查全失败
- SSL handshake failed → TLS 协商异常，常见于 SNI 未开启或证书不匹配
确认后端服务真实状态
别只看进程在不在，要看它能不能正常处理请求：
- 用
curl -v http://127.0.0.1:端口/health直连后端，观察是否返回有效 HTTP 响应（含正确状态码、头、body） - 检查后端进程资源：内存是否 OOM 被 kill（
dmesg -T | grep -i "killed process"），CPU 是否 100% 卡死 - 查后端自身日志，看是否有 panic、线程池满、连接拒绝等记录（如 Tomcat 的 catalina.out、Gunicorn 的 error log）
- 如果是 PHP-FPM，检查
pm.max_children是否打满，用php-fpm -tt或systemctl status php-fpm查状态
检查 Nginx 代理配置关键参数
很多 502 是配置和流量不匹配导致的，尤其在并发升高时：
-
超时类：确保
proxy_connect_timeout（建连）、proxy_send_timeout（发请求）、proxy_read_timeout（等响应）三者合理，一般不低于后端平均响应时间的 2–3 倍 -
缓冲区类：响应体大或 header 多时容易触发 502，加这组兜底配置：
proxy_buffer_size 128k;<br>proxy_buffers 4 128k;<br>proxy_busy_buffers_size 256k;<br>proxy_temp_file_write_size 256k;
-
SNI 和 Host 头：若后端是 HTTPS，必须开启
proxy_ssl_server_name on;；Host 头建议显式设置为后端期望值，而非默认$host -
重试策略：禁用对 502 的重试，避免雪崩：
proxy_next_upstream error timeout http_500 http_503;（去掉http_502）
抓网络与系统层异常信号
当日志模糊、现象偶发时，需深入底层：
- 用
ss -tuln | grep :端口确认后端端口确实在 LISTEN，且绑定的是0.0.0.0或127.0.0.1，不是 localhost 或具体 IP 导致 Nginx 连不上 - 检查连接数限制：
cat /proc/sys/net/core/somaxconn（内核连接队列）、ulimit -n（Nginx 进程文件描述符上限） - 查是否有 SYN flood 或连接泄漏：
netstat -s | grep -i "listen overflows\|failed" - 高并发下磁盘满也会间接引发 502（日志写不进、临时文件无法生成），运行
df -h和du -sh /var/log/nginx/
