2026-10-30 · 技术
502 是上游返回了无效响应，504 是等上游超时，两者指向的问题完全不同。本文按客户端、CDN、反向代理、应用、数据库这条链路给出排查顺序，帮你十分钟内定位到具体环节。
网站突然报 502 或 504，很多人的第一反应是重启服务，重启后好了，过一会儿又出现。这两个错误码看着像，指向的问题却不一样：502 是网关收到了上游的无效响应，通常意味着后端进程挂了、崩了或者拒绝了连接；504 是网关等上游响应超时，后端还活着，但处理太慢或者根本没处理完。 排查要按链路走，从外到内，一层层排除。 第一步，看错误页面是谁返回的。页面上如果带 CDN 的标识，说明请求在边缘节点就没拿到源站响应；如果是自己配置的错误页，说明请求已经到源站了。这一步能直接砍掉一半的排查范围。 第二步，绕过 CDN 直连源站。用 hosts 绑定源站 IP 访问，如果直连正常、走 CDN 异常，问题在回源链路或节点；如果直连也报错，问题在源站内部。 第三步，看反向代理的错误日志。502 通常伴随 upstream prematurely closed connection 或 connection refused，前者多半是后端进程崩溃或被 OOM 杀掉，后者是后端没在监听端口。504 则多是 upstream timed out，说明请求发出去了但没等到回应。 第四步，看应用进程和慢日志。PHP 看进程池是否被占满、有没有卡在外部请求上；Java 看线程池、GC 日志和 Full GC 频率；Node 看事件循环是否被阻塞。这一层最常见的原因是某个接口调用了没设超时的外部服务，把工作进程全拖住了。 第五步，看数据库。连接池被打满、慢查询堆积、锁等待，都会让应用层表现为超时。这一层的特点是错误只在特定页面出现，而不是全站。 第六步，看资源和带宽。CPU 打满、内存吃紧触发 OOM、带宽跑满导致丢包，也会造成大量 504。如果是整点或固定时间出现，还要怀疑备份、定时任务、日志切割这类瞬时 IO 压力。 最后区分偶发和全站。偶发且集中在某个接口，往应用和数据库查；全站同时出现，优先看带宽、连接数和反向代理本身。 加速IDC 提供云服务器和物理服务器，标配带宽与流量监控，遇到这类问题可以协助定位是资源不足还是链路异常。
