Nginx Ingress 请求阻塞其他请求问题排查求助

1. 排查会话亲和性配置 #

如果Ingress或关联的Service配置了会话亲和（比如Ingress的nginx.ingress.kubernetes.io/affinity: cookie，或是Service的spec.sessionAffinity: ClientIP），同一客户端的所有请求会被绑定到同一个Pod。若Pod A被第一个sleep请求占用，后续请求也会被转发到该Pod，进而阻塞。

• 解决：移除会话亲和配置，或确保后端Pod具备多并发处理能力。

2. 检查后端Pod的并发处理能力 #

如果你的后端应用是单进程单线程架构（比如默认配置的Python Flask/Django），即使Nginx发并行请求过来，应用本身也只能串行处理。第一个请求sleep60时，后续请求会排队等待。

• 解决：调整应用的并发配置，比如用Gunicorn启动多worker进程，或切换为多线程模式。

3. 调整Nginx连接复用参数 #

Nginx默认会复用与后端Pod的连接，若连接池过小或Keep-Alive超时设置不合理，第一个长请求会占用连接，后续请求只能等待空闲连接。

• 排查与解决：在Ingress中添加或调整以下注解：
  • nginx.ingress.kubernetes.io/proxy-connection-pool-size: "10"：增大后端连接池大小
  • nginx.ingress.kubernetes.io/proxy-keepalive-timeout: "30s"：缩短Keep-Alive超时，避免连接被长时间占用

4. 验证请求转发逻辑 #

用命令行工具同时发起多个请求，确认阻塞原因：

# 同时发起两个请求，分别指向不同路径
curl http://your-domain/ & curl http://your-domain/dashboard

如果两个请求都阻塞，说明是会话亲和或后端Pod单线程问题；如果第二个请求正常响应，那可能是浏览器的同域名并发限制（可忽略，因为你的场景是后续请求完全阻塞）。

5. 查看Nginx Ingress日志 #

通过日志确认请求转发的Pod目标：

kubectl logs -n ingress-nginx <nginx-ingress-controller-pod-name>

如果后续/dashboard请求也被转发到Pod A，说明是会话亲和配置导致；如果转发到了其他Pod仍阻塞，需排查其他Pod状态或网络问题。

内容的提问来源于stack exchange，提问作者GrasWindowWind