keepalive_requests核心是平衡复用效率与资源占用：它限制单连接最大请求数（非时长），达限即断连；推荐值react应用2000、轻量api 1000–3000，并需同步调短keepalive_timeout至15–30秒、确认客户端及upstream长连接支持。
调优 keepalive_requests 的核心目标，是让一个客户端连接在“干够活”和“不占位”之间取得平衡：既充分复用 TCP 连接降低握手开销，又避免单个连接长期滞留挤占资源。
它到底管什么？
这个参数不控制连接能“活多久”，而是限制它能“干多少活”——即单个长连接最多处理多少次请求后，Nginx 就会主动关闭它（哪怕此时还空闲着）。它和 keepalive_timeout 是并列的两个退出条件：任一触发，连接就结束。实际生命周期 = 二者中先到达的那个。
设太小：复用失效，开销翻倍
默认值 100 在高频场景下极易成为瓶颈：
- 每秒发起 5 次请求的客户端，平均 20 秒就要重建一次连接；
- 大量三次握手 + TLS 握手叠加，单次建连耗时可达 100–300ms；
- TIME_WAIT 状态堆积，本地端口快速耗尽，出现 “Cannot assign requested address”；
- worker 进程 CPU 被协议栈占用，业务处理能力下降。
设太大：资源虚占，掩盖问题
盲目设为 5000 或 unlimited 会带来隐性代价：
- 请求稀疏时，连接空闲等待，却仍占用 worker_connections 槽位；
- 老旧后端存在连接老化风险（如内存泄漏），复用越久出错概率越高；
- 监控指标失真：活跃连接数高，但实际吞吐未提升；
- reset_timedout_connection 等机制失效，空闲连接只能等 timeout 才释放。
怎么定一个合理值？
关键看“典型用户会话周期内发多少请求”：
- React/Vue 单页应用：首屏加载 + 交互 + 轮询 + 子应用资源，建议 2000；
- 轻量 JSON API（如移动端）：QPS 高、响应快，设 1000–3000；若后端偶发延迟，可降至 200–500 强制轮转；
- WebSocket 或长轮询服务：这类连接不走常规 HTTP 请求流，keepalive_requests 影响很小，保持默认 100 即可；
- 不建议设为 0：不限制会掩盖真实连接管理问题，且可能引发缓慢内存增长。
必须同步检查的配套项
单独调大 keepalive_requests 效果有限，还需确认：
- keepalive_timeout 缩短至 15–30 秒：高频请求本就不易空闲太久，超时设太长反而延迟释放无效连接；
- 客户端支持 Keep-Alive：HTTP/1.1 默认开启，但需确认没显式发送 Connection: close；
- 反向代理场景下，upstream 也要启用长连接：配置 proxy_http_version 1.1、proxy_set_header Connection ''，并在 upstream 块中设置 keepalive N；
- 禁用兼容性降级指令：如 keepalive_disable msie6，避免误判现代客户端。
