用户说“网站报网关错误”，日志里却交替出现502、503和504。三者都可能由反向代理、API网关或负载均衡返回，但表达的故障阶段不同；把它们统一归为“后端挂了”，会浪费排查时间。
三个状态码的常见含义
| 状态码 | 典型含义 | 常见证据 |
|---|---|---|
| 502 Bad Gateway | 网关从上游收到无效响应或连接异常 | 连接拒绝、TLS失败、上游重置 |
| 503 Service Unavailable | 服务暂时不可用 | 无健康节点、维护、限流、过载保护 |
| 504 Gateway Timeout | 网关等待上游响应超时 | 连接或读取阶段超过期限 |
具体产品可能在不同条件下选择不同状态码，必须结合响应头、网关日志和配置解释。
先找出是谁生成状态码
CDN、WAF、外层负载均衡、API网关和应用反向代理都可能生成错误页。查看Server、Via、请求ID和各层访问日志，但不要只凭错误页样式绝对判断。最可靠的方法是用统一请求ID和UTC时间串联每一层。
502通常发生了什么
代理连接不上目标端口、上游在完整响应头之前断开、返回不符合HTTP格式的数据，或代理到上游TLS/SNI不匹配，都可能是502。若日志明确写connection refused，继续增加读取超时没有意义，应检查进程监听、地址、健康状态和防火墙。
503是谁在保护谁
应用可以主动返回503，代理在无可用后端、连接队列满或触发熔断时也会返回503。若响应包含合理的Retry-After，客户端可据此延后重试。维护页面、容量限制与依赖熔断应有不同日志标签，便于区分计划事件和事故。
504为何不能只调大超时
504说明网关在规定时间内没有拿到预期响应。真正耗时可能在DNS、建连、TLS、排队、应用计算、数据库或第三方接口。统一把超时从30秒改为300秒，会增加占用连接和内存的请求数量，故障高峰反而更严重。
多层超时如何排列
外层客户端Deadline应覆盖合理业务时长，内层组件要留出返回错误和清理资源的窗口。若外层先超时，内层仍继续计算，就会产生无主请求；若内层过短，则正常慢请求也被提前切断。需要按完整调用链设计，而不是每层独立取默认值。
健康检查通过仍会503
只检查TCP端口的健康探针可能认为节点可用，但应用线程池、数据库连接池或关键依赖已经耗尽。健康检查应反映接收新请求的能力，又不能执行过重查询拖垮系统。就绪与存活检查也要区分。
上游重置与502
上游若发送TCP RST，代理可能转成502。关于RST来源、连接池和空闲超时，可参考Connection Reset的分层排查，客户端最终看到的502不代表代理本身就是最初故障点。
重试要考虑幂等
GET等读取可有限退避重试，并换健康节点；POST写入可能已在上游执行，只是响应丢失。网关与客户端同时重试会成倍放大流量，应规定唯一责任层、最大次数、随机抖动和幂等键。
建议记录的字段
- 请求ID、路由、方法、状态码与生成组件；
- 选中的上游地址、连接时间、首字节时间和总耗时；
- 重试次数、上游状态、响应标志与熔断原因；
- 应用队列、线程池、连接池和依赖耗时；
- 错误发生前后的发布、扩容和配置变更。
结论
502、503和504分别提示上游响应异常、暂时不可用和等待超时，但真正根因仍需由生成层日志确认。沿着请求时间线核对连接、健康、容量和依赖，比统一扩大超时或无限重试更可靠。
