502 Bad Gateway是代理层（如Nginx、CLB）未收到后端有效响应所致，根因需通过代理日志中的upstream_status、upstream_addr、upstream_response_time及error.log错误线索综合定位，而非仅看客户端显示的502。
502 Bad Gateway 不是前端问题，而是代理层（如 Nginx、CLB 或 API 网关）在转发请求时，没收到后端的有效响应。真正原因藏在日志里——关键不是看 客户端看到的 502，而是看代理日志中记录的 upstream_status 或错误线索。
查 Nginx access.log 和 error.log 中的关键字段
打开 Nginx 的 access.log，找对应失败请求行，重点关注：
– status=502（代理返回给用户的码）
– upstream_status=xxx（后端实际返回或未返回的状态）
– upstream_addr（连的是哪台后端）
– upstream_response_time（耗时多少秒，是否超时）
再翻 error.log，搜索关键词：
– "upstream prematurely closed connection" → 后端进程提前断开，常见于 PHP-FPM 崩溃、Node.js 未 catch 异常退出
– "Connection refused" → 后端端口没监听，或服务根本没起来
– "No route to host" → 网络不通，可能是安全组/防火墙拦截，或 CLB 后端用了 100.64.0.0/10 网段但没放行
区分 upstream_status 的三类含义
upstream_status 是定位根因的“第一把钥匙”：
GateCrash Forms
下载
以 CLI 为先的表单构建器，采用 BYOK 理念。通过JSON Schema 生成美观的 HTML 表单，使用您自己的 SMTP 服务器处理提交，存储响应...
- 值为 502：后端自己返回了 502，比如 Nginx 或 Spring Gateway 配置错误、上游网关也挂了——要顺藤摸瓜查它背后的日志
- 值为 504、500、404 等其他状态码：说明后端返回了别的码，Nginx/CLB 只是透传或做了转换——按这个真实码去查后端服务日志（如应用 log、Nginx upstream 日志、数据库慢查询）
- 值为 - 或空：代理压根没收到任何响应，属于“零响应”。重点排查：
✓ 后端进程是否存活、端口是否监听（netstat -tlnp | grep :8080）
✓ 安全组/防火墙是否允许 CLB 或 Nginx 所在 IP 访问后端端口
✓ 后端服务器 backlog 是否打满（netstat -s | grep -i "listen.*drop"）
验证后端可达性与响应能力
别只信 ping，要模拟代理行为做真实验证：
- 从 Nginx 或 CLB 所在机器，用
curl -v http://后端IP:端口/health，观察是否返回 200、响应头是否完整、body 是否为空 - 检查后端服务自身日志，尤其是报错前后的堆栈（如 Java 的 Exception、Python 的 Traceback）
- 确认后端资源水位：
✓ CPU 使用率是否持续 95%+（top）
✓ 内存是否 OOM 被 kill（dmesg -T | grep -i "killed process"）
✓ 连接数是否打满（如 MySQL 的show status like 'Threads_connected'）
留意容易被忽略的配置细节
有些 502 并非服务宕机，而是配置“卡住”了请求：
-
Header 太大：Nginx 默认
proxy_buffer_size 4k，若后端返回 header 超过该值（如带长 Cookie 或 JWT），会直接 502。可调大：proxy_buffer_size 16k; -
超时设置过短：后端处理需 8 秒，但 Nginx 设了
proxy_read_timeout 5;→ 触发 502。建议设为后端 P99 响应时间的 1.5 倍 -
PHP-FPM 子进程不足：高并发下所有 php-cgi 进程忙等，新请求排队超时 → 502。检查
pm.max_children和pm.status_path监控实际使用量
