keepalive_requests 不直接控制回源长连接，仅作用于客户端到 Nginx 的连接；防止回源连接过早失效的关键是正确配置 upstream keepalive 32、proxy_http_version 1.1 和 proxy_set_header Connection ''，三者缺一不可。
keepalive_requests 本身不直接用于“回源长连接”，它只作用于客户端到 Nginx 的这一段连接。要防止回源（即 Nginx 到 upstream 后端）的长连接过早失效，关键不是调大 keepalive_requests，而是正确配置 upstream 层的连接复用机制，并让 keepalive_requests 配合得当——避免它无意中切断本可复用的客户端连接，从而间接影响回源链路稳定性。
keepalive_requests 对回源链路的影响逻辑
- 客户端连接若因
keepalive_requests达限被强制关闭，会触发新连接建立； - 新连接若未命中 upstream 连接池中的空闲连接，Nginx 就需新建回源 TCP 连接；
- 频繁新建回源连接 → 后端压力上升、TIME_WAIT 增多、TLS 握手开销增加 → 表现为回源延迟升高或偶发超时。
所以，防止回源长连接“过早失效”的前提是：让客户端连接足够稳定复用，减少不必要的重建，从而让 Nginx 有更多机会复用已建好的 upstream 连接。
应该怎么做
-
对客户端连接段（http 块）合理设置
keepalive_requests- 不设为 0（否则连接长期驻留，可能掩盖问题且内存缓慢增长）；
- 也不设过小（如默认 100），尤其在 React/Vue 单页应用 + 轮询场景下，一次会话常超 50 请求，100 很快打满；
- 推荐值：1000–3000，配合
keepalive_timeout 25s–30s，形成“请求数+空闲时间”双约束，既保障复用率，又防僵死。
-
必须单独配置 upstream 连接池（这才是真正管回源的）
upstream backend { server 10.0.1.10:8080; keepalive 32; # 每个后端最多缓存 32 个空闲长连接 } location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ''; # 清除 Connection 头，避免后端误关连接 # 可选：启用 socket 级保活，防防火墙静默断连 proxy_socket_keepalive on 240s 10s 3; }-
keepalive 32是核心：它让 Nginx 主动维护空闲连接，供后续请求复用； -
proxy_http_version 1.1和proxy_set_header Connection ''是前提，缺一不可，否则后端可能拒绝复用。
-
-
避免客户端“主动放弃”而服务端还想复用
- 检查前端 SDK（如 axios、OkHttp）是否禁用了 connection reuse；
- 若客户端设置了比 Nginx
keepalive_timeout更短的 idle timeout（例如 10s），它会先断连，导致 Nginx 的 upstream 连接池无法被持续利用； - 建议客户端 idle timeout ≥ Nginx
keepalive_timeout+ 5s 缓冲。
-
验证是否生效的小方法
- 查看回源连接是否复用：
ss -tnp | grep :8080 | grep ESTAB | wc -l，压测前后对比是否稳定在几十个（而非飙升数百）； - Nginx 日志中检查
upstream_addr字段，若频繁出现新 IP:port 组合，说明回源连接未复用； - 观察
ngx_http_upstream_keepalive监控指标（需启用 stub_status），应长期保持非零值。
- 查看回源连接是否复用：
不复杂但容易忽略的是：keepalive_requests 是客户端连接的“寿命计数器”，它不控制回源，但会影响回源能否被高效复用。真正守护回源长连接的，是 upstream 的 keepalive + proxy_http_version 1.1 + Connection '' 这组组合。
