先查Ingress日志确认504是否真实来自该层：若无“upstream timed out”记录，则问题在LB、Service或DNS；若有，再根据日志中“while connecting/reading/sending”关键词定位超时阶段，并结合access_log的$request_time、$upstream_response_time和$upstream_addr三字段交叉分析集群或节点级慢问题。
确认504是否真实来自Ingress层
先查用户反馈的完整请求时间、URI和Trace ID，立刻去Ingress Controller Pod的日志里搜对应时间窗口的error.log行：kubectl logs -n ingress-nginx 【ingress-nginx-controller-xxxx】 2>&1 | grep "upstream timed out" | grep "21:13:42"。
如果日志里压根没有这条记录，说明504根本没经过Ingress——问题在LB、Service或DNS；如果找到了，继续往下走。
定位超时发生在哪一段路径
看error.log里那条报错末尾的关键词：
出现 【while connecting to upstream】 → Ingress连不上后端Pod，可能是Endpoint为空、Pod未就绪、网络策略阻断或Service selector不匹配；
出现 【while reading response header from upstream】 → 连已建好，但Pod迟迟不发响应头，大概率是应用卡死、GC停顿、DB锁表或下游API挂了；
出现 【while sending to client】 → 请求已从Pod返回，但Ingress往客户端回传时卡住，重点查client_body_timeout、send_timeout或客户端异常中断。
交叉验证access_log中的三组关键字段
第一步：进入Ingress Controller Pod，执行 nginx -T | grep -A10 'log_format' 确认access_log格式是否包含 $request_time、$upstream_response_time 和 $upstream_addr。
第二步：用 kubectl exec -n ingress-nginx 【ingress-nginx-controller-xxxx】 -- tail -n 100 /var/log/nginx/access.log | grep "504" 提取最近几条504记录。
第三步：逐条检查：
若 $upstream_response_time 显示为 “-” 或 “0.000”，且 $upstream_addr 是空或全为“-”，说明Ingress压根没选到可用后端——立刻查 kubectl get endpoints 【your-service-name】 -n 【your-ns】；
若 $upstream_response_time 是 “59.998, 0.002, 0.003”，而 $upstream_addr 集中在 10.244.3.17:8080 和 10.244.3.18:8080，说明这两个Pod响应极慢，其他节点正常——直接进那两个Pod查 jstack 或 top；
若所有 $upstream_addr 都频繁出现在504行中，且 $upstream_response_time 普遍接近 proxy_read_timeout 值（比如都是59.997），说明集群整体变慢，不是节点故障而是负载或依赖瓶颈。
检查Ingress资源是否覆盖了超时配置
方法一：直接看Ingress YAML里有没有 annotation：
nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
nginx.ingress.kubernetes.io/proxy-connect-timeout: "60"
nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
方法二：如果没加annotation，就查全局ConfigMap：
kubectl -n ingress-nginx get cm ingress-nginx-controller -o yaml | grep -E "(proxy.*timeout|keepalive)"
注意：Ingress resource里的annotation优先级高于ConfigMap，但低于location块内硬编码——不过Ingress Controller不支持在location里手写proxy_*_timeout，所以实际只认前两者。
快速验证后端Pod是否真慢
第一步：挑一个报错中出现过的 $upstream_addr（如 10.244.3.17:8080），用curl直连：
kubectl exec -n ingress-nginx 【ingress-nginx-controller-xxxx】 -- curl -w "\n%{time_total}\n" -s -o /dev/null "http://10.244.3.17:8080/healthz"
第二步：对比结果——如果直连耗时稳定在0.02s，但Ingress打过去就是504，说明问题出在Ingress与Pod之间的链路：查NetworkPolicy、CNI插件状态、kube-proxy日志；
第三步：如果直连也卡在30s以上，问题就在Pod内部：进该Pod执行 curl -v http://localhost:8080/healthz，再看应用日志、线程堆栈、数据库连接池使用率。
