HTTP 502、503、504 错误详解：如何定位服务器和上游服务故障

先把 5xx 当作链路线索

5xx 表示服务器侧某一层没有完成请求，但状态码本身不是根因报告。先记录准确状态码、URL、响应时间、响应头、发生时间，以及结果来自 CDN、反向代理还是源站。快速 502 和缓慢 504 通常对应不同故障链路。

502 Bad Gateway 通常表示网关或反向代理没有从上游拿到有效响应。检查上游地址、端口、协议、Socket、进程状态和响应格式。连接被拒绝、连接重置和响应头无效是不同线索，应结合代理和应用日志判断，不要只靠反复刷新。

503 Service Unavailable 常表示服务停止、过载、维护中，或健康检查、限流策略主动拒绝了流量。检查应用 Worker、发布状态、健康检查、连接池、CPU、内存和磁盘压力。CDN 生成的 503 不一定代表源站本身返回了 503。

504 Gateway Timeout 表示网关等待上游响应超时。要找出具体超时发生在哪一跳：CDN 到代理、代理到 Web Server、Web Server 到 PHP-FPM、应用到数据库，或应用到外部 API。没有测量慢依赖前，不要盲目增加超时时间，否则可能掩盖问题并耗尽 Worker。

先确认 DNS 和预期 IP，再依次检查 CDN 或边缘节点、反向代理、虚拟主机、上游 Socket、应用进程、数据库和外部服务。确认每一层都指向预期的下一层，防火墙也允许连接。只有在获得授权时，才直接测试源站。

保留诊断时间和请求路径，对照 CDN、负载均衡、代理、Web Server、PHP-FPM、应用和数据库在同一时间窗口的日志。重点查找拒绝连接、上游超时、Broken Pipe、Worker 重启、内存被杀、数据库连接池耗尽和发布错误。按日志关联比猜状态码可靠。

检查 CPU、内存、磁盘、文件描述符、进程限制、Worker 数量、队列长度、数据库连接数和重启记录。服务进程可能仍在运行，但已经无法接受更多任务。应先修复瓶颈或故障依赖，再考虑调整并发或代理超时。

修正上游地址、恢复进程或修好依赖后，先测试受影响的那一层，再测试公网 HTTPS。对比状态码、延迟、响应头和日志，保留可回滚配置。不要同时修改 DNS、代理、应用和数据库，否则无法判断哪个改动真正起效。

不要把所有 5xx 都当作 DNS 问题，不要认为某个路径返回 200 就代表整个应用健康，也不要在公开诊断中暴露堆栈、账号或密钥。IIPP 可以展示公开响应证据，但源站日志、内部健康检查和应用指标才是运营者的最终依据。

使用 IIPP 实时工具，检查你正在处理的域名或 IP 地址。