504 Gateway Timeout本质是Nginx与上游服务间超时契约失效，需通过access_log中request_time、upstream_response_time和upstream_addr三字段组合定位集群级慢或节点局部问题，辅以error_log异常类型及K8s endpoints/pod状态交叉验证。
直接看 error_log 无法确认 504 是集群节点响应慢导致的，因为 Nginx 的 error_log 默认不记录 upstream 超时详情。真正能定位这类问题的是 access_log 中的字段组合，配合 error_log 中的辅助线索。
重点看 access_log，不是 error_log
error_log 里通常只记类似：
2026/05/12 08:42:15 [error] 12345#0: *6789 upstream timed out (110: Connection timed out) while reading response header from upstream
这类日志说明“读响应头超时”，但无法区分是单个后端挂了、还是整个集群多数节点变慢。
判断是否集群级响应慢，必须回到 access_log，关注三组关键字段：
- request_time：Nginx 从收到请求到返回响应的总耗时。若大量请求该值集中在某个固定值（如 30.001、60.000、180.002），基本等于你配置的 proxy_read_timeout，说明不是随机抖动，而是普遍卡在超时点
- upstream_response_time：后端实际返回第一个字节的时间。如果该字段大量显示为 “-” 或 “0.000”，代表 Nginx 根本没等到任何响应；如果出现多个数值（如 “0.002, 0.003, 59.998”），说明部分节点快、个别节点极慢，拖累整条链路
- upstream_addr：列出实际转发的目标地址。若错误集中出现在某几个 IP:port（比如 10.20.30.11:8080、10.20.30.12:8080），而其他节点正常，则是节点局部问题；若所有 backend 地址都频繁出现在超时行中，才是集群整体响应变慢
用 error_log 辅助交叉验证节点状态
虽然 error_log 不直接报“慢”，但它会暴露底层异常，帮你看清是网络层、连接层还是应用层的问题：
- 出现 “connect() failed (113: No route to host)” 或 “Connection refused” → 后端进程已崩溃或端口未监听，不是“慢”，是“不可达”
- 出现 “upstream prematurely closed connection” → 后端主动断连，常见于应用 OOM Kill、JVM Full GC 暂停、或容器被驱逐
- 出现多条 “no live upstreams while connecting to upstream” → 所有健康检查失败，集群节点大面积失联，可能因网络分区、节点 NotReady 或 readinessProbe 全部失败
结合 Kubernetes 状态快速确认节点健康度
如果你用的是 K8s Ingress（如 nginx-ingress），光看日志不够，要立刻查集群状态：
- 运行
kubectl get pods -n <ingress-ns></ingress-ns>，确认 ingress controller 本身 Pod 是否 Running 且 Ready - 运行
kubectl get endpoints <backend-svc-name> -n <ns></ns></backend-svc-name>，看 SUBSETS.ADDRESSES 是否为空或明显少于预期 → 表明 service 后端 endpoint 未注册成功 - 运行
kubectl describe pod <backend-pod></backend-pod>，检查 Events 中是否有 FailedMount、CrashLoopBackOff、ImagePullBackOff 等，这些都会导致节点“响应慢”的假象（其实是根本没起来）
