故障排查：如何通过错误日志定位 "502 Bad Gateway" 的真实根因

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 是定位根因的“第一把钥匙”： 值为 502 ：后端自己返回了 502，比如 Nginx 或 Spring Gateway 配置错误、上游网关也挂了——要顺藤摸瓜查它背后的日志 值为 504、500、404 等其他状态码 ：说明后端返回了别的码，Nginx/CLB 只是透传或做了转换——按这个真实码去查后端服务日志（如应用 log、Nginx upstream 日志、数据库慢查询） 值为 - 或空 ：代理压根没收到任何响应，属于“零响应”。重点排查： ✓ 后端进程是否存活、端口是否监听（ ） ✓ 安全组/防火墙是否允许 CLB 或 Nginx 所在 IP 访问后端端口 ✓ 后端服务器 backlog 是否打满（ ） 验证后端可达性与响应能力 别只信 ping，要模拟代理行为做真实验证： 从 Nginx 或 CLB 所在机器，用 ，观察是否返回 200、响应头是否完整、body 是否为空 检查后端服务自身日志，尤其是报错前后的堆栈（如 Java 的 Exception、Python 的 Traceback） 确认后端资源水位： ✓ CPU 使用率是否持续 95%+（ ） ✓ 内存是否 OOM 被 kill（ ） ✓ 连接数是否打满（如 MySQL 的 ） 留意容易被忽略的配置细节 有些 502 并非服务宕机，而是配置“卡住”了请求： Header 太大 ：Nginx 默认 ，若后端返回 header 超过该值（如带长 Cookie 或 JWT），会直接 502。可调大： 超时设置过短 ：后端处理需 8 秒，但 Nginx 设了 → 触发 502。建议设为后端 P99 响应时间的 1.5 倍 PHP-FPM 子进程不足 ：高并发下所有 php-cgi 进程忙等，新请求排队超时 → 502。检查 和 监控实际使用量