## 症状现象
网站大部分时间正常，隔一阵子批量报 502，几秒到几十秒后自愈。ps 查后端进程一直活着，重启大法也没用——重启完过几个小时照样犯。间歇性故障比持续故障更磨人：现场难抓，用户截图的时间点机器上什么都没留下。方向先定住：502 说明 Nginx 到后端这一段断了，进程活着而响应超时，问题在"后端忙不过来"的几种形态。
## 三层原因与定位
第一层是慢查询拖累：后端每个请求都要等数据库，慢 SQL 一堆积，工作进程全部阻塞在等待上，队列打满，Nginx 等不到响应超时断开。特征：502 时段与数据库慢日志时间吻合。开启慢查询日志对比时间线，抓到就治理索引与查询。
第二层是进程池打满：PHP-FPM 的 pm.max_children 用尽，新请求排不上队。特征：502 时段 php-fpm 状态页显示全部 worker 忙、内存同时偏高。处理方向是分析每个 worker 的平均内存，算出合理池大小，配合内存升级或代码瘦身。
第三层是超时链不一致：Nginx 的 proxy_read_timeout 比后端实际处理时间短，慢请求全部被掐断表现成 502。特征：报错时间点固定在请求发出后的某个秒数。对齐超时配置即可缓解，但真正的解法是让慢接口异步化，而不是无限拉长超时。
## 日志采样定位法
间歇性问题靠等是低效的，主动采样：Nginx 日志开启请求耗时与上游耗时字段，记录一段时间的 502 样本，按时间、URL、上游耗时三个维度聚类。集中在个别 URL，是慢接口；均匀分布，是容量问题；固定整点，是定时任务撞峰。三个聚类结果对应三种修复，日志会说话。
## 预防建议
后端健康状态要可观测：进程池使用率、队列长度、请求耗时分位数都暴露出来，502 只是结果，指标先行。容量上给后端留三成余量，大促或推广前压测。顺云控制台的 CPU 与带宽曲线配合应用日志，间歇性问题的复现窗口越缩越短，最终在它再犯之前把根因修掉。