网站批量报502别急着重启：从后端进程数到代理超时的整套排障

502 是运维接到最多的告警之一。很多第一反应是重启服务，重启确实常常"治好"它——也因此掩盖了真凶，过两天复发。要治本，得先理解 502 的本质，再按链路一层层排。这篇文章把散落的排障点串成一条完整的处置线。

先懂语义：502 是"网关活着，后端死了"

浏览器看到 502 Bad Gateway，含义精确：前面的 nginx 还在正常接客，但它去找后面的应用服务（PHP-FPM、Tomcat、Node 进程、上游 API）时，要么连不上，要么拿到无效响应。所以排障的方向从一开始就定了——问题在后端与代理之间，不在 nginx 本身。记住这句话，就不会把时间浪费在反复 reload nginx 上。

第一嫌疑人：后端进程撑爆了

批量 502 的头号真凶是后端进程池耗尽。以 PHP 站点为例，php-fpm 的进程数有上限（pm.max_children），并发一超，新请求排队超时，nginx 端就表现为成片 502。排查顺序：先看错误日志里有没有 “connect() failed” 或 “no live upstreams”；再看进程数是否顶到上限、内存是否吃满。处置是两条腿：短期把进程池上限和内存配比调到位（每个进程吃多少内存，乘一下就知道上限该多大）；长期做扩容评估——反复顶上限就说明该加机器或加节点了。进程意外挂掉的还要配自动拉起，避免单次崩溃演变成持续 502。

第二嫌疑人：反向代理配置错位

nginx 做反向代理时，proxy_pass 指向的后端地址或端口写错、后端服务没监听对应端口、防火墙拦了代理到后端的流量——三种情况症状相同：nginx 健康但转不出去。排查用最朴素的方法：在 nginx 所在机器上直接 curl 后端地址端口，通不通一目了然。通了还 502，就看 nginx 的 error_log，上游拒绝的真实原因都记在里面，比浏览器报错信息量大多了。

第三嫌疑人：多级代理链与超时

架构复杂后，客户端到应用中间隔了好几跳代理，502 可能出在任何一跳。逐跳定位法：沿链路从外向内逐层看各跳日志，锁定 502 产生的那一跳。链路里特别要盯超时参数——后端响应慢（慢查询、外部接口卡顿），代理等不到响应主动断开，也会回 502。proxy_connect_timeout 这类参数的调整能缓解，但先要查后端为什么慢：超时是症状，慢才是病。

变种场景：上了证书之后突然 502

HTTPS 部署后突现 502，多半是协议断层：证书配在 nginx 上，nginx 到后端仍走 HTTP，配置里却按 HTTPS 转发，协议对不上自然握手失败；反向代理要按后端实际协议转发，混配时端口和协议两项都要核对。这类问题集中在变更后爆发，回看变更内容往往一击即中。

处置 SOP：按这个顺序走

把上面的内容压成一张执行单：一看告警面（个别 502 还是批量）；二看 nginx error_log 定位上游错误；三测代理到后端的连通；四查后端进程池与资源水位；五查链路超时与后端慢因；六复盘近期变更。按单走完，绝大多数 502 当次能定位，反复发作的也能从历史里找到规律。

502 排障是后端运维的基本功，真正值钱的是把每次处置沉淀成自己环境的检查清单——下次告警响起，您手里有单，心里有谱。

网站运维、服务器托管或业务系统上云后的稳定性保障，贵州诚鑫致达科技提供驻场与远程运维服务，欢迎留言或私信咨询。

（信息来源：本文排障路径综合自公开技术社区高频问答的共性方法，命令与参数以所用软件官方文档为准）

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

做核心业务 SAN 存储与高可靠应用，群晖机型参考：UC3400 · UC3200 · SA3600。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。