502/504：先确认是谁返回的、上游是否存活，再查超时、连接池与证书

补充说明

502/504 是网关类错误，不是浏览器或应用直接返回。先确认返回者（云负载均衡、Ingress、Nginx、应用网关），再看上游是否监听、是否有健康端点、超时是否合理。502 更像“上游连接或响应坏了”，504 更像“上游太慢或网关等不及”。本页是分诊入口，单场景处置见 502-bad-gateway 和 504-gateway-timeout。

边界：不覆盖应用内部的性能分析；如果是 499、413、431 或 WebSocket 断开，先看 HTTP 状态码速查 和 Nginx 速查。

3 分钟定位

curl -sv -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/health
curl -sv http://<upstream>:<port>/health
ss -lntp | grep <port>
dig +short <service>.<namespace>.svc.cluster.local
nginx -T | grep -E 'proxy_(pass|connect_timeout|read_timeout|send_timeout)'

Kubernetes 里同时看路由、后端和事件：

kubectl get ingress,pods,svc,endpoints -n <namespace>
kubectl describe ingress <name> -n <namespace>
kubectl logs deploy/<app> -n <namespace> --tail=100
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail

根因树

1. 上游没起来：进程崩溃、端口没监听、启动失败、健康检查未通过。先 ss -lntp 和 curl 直连，不要只看网关日志。
2. 上游起来了但不可达：Service selector 不匹配、Endpoints 为空、targetPort 写错、NetworkPolicy 拦截、DNS 解析失败。
3. 上游可达但太慢：应用排队、数据库慢查询、连接池耗尽、GC 停顿、下游超时；504 常在这里出现。
4. 网关配置问题：proxy_read_timeout 太短、proxy_buffer_size 不足、请求体限制、keepalive 与后端不匹配。
5. TLS/证书：证书过期、证书链不完整、SNI 不匹配、mTLS 客户端证书缺失，常表现为 502 或握手失败。
6. 发布与健康检查：滚动发布时 readiness 过早通过、preStop 太短、旧连接未排空，造成间歇性 502。
7. 资源与限流：CPU 限流、内存不足、文件描述符耗尽、连接数打满，应用无法及时响应。

相关命令

• 502-bad-gateway — 502 的标准排查顺序。
• 504-gateway-timeout — 超时类问题的定位。
• k8s-ingress-502 — Ingress 到 Service 的链路。
• cloud-lb-502 — 云负载均衡的健康检查与后端。
• connection-refused — 连接被拒绝。
• connection-timeout — 连接超时。
• Nginx — 反向代理、超时与缓冲区配置。
• HAProxy — 另一种常见网关的超时与健康检查。
• Nginx Ingress — Kubernetes 侧的 Ingress 配置。
• curl、ss、dig — 逐层验证连接、监听与 DNS。

相关教程

• Nginx 502 故障演练 — 在本地复现 502 并验证修复。
• 网络排障速查 — 从 DNS 到端口的检查顺序。
• HTTP 状态码速查 — 先分清 4xx、5xx 与网关错误。
• Nginx 速查 — 常用代理配置与日志字段。

易错点与排错

• 看到 502 就重启应用：先确认返回者是谁。云 LB、Ingress、Nginx 和应用网关的日志位置不同，重启可能把现场清掉。
• 504 不一定是应用慢：DNS 解析慢、连接池排队、LB idle timeout、重试风暴都会表现为超时。
• kubectl get endpoints 为空：先查 Service selector 与 Pod readiness，再查端口名是否与 targetPort 匹配。
• targetPort 与容器实际监听端口不一致时，Service 看起来正常，但请求全部失败；用 kubectl exec 在 Pod 内 curl localhost:<port> 验证。
• Nginx 的 proxy_read_timeout 与云 LB 的 idle timeout 要匹配；任何一个更短，长请求都会被提前切断。
• 滚动发布期间的 502 常与 readiness、preStop、连接排空有关；先看发布时间和 Pod 状态，不要只盯应用日志。
• 证书链不完整时浏览器可能正常、命令行客户端却失败；用 curl -v 和 openssl s_client -showcerts 看完整链。
• client_max_body_size 太小会返回 413，不是 502；先看状态码，再查对应配置。
• 499 是客户端先断开，通常说明客户端超时或用户取消，不要误判为网关故障。

参考链接

• nginx: ngx_http_proxy_module
• Kubernetes Ingress
• Kubernetes Service
• RFC 9110: HTTP Semantics

读完自测

合上页面，先回答，再展开对照。

1. 502 和 504 的核心区别是什么？
2. kubectl get endpoints 为空，常见原因有哪些？
3. 504 除了“应用处理慢”，还可能是哪些环节的问题？