线上突然一片 502，用户炸了群，这场面我经历过好几回。

第一次遇到时我是懵的，上来就重启服务，碰运气好了，但根本不知道为啥好。后来踩多了才明白，502 其实把病因说得挺清楚，只是我当时没听懂。

这篇就把 502 的排查思路捋一捋，分有 Nginx 和无 Nginx 两个场景讲，因为这俩排查的落脚点不太一样。

先听懂 502 在说什么

排查之前，得先知道 502 是啥意思，不然全是瞎撞。

502 的全称是 Bad Gateway，翻译过来是“坏的网关”。

关键词是网关。它的意思是：

我（网关/代理）收到了你的请求，想转给后面真正干活的服务，但后面那个服务没能好好回应我。

注意这里有个隐含前提：报 502 的，是那个转发请求的中间层，不是最终的业务服务。

换句话说，502 是中间人在喊“我联系不上后面的人”，而不是业务代码自己抛的错。

打个比方，你去前台办事，前台跑去后面办公室找经办人，结果回来跟你说“里面那位没搭理我”。这个前台就是网关，它转达的就是 502。

搞懂这一点，排查方向立马清晰：别老盯着网关本身，重点去看它后面那个服务到底怎么了。

常见的病根就那么几类：

• 后端服务挂了或者根本没起来
• 后端服务还活着，但太慢，网关等不及超时了
• 后端服务被打满，没有空闲资源处理新请求
• 网关配置错了，指向了一个错误的后端地址

下面分场景，把这几类逐个对号入座。

场景一 有 Nginx

大部分线上架构，Nginx 挡在最前面当反向代理，后面接一个或多个业务服务。这时候报 502 的，就是 Nginx。

排查按这个顺序来，从近到远。

第一步 看 Nginx 错误日志

这是最该先做的，也是最容易被跳过的。

Nginx 的错误日志会直接告诉你它为啥报 502，别自己瞎猜。

# 翻 Nginx 的错误日志，重点看 502 附近的报错
tail -n 100 /var/log/nginx/error.log
​

日志里通常会有很明确的线索，几种典型：

• connect() failed (Connection refused)：Nginx 去连后端，被拒绝了。基本可以断定后端服务没起来，端口上压根没人监听
• upstream timed out：连是连上了，但后端处理太慢，超过 Nginx 设的超时时间，它等不及了
• no live upstreams：配置的后端全都不可用了

看到哪种，方向就定了。这一步能省掉后面一大半的乱猜。

第二步 确认后端到底活没活

日志要是提示连不上后端，那就去后端机器上，亲眼确认服务到底在不在。

# 看业务进程还在不在
ps -ef | grep 你的服务名

# 看后端端口有没有在监听（假设后端跑在 8080）
netstat -tlnp | grep 8080
​

• 进程没了 / 端口没监听：服务挂了或没起来，这就是根因。去看业务服务自己的日志，找它为啥挂——很可能是启动报错、OOM 被系统杀了、或者干脆没部署上
• 进程在、端口也在：那问题可能出在“慢”或者“满”，往下走

第三步 越过 Nginx 直连后端

这招特别好用，能一刀切清是谁的锅。

直接在服务器上，绕开 Nginx，自己去请求后端：

# 直接怼后端端口，看它自己回不回、回得快不快
curl -v http://127.0.0.1:8080/health
​

• 直连很快就正常返回：说明后端没问题，锅在 Nginx（多半是 Nginx 配置里后端地址、端口写错了，或者超时设太短）
• 直连也慢、也报错、也连不上：那就坐实了是后端的问题，跟 Nginx 没关系

这一步把责任范围一下子劈成两半，非常关键。

第四步 顺藤摸后端为啥不行

确认锅在后端后，就去挖它具体咋了：

• 翻业务服务自己的日志，看有没有异常、有没有卡在某个操作上
• 看机器资源，CPU、内存是不是被打满了（top 一眼）
• 看后端有没有卡在下游——比如数据库连接池耗尽、调的第三方接口超时，这些都会让后端“活着但回不了”

场景二 无 Nginx

有时候架构里没有 Nginx，但只要用户还是收到了 502，就说明请求链路上一定还有别的“网关”。502 这个错，必然是某个中间转发层报出来的。

所以无 Nginx 场景，第一件事是找出到底是谁在报这个 502。常见的“隐形网关”有这么几个：

• 云厂商的负载均衡（SLB/ALB/CLB）：很多架构是 SLB 直接挂后端，没有自建 Nginx。这时候 502 是 SLB 报的
• API 网关 / 服务网关：微服务架构里的网关组件（比如 Spring Cloud Gateway 这类）
• CDN：请求先过 CDN，CDN 回源时连不上源站，也会甩个 502

找到是谁报的，排查思路其实和有 Nginx 时一模一样，只是把“看 Nginx 日志”换成“看对应网关的日志/监控”：

第一步 定位报错的网关

顺着请求链路从外往里排：用户 → CDN → 负载均衡 → 网关 → 后端服务。

一层层问“502 是在哪一层冒出来的”。

• 云上的 LB、CDN 一般在控制台有监控面板和访问日志，看那一层的 5xx 统计和后端健康状态
• 自建的 API 网关，就去翻它自己的日志

第二步 查那一层背后的后端健康

跟有 Nginx 的第二步一个道理：找到报错的网关后，去看它指向的后端是不是健康的。

• 云 LB 都有健康检查机制，先看控制台里后端实例是不是被标成了“不健康”。被摘除了，说明后端没通过健康检查，多半是挂了或没起来
• API 网关的话，同样去后端机器上 ps 看进程、netstat 看端口、curl 直连验证

第三步 一样的直连大法

无论中间是啥网关，绕过它直连后端这招永远好使：

# 登到后端机器上，直接请求后端自己，撇开所有中间层
curl -v http://127.0.0.1:8080/health
​

直连正常 → 锅在网关那层（配置、健康检查、超时）；直连也不行 → 锅在后端自己。跟前面完全一致。

提炼一套通用套路

讲了两个场景，其实排查骨架是同一套。不管有没有 Nginx，记住这条主线：

1. 认清 502 = 某个网关连不上后端(先搞清是谁报的)
2. 看那个网关的日志/监控(它会告诉你为啥)
3. 确认后端活没活(ps 进程 / netstat 端口)
4. 绕过网关直连后端(curl 一刀切清责任)
5. 定位到底层(网关配置错? 后端挂了/慢了/满了?)
​

有 Nginx 和无 Nginx，区别只在第 1、2 步“网关是谁、日志在哪”，从第 3 步开始完全通用。

小结

502 不可怕，可怕的是一上来就无脑重启碰运气。

把这几点刻进脑子就不慌：

• 502 是网关在喊“我连不上后端”，第一步是搞清楚谁在报——有 Nginx 就是 Nginx，没有就是 LB/CDN/API 网关
• 先看报错那层的日志，它基本会直说原因（连接被拒 / 超时 / 后端全挂）
• 确认后端进程和端口在不在，再直连后端一刀切清是网关的锅还是后端的锅
• 锅在后端就往下挖：挂了、慢了、满了，还是卡在数据库/下游

排查的核心不是记命令，是理清那条“网关 → 后端”的链路，顺着它一段段往里问。想明白这个，下次再来 502，你就能稳稳当当地查，而不是慌慌张张地重启了。那就把这套顺序记下来备用吧。