502和504：一个说后端挂了，一个说后端太慢

先记一句口诀：502是「后端挂了或连不上」，504是「后端太慢、等超时了」——同样是网关报错，方向完全不同，混着查只会越查越乱。网站突然满屏502、用户进不来订单下不了的时候，按这篇的顺序走，能少走弯路。网关错误的排查最忌全域乱查，分层定位是唯一正路。

第一步：先分清是哪兄弟两个码的分工：502 Bad Gateway，网关收到了后端的无效响应——后端进程挂了、崩溃了、或者返回了无法解析的报文；504 Gateway Timeout，网关把请求转给了后端，但后端在超时时间内没返回结果——进程还活着，只是太慢。一句话区分：502查「死没死」，504查「慢在哪」。翻Nginx错误日志，一眼就能确认是哪种情况——先分类再动手，能省一半时间。

第二步：502的三个经典病因病因一，后端进程崩了：PHP-CGI或PHP-FPM的进程全部被卡住时，新请求没人处理，直接502——查进程数和状态，看是不是被长任务占满。病因二，后端返回了坏报文：错误日志里出现「upstream sent invalid header」这类字样，说明应用在响应里混入了非法数据——重点查应用有没有输出多余内容，这条线索很多人不知道。病因三，资源耗尽：内存打满导致进程被杀、连接数到上限——真实现场里，大型考试系统在早八点、期末这种流量高峰集中宕机报502的事，年年都在发生：突发并发超过了承载能力。预估容量时按峰值的三倍留余量，是挨过打的人总结的规矩。

第三步：504的排查链条504的方向是慢，排查沿着链路走：先看Nginx的超时配置——proxy_read_timeout、fastcgi_read_timeout这些值是否小于后端正常处理时间，配置太紧会冤杀慢而正常的请求；再看后端慢在哪——对照访问日志里的upstream_response_time和应用自身的慢请求日志，定位到具体接口；最后对症：是数据库慢查询就查慢日志，是外部依赖超时就加超时和降级，是代码死循环就修代码。504的根因十有八九在后端应用里，Nginx只是替它报了丧。顺着响应时间链路查，真凶总在链路最长的那一段。

第四步：紧急止血与防复发正在报警时的止血顺序：先看后端进程状态，挂了先拉起；再看重启后是否复现，复现说明有慢性病；同时保留现场——错误日志、进程状态、资源占用截图，都是后面定位的证据。防复发三件套：监控告警覆盖502/504错误率，异常第一时间知道而不是等用户骂；上线前压测，知道自己的系统极限在哪，别让流量峰值第一次出现在生产环境；给后端配健康检查和自动拉起，进程挂了自动恢复，人只处理真正的根因。监控、压测、自愈三件套配齐，网关错误才从事故降级为告警。

最后一张速查卡502：后端死了/连不上/报文坏了——查进程、查资源、查invalid header；504：后端活着但超时——查超时配置、查慢接口、查依赖。先分兄弟，再动手术，网关错误从来不可怕，可怕的是把两个码当成一回事。这张卡贴在工位上，下次报警先深呼吸再看码。