keepalive_requests 的核心作用是控制每个长连接最多处理的请求数后主动关闭，以避免连接老化引发的抖动、超时和状态残留；它通过请求计数归零重启实现健康轮换，需配合 keepalive_timeout 及客户端复用配置协同生效。
keepalive_requests 的核心作用不是“保持连接”，而是控制每个长连接最多处理多少个请求后主动关闭——这能有效避免因连接复用过久引发的抖动、超时、状态残留等问题。
为什么频繁重连会引发连接抖动？
当后端（如 Nginx）未合理配置 keepalive 机制时，客户端可能在连接尚存但服务端已静默关闭、或 TLS 会话过期、或连接被中间设备（如 LB、NAT 网关）回收的情况下，继续复用旧连接，导致首次请求失败、重试延迟、RTT 波动大、甚至触发客户端级连接池混乱。这不是网络丢包，而是连接“看似可用实则失效”的状态错配。
keepalive_requests 怎么切断问题循环？
它通过强制“请求计数归零重启”来实现连接健康轮换：
- 每建立一个 keepalive 连接，Nginx 内部计数器从 0 开始累加
- 达到 keepalive_requests 设定值（如 100）后，该连接在响应完当前请求后立即关闭，不进入 keepalive 池
- 下一次请求必然新建连接，天然规避了老化连接、证书续期失败、TCP TIME_WAIT 残留等累积性问题
- 配合 keepalive_timeout 使用效果更稳：前者控请求数量，后者控空闲时长，双保险
生产环境典型配置与调优建议
不追求最大值，而要匹配业务特征：
- 高并发短平快接口（如 API 网关）：设为 50～100，兼顾复用率与连接新鲜度
- 含长轮询或 SSE 的服务：建议调低至 10～20，防止单连接长期占用又无法及时感知断连
- 与 gRPC 或 HTTP/2 共存时需注意：HTTP/2 天然多路复用，keepalive_requests 对单个 TCP 连接仍生效，但实际影响面变小；重点应放在上游 client 是否支持 graceful shutdown
- 观察指标：重点关注 Nginx 的 ngx_http_upstream_requests（总请求）、ngx_http_upstream_keepalive（当前空闲连接数），若 keepalive 连接数持续趋近于 0 且 upstream connect time 波动大，说明数值可能偏小
配合客户端才能真正落地
服务端设了 keepalive_requests，客户端也得配合才不白费：
- HTTP 客户端（如 curl、Requests、OkHttp）必须启用 connection reuse（默认通常开启），并设置合理的 max idle connections
- 避免客户端自行设置过长的 idle timeout（比如 300s），否则可能比服务端先断连，造成“服务端想复用，客户端已放弃”
- 对 Go net/http、Python urllib3 等，检查是否启用了 http.Transport 的 idle connection 复用，并确保 MaxIdleConnsPerHost ≥ 后端 worker 数
- 上线前用 ab / wrk 做连接复用压测：对比 keepalive_requests=1 和 =100 时的 99% 延迟和连接新建频率，验证抖动改善效果
