Nginx 会新建连接而非排队：当 keepalive 池满且无可复用空闲连接时，Nginx 直接新建 TCP 连接发往后端；默认无请求排队功能，需依赖 limit_req burst 或 Nginx Plus 的 queue 指令实现真正排队。
keepalive 连接池满时，Nginx 怎么处理新请求
当 upstream 中配置了 keepalive 32，表示每个 worker 进程最多缓存 32 个空闲长连接。若此时所有连接都被占用（活跃中），或池中已无可用空闲连接，Nginx 并不会直接拒绝请求，而是按以下逻辑处理：
- 优先尝试复用：新请求到来时，Nginx 先检查本 worker 的 keepalive 池中是否有未超时、可复用的空闲连接；有则直接复用，不新建连接
-
池满且无可复用 → 新建连接：若池已满（达到 32 条）且所有连接都处于活跃状态（正在处理请求），Nginx 会新建 TCP 连接发往后端——这会绕过 keepalive 池，但连接仍受
proxy_connect_timeout和后端健康状态约束 -
新建连接失败或后端不可达 → 触发重试或降级：取决于
max_fails/fail_timeout配置和健康检查结果；若所有节点均不可用，则返回 502/503
排队机制不是默认开启的，需要显式启用
开源版 Nginx 本身不提供内置请求排队功能。所谓“排队”，实际依赖两个独立但可协同的机制：
-
限流排队（limit_req + burst）：基于客户端 IP 或路径做速率控制，
burst=50 nodelay表示允许最多 50 个请求暂存在内存队列中，立即响应或快速拒绝；去掉nodelay则按设定速率平滑释放，形成真实等待 -
Nginx Plus 的 queue 指令：仅 Plus 版支持，在 upstream 块中写
queue 64 timeout=10s，表示当 keepalive 池无空闲连接时，新请求可在队列中等待最多 10 秒，等待空闲连接释放；超时或队列满（64）即返回 503
为什么不能只靠 keepalive 池“自动排队”
keepalive 池管理的是连接生命周期，不是请求调度队列。它的作用是复用连接、减少握手开销，而非缓冲请求。关键区别在于：
- 池中连接数反映的是“当前有多少连接正被使用”，不是“有多少请求在等连接”
- 没有 queue 或 limit_req 机制时，一旦连接池耗尽且后端响应慢，新请求就会阻塞在 proxy_read_timeout 期间，占用 worker 进程和内存，可能引发雪崩
- 真实排队必须由明确的缓冲策略（如 burst 队列）或 Plus 的 queue 控制，否则 Nginx 默认行为是“尽力发，发不出就等/超时/失败”
配合健康检查与连接超时才能稳定排队
无论用 limit_req burst 还是 Plus queue，要让排队真正有效，必须确保后端连接链路可控：
-
proxy_http_version 1.1和proxy_set_header Connection ""必须启用，否则后端可能主动断连，导致 keepalive 失效、排队请求反复建连 -
proxy_read_timeout应略小于后端 keepalive timeout（例如后端设 60s，Nginx 设 55s），避免连接因超时不同步而泄漏或卡死 - 启用 active health check（如
health_check interval=3 fails=2 passes=2），确保排队请求不会持续发往已卡顿或假死的节点
