根本原因是Ingress-nginx与后端连接复用不匹配：后端未正确配置keepalive或主动断连，导致nginx复用失效连接超时；需统一keepalive设置、核对多层timeout、排查网络干扰及健康检查冲突。
这个问题很常见：Ingress-nginx 日志里反复出现 upstream timed out (110: Connection timed out)，但你直接 curl 后端 Pod 或看应用日志，发现响应只要几毫秒 —— 明明很快，却被判超时。根本原因通常不是后端慢，而是 Ingress-nginx 和后端之间的连接或配置不匹配。
检查 upstream 连接复用与 keepalive 设置
Ingress-nginx 默认会复用到后端 Pod 的连接（keepalive），但如果后端服务（比如 Spring Boot、Node.js、Gin）没有正确配置 HTTP keepalive，或者主动关闭了空闲连接，nginx 就可能在复用一个已失效的连接时触发 timeout。
- 确认后端服务开启了 HTTP/1.1 keepalive，并设置了合理的
keep-alive timeout（例如 60–300 秒） - 在 Ingress 资源中显式配置 upstream keepalive，避免默认值过低或不兼容：
nginx.ingress.kubernetes.io/upstream-keepalive-connections: "200"
nginx.ingress.kubernetes.io/upstream-keepalive-timeout: "60"
nginx.ingress.kubernetes.io/upstream-keepalive-requests: "1000" - 如果后端是 gRPC 或长连接场景，还需额外设置
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"并调大超时
核对 timeout 配置是否被多层覆盖
超时不是单一参数决定的。Ingress-nginx 中存在多个层级的 timeout，容易互相覆盖或遗漏：
- proxy-read-timeout：从后端读响应的最长时间（默认 60s）—— 这是最常被误调的项
- proxy-connect-timeout：与后端建立 TCP 连接的超时（默认 60s）
- proxy-send-timeout：向后端发请求体的超时（默认 60s）
- 这些可通过 annotation 设置，例如：
nginx.ingress.kubernetes.io/proxy-read-timeout: "30" - 注意：ConfigMap 全局配置（如
proxy-read-timeout）会被 Ingress annotation 覆盖，但如果你没设 annotation，又没改 ConfigMap，默认 60s 一般不会导致“明明很快却超时”；所以更可能是连接复用问题，而非读超时本身
排查网络路径中的干扰因素
即使 Pod 响应快，中间环节也可能破坏连接稳定性：
- Service 的
sessionAffinity: ClientIP或externalTrafficPolicy: Local可能导致连接路由异常，尤其在节点扩缩容后 - CNI 插件（如 Calico、Cilium）的 conntrack 表溢出或老化时间过短，造成连接被意外中断
- 若使用 NetworkPolicy，确认未误拦截健康检查或重试流量
- 在 Ingress-nginx Pod 内执行
curl -v http://直连后端 Pod IP（绕过 Service），观察是否仍有 timeout —— 可快速定位是 kube-proxy、Service 还是 nginx 自身的问题:
验证并精简健康检查行为
默认情况下，Ingress-nginx 会对 upstream endpoints 做主动健康检查（active health check），而它的探测逻辑和后端 readiness probe 不一致时，可能导致 nginx 认为某些 Pod “不可用”或连接不稳定：
- 检查是否启用了
nginx.ingress.kubernetes.io/health-check-path等主动探针配置 - 如果后端已有完善的 readiness probe，建议关闭 nginx 主动健康检查（加 annotation：
nginx.ingress.kubernetes.io/health-check: "false"） - 否则，确保健康检查路径返回 200 且响应极快（
