502 不一定是后端崩了：反向代理报错的排查顺序

看到浏览器里躺着个 502 Bad Gateway，很多人第一反应是后端挂了。其实 502 的字面意思是"网关拿到了一个无效的上游响应"——问题往往在网关和上游之间这段链路上。我常用的排查顺序是这样的：

第一步：看网关日志的 upstream_status
Nginx 的 $upstream_status 和 $upstream_response_time 是关键。如果 upstream_status 是空的，说明网关根本没连上上游（连接被拒绝、超时、DNS 解析失败），排查方向是网络层；如果有状态码但和业务预期不符，方向是上游应用层。先看日志再动手，能省掉一半瞎猜。

第二步：从网关机器直接 curl 上游
绕开网关，直接在网关所在机器上 curl -v 上游地址。这一步能快速区分是"上游服务本身有问题"还是"网关和上游之间的网络有问题"。比如容器场景里经常遇到的坑：网关容器重启后 IP 变化，但 upstream 写死了旧 IP，curl 直接连会立刻暴露问题。

第三步：查三个经典配置坑

1. proxy_pass 后面斜杠的语义区别：proxy_pass http://backend/; 和 proxy_pass http://backend; 拼接路径的方式完全不同，写错一个斜杠就会 502 或 404。
2. 超时参数：上游接口变慢、但网关 proxy_read_timeout 还是默认 60 秒，慢接口会被网关主动掐断，表现为 502。看 $upstream_response_time 接近超时阈值就是信号。
3. upstream 健康检查缺失：节点挂了网关还继续转发，短时间出现零散 502。加个主动健康检查，或者至少确认负载均衡的失败重试配置生效。

第四步：看资源与连接数
上游服务"看着活着"但连不上，常是因为连接打满了：netstat -s 看 ListenOverflows、看应用线程池/连接池是否耗尽、看网关到上游的 keepalive 配置。这种 502 往往是偶发的，压测流量一上来就复现。

一句话总结
502 的排查顺序应该是：日志定位层级（网络层还是应用层）→ 绕开网关直连验证 → 配置坑 → 资源连接数。从外向内，一步一证据，别一上来就重启后端。