keepalive_requests 是单连接请求配额而非延时器，与 keepalive_timeout 共同决定连接生命周期，取二者触发时间之先者；默认100在高频场景易致频繁建连、TIME_WAIT堆积及握手开销激增，建议API网关设1000–3000、React应用设2000，并需协同配置upstream长连接。
keepalive_requests 不是延长连接寿命的“延时器”，而是给每个长连接设定一个“工作配额”：它规定一个客户端连接最多能处理多少次请求，到数即断。它和 keepalive_timeout 共同决定连接真实生命周期——谁先触发，连接就按谁的规则关闭。
它怎么参与长连接生命周期控制
一个客户端与 Nginx 建立的 keep-alive 连接，实际存活由两个条件竞争决定：
- 空闲超时：上一次请求结束后，静默等待新请求的时间超过 keepalive_timeout（如 20s），Nginx 主动关闭；
- 请求数耗尽：该连接已成功处理了 keepalive_requests 次请求（如 1500 次），哪怕刚处理完第 1500 次、连接还活跃，Nginx 下次请求前就会断开它。
所以真实生命周期 = min(空闲等待时间, 请求处理上限)。它本质是防止单连接无限复用带来的内存累积、状态老化或资源僵死。
设太小会拖垮高并发代理链路
默认值 100 在 API 网关、微服务调用等高频代理场景中极易成为瓶颈：
- 每秒发起 5–8 次请求的客户端，单连接平均仅撑 12–20 秒，频繁重建连接；
- TCP 握手 + TLS 协商反复发生，实测单次建连耗时 100–300ms，10 次请求若全新建，光握手就可能占掉 1–3 秒；
- 大量 TIME_WAIT 堆积，本地端口快速耗尽，出现 “Cannot assign requested address”；
- worker 进程 CPU 被协议栈操作占用，业务处理能力下降。
设太大反而掩盖问题、挤占资源
盲目调至 5000+，尤其在请求稀疏或负载不均时，会带来隐性代价：
- 连接虽“活着”，但长期空闲，持续占用 worker_connections 槽位，挤压真正活跃连接的空间；
- 老旧后端存在连接老化风险（如句柄泄漏、内存缓慢增长），复用越久出错概率越高；
- 监控中活跃连接数虚高，但 request/sec 未提升，误判为“连接池健康”；
- reset_timedout_connection 等主动回收机制失效，空闲连接只能被动等 keepalive_timeout 扫除，释放延迟。
结合代理场景的合理取值建议
关键看“典型客户端在一个会话周期内会发多少请求”：
- API 网关 / 微服务间代理：QPS 高、单次响应快，建议 keepalive_requests = 1000–3000，配合 keepalive_timeout = 15–30s；
- React/Vue 单页应用反向代理：首屏加载 + 后续交互 + 轮询常达 30–60 请求，建议设为 2000；
- 心跳/轮询类代理（如设备上报）：每 2–5 秒一次，1000 次可支撑 30 分钟以上，设 1000–2000 更稳妥；
- WebSocket 或长轮询升级前代理：这类流量不走常规 HTTP 请求流，keepalive_requests 影响极小，保持默认 100 即可。
注意：它只控制客户端到 Nginx 这一段，Nginx 到后端还需单独配置 upstream keepalive、proxy_http_version 1.1 和 proxy_set_header Connection ''，否则后端收不到复用连接。
