nginx 502/504本质是网关与上游服务通信失败，需聚焦容器网络连通性、service/endpoint状态、dns解析、cni插件及超时配置；先用curl和nslookup在nginx容器内验证可达性，再结合error.log关键字精准定位。
容器化集群中出现 Nginx 502 或 504，本质不是“Nginx 错了”，而是它作为网关，在转发请求时与上游服务（比如 Pod、Service 或另一组容器）之间的通信链路出了问题。和传统单机部署不同，容器环境多了网络平面（如 CNI 插件）、服务发现（如 kube-dns / CoreDNS）、Pod 生命周期、NetworkPolicy 等新变量。排查要从“Nginx 能否稳定触达上游服务”这个核心出发，而不是只盯着配置文件。
确认上游服务在集群内是否真实可达
很多 502 其实是“连都连不上”，但你查 Nginx 日志看到的是 Connection refused 或 No route to host，这往往不是 Nginx 配置错，而是容器网络不通。
- 进入运行 Nginx 的容器：
kubectl exec -it <nginx-pod-name> -- sh</nginx-pod-name> - 用
curl -v http://<upstream-service>:<port></port></upstream-service>测试——注意用 Service 名（如api-svc:8080），不是 Pod IP；如果失败，说明 DNS 或 Service 转发异常 - 若 Service 不通，再试 Pod IP：
curl -v http://<pod-ip>:<port></port></pod-ip>；通则说明 Service 或 Endpoint 有问题；仍不通，检查 Pod 是否就绪、端口暴露是否正确（containerPort与targetPort匹配） - 检查 Endpoint：运行
kubectl get endpoints <service-name></service-name>，确认后端 Pod 地址列表非空且状态正常
检查容器网络插件与跨节点通信
502/504 在多节点集群中高频出现在跨节点调用时，常见于 CNI 插件异常、MTU 不一致或节点间防火墙拦截。
- 确认所有节点的 CNI 插件（如 Calico、Cilium、Flannel）处于 Running 状态：
kubectl get pods -n kube-system | grep calico - 检查节点间 VXLAN/Geneve 隧道是否建立（如 Calico 使用
calicoctl node status） - 在不同节点上的 Pod 中互 ping 对方 Pod IP；若不通，检查节点主机防火墙（
ufw或iptables）是否放行 CNI 所需端口（如 Calico 默认用 179/BGP、51820/UDP） - 验证 MTU：宿主机网卡 MTU 与 CNI 配置不一致会导致 TCP 分片失败，表现为偶发 502；统一设为 1450（Flannel）或 1440（Calico）较稳妥
验证 Nginx 容器内 DNS 解析与服务发现
容器里 proxy_pass http://api-svc:8080 看似简单，但若 DNS 解析失败或缓存过期，Nginx 会直接报 502（Connection refused），因为它根本没发出去请求。
- 在 Nginx 容器中执行：
nslookup api-svc和nslookup api-svc.default.svc.cluster.local，确认能返回 ClusterIP - 检查
/etc/resolv.conf中 nameserver 是否指向 CoreDNS Service IP（通常是10.96.0.10） - CoreDNS 自身是否健康：
kubectl get pods -n kube-system -l k8s-app=kube-dns；查看日志是否有plugin/errors - 避免使用
localhost或127.0.0.1作为 upstream：在容器里这指向 Nginx 自身，而非宿主机或其它 Pod
结合日志与超时参数做精准区分
502 和 504 在容器环境里常被误判。关键看 Nginx error.log 的错误短语，它直接暴露底层网络行为：
-
connect() failed (111: Connection refused)→ 上游没监听，或 Service 没后端，或 NetworkPolicy 拦截了入向连接 -
upstream timed out (110: Operation timed out)→ 连上了但没回响应，重点查上游 Pod 资源（OOMKilled？CPU limit 被限频？）、慢查询、或 proxy_read_timeout 过短 -
upstream prematurely closed connection→ 上游主动断连，常见于应用未正确处理 keepalive、HTTP/1.1 连接复用异常、或上游进程崩溃 - 在 Nginx 配置中显式设置超时，避免依赖默认值：
proxy_connect_timeout 10s;<br>proxy_send_timeout 30s;<br>proxy_read_timeout 60s;
（根据业务接口实际耗时调整）
