Appearance
生产问题：Nginx 502 怎么排查，先看网关还是先看后端服务
Nginx 502 是非常典型的一类线上问题。
它最容易让人误判的地方在于：
- 表面报错出现在 Nginx
- 但根因往往不一定在 Nginx 本身
很多现场里，大家一看到 502 就会同时怀疑：
- Nginx 配置改坏了
- 网关挂了
- 后端服务挂了
实际上 502 更像一个“上游拿不到正常响应”的统一外显，真正根因可能在网关、应用、容器、线程池、数据库，甚至是发布切换过程本身。
先说结论
排查 502 更实用的顺序通常是：
- 先确认上游服务是否可用
- 再看 Nginx 和上游的连接方式是否匹配
- 再看超时、进程状态和资源耗尽
- 最后再回到网关配置细节
也可以简单记成：
- 先看上游活没活
- 再看上游是不是已经慢死了
- 最后才看 Nginx 自己是不是配错
一、502 通常意味着什么
可以先粗略理解成：
- Nginx 能收到请求
- 但没能从上游拿到一个正常响应
所以第一反应不应该只是改配置，而是先判断：
- 上游到底是不是活着
很多情况下，Nginx 只是第一个把错误暴露出来的环节，不是问题发起点。
二、最常见的几类原因
1. 上游服务根本没起来
比如：
- Java 进程挂了
- 容器重启中
- 端口没监听成功
2. 上游返回异常或连接被拒绝
这类情况本质上更像是：
- Nginx 连不上后端
3. 超时或资源耗尽
比如：
- 后端线程池打满
- 数据库连接卡住
- 接口 RT 飙升
最后 Nginx 只是先把错误暴露出来。
4. 代理配置和服务协议不匹配
这类问题在多环境部署、网关转发或容器迁移时也很常见。
例如：
- 目标端口改了但 upstream 没改
- HTTP/HTTPS、http1/http2 配置不匹配
- Unix socket 和 TCP 目标不一致
- 容器服务发现地址过期
三、一个更实用的排查顺序
第一步：先确认后端服务活没活
重点看：
- 进程是否存在
- 端口是否监听
- 健康检查是否正常
如果后端服务已经不在了，或者 Pod 本身就在重启，Nginx 怎么调都只是表面处理。
第二步：看后端服务是不是“活着但已经很慢”
如果服务没挂，但线程池和连接池都满了，也很容易表现成 502。
这时业务常见的特征是：
- 应用进程还在
- 端口也能连
- 但是请求进去后长时间拿不到响应
第三步：看 Nginx 错误日志
要搞清楚到底是：
- 连接不上
- 连接被拒绝
- 读超时
- 上游提前断开
这是非常关键的一步，因为不同报错方向差别很大：
connect() failed更像连不上upstream timed out更像后端太慢upstream prematurely closed connection更像后端自己断了
第四步：再看配置
包括：
- upstream 配置
- 超时配置
- 代理目标地址
如果是最近发版、迁移、切流后出现的 502，更要把变更记录一起对上。
四、最容易踩的坑
1. 一看到 502 就重启 Nginx
如果根因在后端，重启网关通常只是暂时掩盖现象。
2. 只看 Nginx，不看应用日志
很多 502 的真正根因，其实在应用服务或下游数据库里。
3. 只改超时配置
如果后端已经明显异常，单纯放大超时只会让问题暴露得更晚。
五、一个更现场化的判断顺序
如果线上突然大面积 502，我通常按这个顺序看：
- 先确认是不是所有 upstream 都受影响，还是只有某一组服务有问题。
- 看后端进程、Pod、监听端口、健康检查是否正常。
- 看 Nginx 错误日志属于连接失败、拒绝、超时还是提前断开。
- 看后端应用日志里是否有线程池打满、连接池耗尽、OOM、重启、GC、下游超时。
- 最后再回头审网关配置、代理协议、端口、服务发现和最近变更。
这样更容易分清是网关问题，还是后端服务或其下游的问题。
一句话总结
Nginx 502 排查最重要的不是先改网关参数，而是先分清：
- 后端是不是挂了
- 后端是不是慢了
- 还是网关和上游的连接关系配错了
把“上游存活、上游时延、Nginx 错误日志、最近变更”这几条线一起看，通常比一上来改 timeout 或重启 Nginx 更有效。