keepalive_requests 不决定连接“能不能活”，而是决定它“能干多少活”，与keepalive_timeout共同控制长连接生命周期：任一条件满足即断连，实际存活时间取二者最小值。
keepalive_requests 不决定连接“能不能活”，而是决定它“能干多少活”。它和 keepalive_timeout 一起，共同掐住了长连接的实际生命周期——谁先到，就按谁的规则断开。
它怎么参与控制连接生命周期
一个客户端与 Nginx 建立的 keep-alive 连接，其真实存活时间不是固定值，而是由两个条件竞争决定的：
- 空闲超时：连接上一次请求结束后，静默等待新请求的时间超过 keepalive_timeout（比如 30s），Nginx 主动关闭；
- 请求数耗尽：该连接已成功处理了 keepalive_requests 次请求（比如 2000 次），哪怕第 2000 次刚结束、连接还热乎着，Nginx 也会标记它为“可回收”，下次请求前就断开。
所以实际生命周期 = min(空闲超时, 达到请求数上限)。它不是延长时间的工具，而是给连接设一道“工作配额”。
高并发下设太小会引发连锁反应
默认值 100 在高并发长连接场景中极易成为瓶颈，尤其当客户端复用积极（如 React SPA、App SDK）：
- 单个用户一次页面加载触发 40+ 请求，100 的限额意味着每 2–3 次交互就要重建连接；
- TCP 握手频次飙升，SYN 包激增，内核 conntrack 表压力变大；
- 大量 TIME_WAIT 状态堆积，本地端口快速耗尽，出现 “Cannot assign requested address” 错误；
- worker 进程忙于建连/拆连，CPU 花在协议栈而非业务处理上。
设太大反而掩盖问题、拖慢回收
盲目调高到 5000 或 10000+，在负载不均或请求稀疏时，会带来隐性代价：
- 连接虽“活着”，但长期空闲，占用 worker_connections 槽位，挤占真正活跃连接的空间；
- 某些老旧后端服务存在连接老化问题（如内存泄漏、句柄泄漏），长连接复用越久，出错概率越高；
- 监控指标失真：活跃连接数虚高，但实际吞吐未提升，误判为“连接池健康”；
- reset_timedout_connection 等主动回收机制失效，空闲连接只能等 keepalive_timeout 被扫掉，延迟释放。
结合业务类型给出合理取值区间
没有通用最优值，关键看“典型用户会话周期内发多少请求”：
- React/Vue 单页应用托管：首屏 + 交互 + 轮询 + 子应用资源，建议 2000；
- 轻量 JSON API（如移动端接口）：QPS 高、单次请求快，设 1000–3000；若后端偶发延迟，可降至 200–500 强制轮转；
- WebSocket 代理或长轮询服务：这类连接本就不走常规 HTTP 请求流，keepalive_requests 实际影响小，保持默认 100 即可；
- 纯静态资源 CDN 层：请求体小、复用率极高，可设 5000，但必须配合强缓存（max-age=31536000）和 Brotli 压缩，否则请求数压不下来。
注意：这个参数只管客户端到 Nginx 这一段。Nginx 到后端的连接复用，要靠 upstream 里的 keepalive、proxy_http_version 1.1 和 Connection 头清理来单独配置。
