Nginx 偶发 502 不是玄学：后端过载与超时的排查线

网站平时好好的，高峰期或运行几天后突然冒出几波 502，刷新又好了——这种「偶发」最磨人：盯着的时候不出现，出现的时候没盯着。偶发 502 的本质几乎只有一句话：Nginx 找后端要响应，后端没在规定时间内给出像样的答复。所以排查的主线就两条：后端为什么慢，Nginx 为什么不肯等。

先抓 error_log，别靠猜。 偶发 502 的第一现场全在 Nginx 的 error_log 里：upstream prematurely closed connection 是后端进程中途挂了（OOM 被杀、进程崩溃）；connect() failed 是后端监听端口没起或积压满了；upstream timed out 是后端活着但太慢，超过了 proxy_read_timeout。三种字样对应三条完全不同的路，先 grep 出 502 时间点附近的行，方向立刻清晰。

后端慢的三类根因。 一是资源耗尽：内存不足被 OOM 杀掉（dmesg 里能翻到记录），CPU 打满导致请求排队，数据库慢查询把应用进程全占住——后端应用日志和系统监控对一下 502 的时间点，基本都能对上某次资源尖峰。二是连接数不够：应用的 worker/线程池太小，高峰期请求在应用门口就排炸了；数据库连接池同理。三是长任务超时：导出报表、大文件处理这类慢接口，把默认超时吃穿了，表现为「特定操作必现 502」。

Nginx 侧的参数是缓释不是根治。 proxy_read_timeout/proxy_send_timeout 调大、upstream 配置里加 keepalive 与合理的 max_fails，能压住「慢但活着」的后端造成的误杀；但把超时从 60 秒改到 600 秒来掩盖慢查询，只是把 502 换成用户白屏。真正的根治永远在后端：慢查询加索引、扩连接池、把长任务改成异步队列，Nginx 的参数回到合理区间。

偶发 502 的治理要以监控为底：给 upstream 的响应时间和 5xx 率配上告警，趋势比日志更早开口。网站与应用架构的性能体检，贵州诚鑫致达科技提供上门诊断服务，详情见官网 cxzd.cc。

企业存储选型参考｜贵州诚鑫致达

做机架式部署与数据中心扩容，群晖机型参考：RS2423RP+ · RS1221+ · RS822+。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。

服务区域｜贵州诚鑫致达

贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。云南昆明企业 NAS 存储方案与备份容灾，支持远程与上门服务。