半夜告警响个不停，打开网站一片 502，监控全红。502状态码的意思很明确：网关或代理（通常是 nginx）把请求转给后端，后端回了个无效响应，或者压根没回。

先分清 502、503、504

502 是后端挂了或返回错误，504 是后端迟迟不响应超时，503 是服务主动拒绝，多半是过载或维护中。三个经常一起出现，含义不同，排查方向也不同。

按这个顺序排查

  • 先看 nginx 的 error log，里面一般写明 connect failed 还是 upstream timed out，前者连不上，后者是太慢。
  • 查后端进程在不在：ps 或 systemctl status 看 php-fpm、node、tomcat 这类服务，很多 502 就是后端进程崩了没拉起来。
  • 绕过 nginx 直接测：curl 后端本机端口，通就是 nginx 配置的问题，不通就守着后端查。
  • 看资源：内存耗尽进程被 OOM 杀掉是 502 的经典原因，dmesg 里能翻到记录，顺便看下 CPU 打没打满。

nginx 侧能调的参数

error log 显示超时类问题时，看看 proxy_read_timeout 是不是设得太短，后端处理慢就适当加长；上游偶尔慢一口就断，也可以配重试。这些是缓解，慢的根源还在后端代码和资源上。

常见的几个根因

后端代码抛异常直接崩、内存不够被系统杀、发版重启那一两分钟请求打进来、上游地址或端口配错，还有并发一上来连接池耗尽的，日常的 502 基本都落在这几类里。

提前准备比事后救火值钱

  • error log 的级别和保留时间调好，出事时才有的看。
  • 后端加健康检查，异常时自动拉起或摘流量。
  • 发版选低峰期，配合优雅重启，能避开大部分发布窗口的 502。

临时恢复可以重启后端服务，但必须找到根因再定论，不然十分钟后又 502，等于没修。告警能少一大半的，往往就是上面这几件提前准备的事。