Nginx 反向代理排查三板斧：502、504、证书告警一网打尽

从一次深夜告警说起

凌晨收到告警：官网接口大量 502。打开服务器一看，Nginx 还活着，后端应用也活着，问题出在哪？这类问题几乎每个运维和后端都遇到过。与其每次都靠猜，不如把 Nginx 反代最常见的三类故障总结成一套固定排查动作，遇事先走流程再下结论。

第一板斧：502 Bad Gateway 先看上游

502 的本质是 Nginx 找不到一个"能正常应答"的上游。按顺序确认三件事：一是后端进程是否在监听正确端口（ss -lntp 核对）；二是 Nginx 里 proxy_pass 写的地址和端口是否与实际一致，尤其是容器场景下用 127.0.0.1 会指到容器自己；三是后端是否因内存或线程耗尽假死，curl 直接打后端端口最诚实。三步走完，九成 502 都能定位。

第二板斧：504 Gateway Timeout 查的是慢不是断

504 说明链路是通的，但上游没在规定时间内应答。先分清是全局慢还是个别接口慢：如果是少数慢接口，优先给 proxy_read_timeout 按业务调整，同时把慢接口异步化；如果是全面变慢，大概率是数据库或下游依赖拖住了，去看慢查询和连接池。注意一点：把超时时间调大只是止痛，找到慢的根因才是治病。

第三板斧：证书告警看有效期和链完整性

浏览器提示证书无效，先看两类问题：一是证书过期，用 openssl s_client -connect 域名:443 查有效期，配合 certbot 续期；二是证书链不完整，服务器只发了站点证书没发中间证书，curl 和部分安卓客户端会报错，而桌面浏览器因为缓存了中间证书看起来正常，最容易骗过排查的人。把 fullchain 配对配置，再用线上检测工具验证一遍。

把排查动作固化下来

三板斧的共同思路是：先分清故障层级——是断（502）、是慢（504）、还是不信任（证书），再按固定顺序逐层验证，而不是看到报错就重启碰运气。建议把这三套动作写成团队手册，配合 access_log 里的 upstream_response_time 字段，多数反代问题五分钟内能定位。