Nginx 502 Bad Gateway 排查清单：从 upstream 到超时配置
502 常见但不简单。它不是“某个单点报错”，而是 Nginx 和上游服务之间通信异常的结果。排查时如果顺序不对，很容易在日志里兜圈子。
1. 先确认 502 来自哪一层
先看是 CDN 返回 502，还是源站 Nginx 返回 502。响应头和日志来源不一致时，优先从最前面的代理层排查。
- CDN 502：先检查回源健康和源站连接。
- Nginx 502：重点看 upstream 可达性与超时。
2. 最快的四步检查
- 确认 upstream 进程是否存活、端口是否监听。
- 从 Nginx 机器直接 curl upstream，排除网络 ACL。
- 看 `error.log` 中是否有 `connect() failed` / `upstream timed out`。
- 确认最近发布是否改了 upstream 地址、协议或健康检查。
这四步能快速覆盖 70% 以上的 502 场景。
3. 常见触发类型与对应处理
- 连接失败：应用没起来、端口错、容器未就绪。
- 读超时：上游慢查询、线程池耗尽、下游依赖阻塞。
- 响应头异常：header 过大、格式非法、协议不匹配。
- 发布窗口抖动：滚动发布瞬间实例不足或探针过严。
4. 超时和缓冲参数要成组调整
只改 `proxy_read_timeout` 通常不够。若上游响应体较大，还要检查：
- `proxy_connect_timeout` / `proxy_send_timeout` / `proxy_read_timeout`
- `proxy_buffers` / `proxy_buffer_size`
- `client_max_body_size` 与上游限制是否一致
参数要结合真实请求形态评估，避免“把超时调大掩盖慢请求”。
5. 线上应急建议
- 优先回滚最近变更，恢复可用性。
- 降低流量入口（限流、熔断、降级静态页）。
- 保留故障窗口日志和配置快照，避免事后无法复盘。
502 的目标不是“消失”，而是“在高峰也可预测、可恢复”。
把 Nginx、上游应用和发布系统串成一条排查链，502 就不会再是随机事故。