一台前置Nginx反代后端业务接口，平时很稳，可一到业务高峰期就隔三差五返回502。点一下刷新又好了，过几分钟再犯。后端起服务没崩、没报错，这502到底哪来的？

一句话看懂

502时有时无、重启即好，往往是Nginx复用了上游已经关闭的连接，或代理超时设置不当——两个坑叠一起，就成了"玄学"故障。

一、现象：502时有时无，服务本身没挂

现场特征很典型：

· 502出现有规律，多在并发上来或空闲一段时间后。

· 重启Nginx后立刻"痊愈"，过一会儿又复发。

· 上游后端日志里几乎查不到对应报错。

同样的请求，有时候通、有时候502——先别怀疑后端，看看Nginx自己。

二、第一个坑：upstream keepalive 复用了已关闭的连接

当你在 upstream 里配了 keepalive，Nginx会复用与上游的TCP长连接。但如果上游（如某些Java/Tomcat、PHP-FPM、LB）在空闲超时后主动关闭了这条连接，Nginx却不知道，仍把这条"死连接"拿去发请求——于是直接upstream prematurely closed connection，返回502。

上游已把连接掐断，Nginx却还拿它复用发请求，一撞一个502。

三、第二个坑：代理超时设置不当

即使连接没断，后端响应稍慢，也会触发Nginx的代理超时。常见三个参数：

proxy_connect_timeout 10s;   # 与上游建立连接超时 proxy_read_timeout    60s;   # 读上游响应的超时 proxy_send_timeout    60s;   # 向上游发送请求的超时

若接口本身耗时接近超时值，波动一下就可能踩线报502。

把连接、读、写三档超时按业务实际耗时调开，别再让"慢一点点"触发502。

四、定位与修复

按这套流程走一遍，基本能对症：

1看错误日志error.log 里搜 502，定位是"prematurely closed"还是"timeout"。 2查连接复用配了keepalive且上游会关空闲连接的，调低 keepalive 数量并核对上游空闲超时。 3调代理超时按业务P99耗时，把 connect/read/send 三档超时留足余量。 4验证稳定性改完 reload，压测或观察一段时间，确认502不再复现。