Nginx 反向代理 502 频发：如何区分上游超时、连接池耗尽与健康检查误判

一次 502 集中爆发时，最容易犯的错误是把它直接等同于“后端宕机”，然后立刻重启服务或统一调大超时。这样偶尔能让告警暂时消失，却常常错过真正的故障层级：后端进程可能仍在运行，只是监听端口拒绝连接；服务可能能建立连接，却在处理过程中卡住；也可能是健康检查过于敏感，把仍可工作的节点提前摘除了。

先不要急着改配置。把排查目标限定为一件事：在十分钟内判断请求到底失败在“连不上上游”“等上游太久”“上游中途断开”，还是“可用节点被错误地判成不可用”。

先把 502 按失败阶段拆开

Nginx 返回 502，表示它作为代理没能从上游获得可用响应。这个结果并不说明后端机器一定不可达，更不说明后端进程一定已经退出。真正有判断价值的是错误日志中的上游报错类型，以及访问日志中与上游相关的地址、返回状态、连接耗时和响应耗时等字段。

排查时先固定一小段故障时间窗口，将同一类请求的 502 聚集起来看。不要只盯着最终状态码；要把“请求被转发给谁、连接用了多久、上游何时返回或中断”连成一条线。通常，错误信息会落入下面三类。

连接被拒：优先怀疑监听与容量，而不是超时

如果日志表现为连接上游时被拒绝，说明 Nginx 已经找到了目标地址，却无法完成 TCP 连接。这时请求通常还没有进入业务处理阶段，调大 proxy_read_timeout 基本没有帮助。

优先检查上游服务是否仍在监听预期端口，以及运行进程是否存活。但“进程活着”还不够：服务可能因为文件描述符、连接数、线程池或内部连接池达到上限，而无法继续接收新连接。对于多实例上游，还应比较各节点的报错分布：如果只有个别节点持续被拒绝，问题更像单节点容量、端口监听或发布异常；如果所有节点在流量高峰同时出现拒绝，则应转向整体接入容量和并发控制。

这里的连接池要分两层理解。Nginx 到上游的 keepalive 复用连接，是代理侧连接复用；上游应用到数据库、缓存或下游服务的连接池，则是应用内部资源。两者耗尽都可能最终表现为 502，但日志信号不同。前者更常见于新连接建立阶段异常或连接复用策略不匹配，后者则可能表现为连接已建立、请求迟迟得不到响应。

读超时：连接成功，不代表请求处理成功

出现上游读超时时，Nginx 已经连上后端，并在等待响应数据。故障重点应转向后端处理链路：应用是否卡在慢查询、锁等待、远程依赖调用、队列积压或资源争用上。

此时需要把 proxy_read_timeout 与后端实际处理时长放在一起看。若业务的正常长请求确实需要更久，超时时间短于合理处理窗口，会造成误杀；但如果平时请求很快，只有异常时处理时间突然拉长，单纯增大超时只会让连接占用得更久，使等待请求继续堆积，最后把局部慢请求放大为整体拥塞。

一个实用判断是：先确认超时请求是否集中在特定接口、特定上游节点或特定时间段。集中在接口上，优先查业务依赖和执行路径；集中在节点上，优先查节点资源和实例状态；集中在流量尖峰，则要同时评估后端并发能力与代理复用连接的配置是否匹配。

上游提前关闭连接：重点看服务稳定性与协议边界

“上游提前关闭连接”意味着连接已经建立，但 Nginx 尚未拿到完整的有效响应，上游就主动或被动断开了连接。这类问题常被误判为单纯超时，实际上更接近服务侧的异常退出、进程重启、请求处理崩溃，或代理与上游之间的连接复用状态不一致。

如果报错紧贴发布、重启或扩缩容发生，先检查实例是否在请求处理中被摘除或终止。若没有明显变更，则应观察问题是否只出现在复用连接上：连接空闲时间、后端关闭策略和 Nginx keepalive 复用节奏不协调时，代理可能复用到一条已被后端关闭的连接。此时盲目提高读超时同样无效，因为请求不是“读得慢”，而是连接已经失效。

十分钟排查顺序：先定位层级，再决定改哪里

现场处置最怕多人同时改超时、扩容、摘节点，最后无法判断哪项动作真正生效。建议按下面顺序推进，每一步只回答一个问题。

1. 确定失败类型和影响范围。 从 Nginx 错误日志中筛出故障窗口内的上游错误，按连接被拒、读超时、提前关闭连接分别计数；同时在访问日志中核对上游地址、上游状态以及连接和响应耗时。先确认是单一错误主导，还是多个错误同时出现。

1. 判断故障是在连接前、处理时还是响应中断时发生。 连接被拒先查监听、实例存活和接入容量；读超时先查后端处理耗时与依赖阻塞；提前关闭连接先查进程重启、异常退出和连接复用状态。不要让最终的 502 覆盖了这些差异。

1. 把超时配置与实际处理时长对齐。 核对 proxy_connect_timeout 是否给了建立连接的合理窗口，proxy_read_timeout 是否覆盖正常请求的响应时间。这里的“合理”不是一味取大，而是要覆盖正常波动、又能及时切断明显异常的等待。若超时请求的处理时长持续增长，应先找增长原因。

1. 核对 keepalive 连接数与并发关系。 观察 Nginx 到各上游节点的活跃连接与请求并发是否失衡。keepalive 数量过小，可能导致高峰期频繁新建连接，放大后端接受连接的压力；设置过大或连接长期被慢请求占住，也可能让连接资源分配不均。重点不是追求某个固定数值，而是让每个节点可复用的连接能力、节点数和真实并发相匹配。

1. 验证健康检查是否过于激进。 如果大量节点在短时间内被标为不可用，剩余节点会承受突增流量，继而出现连接被拒或读超时，形成连锁反应。检查健康检查间隔、失败阈值和恢复条件，确认短暂抖动是否会导致节点被快速摘除，也确认节点恢复后是否能及时重新加入流量。

1. 只做与故障层级对应的调整。 连接被拒优先处理实例监听、容量和连接接入；读超时优先处理慢请求与下游阻塞，再审视超时窗口；提前关闭连接优先处理服务稳定性、发布退出流程和连接复用一致性；健康检查误判则调整探测策略，避免把短暂波动扩大成可用节点不足。

为什么健康检查会让 502 看起来像后端故障

健康检查的目标是避免把流量继续送往异常节点，但它本身也是一种判断机制。检查间隔过短、失败阈值过低，或者检查请求比真实业务更容易失败时，短暂的网络抖动、瞬时负载尖峰都可能被放大为“节点不可用”。

节点被集中摘除后，流量会涌向剩余少数节点。此时即使原本只有少量实例短暂波动，最终也可能演变为其余节点连接被拒、处理排队和读超时。日志表面上看到的是多个上游 502，根因却是健康检查策略让集群失去了缓冲空间。

验证方法并不复杂：将节点被摘除的时间，与 502 开始时间、剩余节点负载变化和上游错误类型对齐。如果“先有一批节点被摘除，后有剩余节点超时或拒绝连接”，就应把健康检查纳入主因排查，而不是只对仍在线的节点扩容。

不要用“大超时”替代故障修复

调大 proxy_connect_timeout 或 proxy_read_timeout 看似能减少 502，实际可能只是把失败延后。连接建立不了时，更长的连接超时会让更多请求停留在等待队列；后端响应变慢时，更长的读超时会让代理工作进程和上游连接被慢请求占住。高并发下，这会降低系统腾挪空间，让原本局部的异常更难恢复。

超时配置应该承担边界控制，而不是承担容量补偿或故障掩盖。只有确认后端存在合理的长耗时场景，并且处理链路具备相应并发能力时，才应调整超时窗口。若超时来自依赖阻塞、连接池耗尽或节点误摘，正确方向是恢复链路健康、控制并发和修正探测策略。

下一次 502 集中出现时，先问三个问题：连接是否真正建立、建立后是否等待过久、连接是否被上游提前中断。答案一旦明确，故障层级通常就不再模糊；随后再检查 keepalive 与并发是否匹配、健康检查是否过度敏感，才能避免用一次“调大超时”换来下一轮更难解释的告警。