502 Bad Gateway是Nginx作为反向代理未能从上游获取合法HTTP响应，需从后端可用性、超时设置、代理头与协议配置、缓冲区及资源限制四方面排查，并优先分析Nginx错误日志定位具体原因。
502 Bad Gateway 不是 Nginx 自己挂了，而是它转发请求后，没收到上游服务的合法 HTTP 响应。排查核心就四件事：确认后端真活着、看连接和等待时间够不够、检查代理头和协议配对没、验证缓冲区和资源撑得住。
先盯住 Nginx 错误日志
这是最快定位问题的入口，别跳过：
- 执行 tail -f /var/log/nginx/error.log | grep -i "502\|upstream"，实时观察报错细节
- 常见线索举例：
• "connect() failed (111: Connection refused)" → 后端根本没监听或地址写错
• "upstream timed out (110: Connection timed out)" → 连接建得上，但等响应超时
• "SSL alert number 80" → TLS 握手失败，大概率缺proxy_ssl_server_name on;
直连验证后端是否真实可用
不能只看进程在不在，要测它能不能收发 HTTP 请求：
- 用 curl -v http://127.0.0.1:端口/health（或任意简单路径），看是否返回 200 和有效 body
- 运行 ss -tuln | grep :端口，确认监听的是
0.0.0.0:端口或127.0.0.1:端口，而不是::1:端口（IPv6 localhost）或特定 IP - 容器环境注意：Nginx 容器里写的
127.0.0.1:8080指的是它自己，不是另一个容器；要用容器名或宿主机 IP + 端口映射 - 查后端日志，比如 Tomcat 的
catalina.out、PHP-FPM 的error.log，找崩溃、OOM、拒绝连接等记录
核对关键配置项是否匹配
很多 502 是“配错了”导致的协议级失败：
-
HTTPS 反代必须加：
proxy_ssl_server_name on;，否则 SNI 不传，后端 TLS 握手失败 -
WebSocket 必须三件套：
proxy_http_version 1.1;+proxy_set_header Upgrade $http_upgrade;+proxy_set_header Connection "upgrade"; -
Host 头别乱用：
$host会把客户端 Host 原样转发，若后端依赖固定域名路由（如多租户），应写死为proxy_set_header Host api.example.com; -
proxy_pass 尾部斜杠要小心：
location /api/ { proxy_pass http://backend; }正确透传路径；proxy_pass http://backend/;会剪掉/api/，变成/abc→/abc，易导致 404 或后端路由错乱
调超时、扩缓冲、查资源瓶颈
后端慢、返回大、并发高，Nginx 默认参数容易扛不住：
-
超时参数建议值：
proxy_connect_timeout 60;（建连）、proxy_read_timeout 120;（等响应头+体）、proxy_send_timeout 120;（发请求给后端） -
缓冲区不够常见于大响应头或流式接口：
proxy_buffer_size 16k;+proxy_buffers 8 16k;+proxy_busy_buffers_size 32k; -
检查系统级限制：磁盘空间（
df -h）、inode（df -i）、PHP-FPMpm.max_children是否打满、TomcatacceptCount是否溢出丢请求
