502是网关连不上上游或收到无效响应，504是连接已建立但上游响应超时；二者根因不同，需结合Nginx错误日志、sidecar指标及上游健康检查精准定位，不可盲目调大超时或重试。
502 和 504 都是网关层暴露的问题，但根源完全不同：502 是“连不上或收不到有效响应”，504 是“连上了但等太久”。在微服务网关场景下，盲目统一调大超时、加重试或扩容上游，往往掩盖真实瓶颈，甚至引发雪崩。优化容灾超时策略，关键在于分清责任边界、按链路分级设防、用可观测性驱动决策。
区分 502 与 504 的真实信号源
别让日志误导你。Nginx error log 里一句 connect() failed (111: Connection refused) 就是典型的 502 根因——上游进程根本没监听端口，可能是 Pod 没就绪、健康检查失败未剔除、或启动脚本异常退出；而出现 upstream timed out (110: Connection timed out) 则指向 504，说明连接已建立，只是后端处理慢。微服务环境下更要结合 sidecar 日志、上游服务的 /actuator/health 或 /metrics，确认是实例不可达（502），还是 P99 响应时间飙升（504）。
按服务等级配置差异化超时参数
微服务不是铁板一块，不能所有接口共用一套 proxy_read_timeout。建议按业务 SLA 分三级：
- 核心读服务（如用户登录、订单查询）：proxy_connect_timeout 5s，proxy_read_timeout 15s，禁用重试（避免放大抖动）
- 非实时写服务（如日志上报、异步通知）：proxy_connect_timeout 10s，proxy_read_timeout 60s，启用最多 1 次重试，且仅限 502/504
- 长耗时任务（如报表导出、AI推理）：单独 location 匹配，proxy_read_timeout 设为 600s 以上，并配合前端轮询或 WebSocket 推送，不阻塞主网关线程
引入主动熔断与降级兜底机制
单靠 Nginx 超时被动等待不够。应在网关层集成轻量级熔断器（如 OpenResty + lua-resty-breaker），当某 upstream 的 502/504 错误率连续 1 分钟超 30%，自动触发半开状态，将后续请求快速失败并返回预设降级响应（如空 JSON 或缓存数据）。同时在 upstream 块中配置：max_fails=3 fail_timeout=30s; 让 Nginx 主动摘除不稳定实例，而不是反复转发失败请求。
强化上下游协同的可观测闭环
真正有效的容灾策略必须打通 Nginx、服务网格与业务指标。例如：把 Nginx access log 中的 $upstream_response_time 和 $status 推送到 Prometheus；上游服务同步暴露 http_server_requests_seconds_count{status=~"502|504"}；再通过 Grafana 做关联看板。一旦发现某接口 504 突增，立刻下钻看其依赖的 DB 连接池使用率、外部 API 调用延迟——问题大概率不在网关，而在下游某环。
