排查定位
Ingress 返回 502 或 503，问题几乎都不在 Ingress 对象本身：502 表示控制器作为代理连不上后端（连接被拒、超时、协议不匹配），503 表示控制器认为没有可用后端。适用平台是 Kubernetes，以 ingress-nginx 为例，它的 upstream 就是 Service 的端点列表，端点来自就绪探针通过的 Pod。定位顺序是「先看 Endpoints 有没有地址，再看控制器日志里的 upstream 报错，最后核对探针与端口」。
基本信息
| 适用平台 | Kubernetes，以 ingress-nginx 等 Ingress 控制器为例 |
|---|---|
| 502 常见成因 | targetPort 与容器监听端口不一致、后端进程未起、协议写错（HTTP 对 HTTPS） |
| 503 常见成因 | 端点列表为空：Pod 未 Ready 或被选择器摘除 |
| 排查入口 | kubectl get endpoints、控制器日志、Pod 就绪状态 |
典型使用场景
- 新上线服务首次访问失败：核对 Service 的 targetPort 与容器实际监听端口
- 发布过程中短暂 502：滚动更新期间旧 Pod 已停、新 Pod 还没就绪，检查探针与 maxUnavailable
- 间歇性 503：探针偶发失败导致端点被摘除，需要看探针阈值与超时
- 只在某个域名上失败：核对 Ingress 的 rules.host 与 Service 名、端口是否一一对应
- 切换后端协议后全挂：如后端从 HTTP 改成 HTTPS，注解没同步调整
分层定位
分层定位
kubectl get ingress web -o wide # 入口对象与后端指向
kubectl describe ingress web | tail -20 # 事件与规则解析结果
kubectl get endpoints web-svc # 后端地址是否存在
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller --tail=80 | grep -iE 'error|upstream'
kubectl get pods -l app=web -o wide # READY 列决定是否进端点
kubectl exec -it web-x -- netstat -tlnp | head # 容器实际监听的端口状态码与原因对照
| 现象 | 直接原因 | 核对点 |
|---|---|---|
| 502 Bad Gateway | 控制器连后端失败（拒连/超时/协议不符） | targetPort、监听端口、backend-protocol 注解 |
| 503 Service Unavailable | 端点列表为空 | 就绪探针、Pod READY、选择器标签 |
| 504 Gateway Timeout | 后端处理超时 | proxy-read-timeout 与实际处理耗时 |
| 偶发 502 | 发布过程中的副本切换 | 探针初始化延迟、preStop 与摘除时机 |
Pod 处于 Running 但未 Ready 时不会进入端点列表，表现为 503；targetPort 与容器监听端口不一致则表现为 502，这两个映射关系是最快的判别依据。
控制器日志里的 upstream 报错会直接写出后端地址与失败原因（connection refused、no live upstreams），比反复刷新浏览器有效得多。