keepalive_requests并非越大越好，而是单个长连接处理请求数的上限，达阈值后Nginx主动关闭连接以平衡复用率与内存开销；React静态托管推荐设为2000并配25s超时，同步启用压缩与强缓存。

keepalive_requests 不是越大越好，也不是越小越省资源。它本质是在单个 TCP 连接生命周期内，用“请求计数”主动控制连接退出时机，从而在复用率和内存占用之间找平衡点。

理解 keepalive_requests 的真实作用

该参数不是限制并发，而是限制**单个长连接上能处理的请求数上限**。达到阈值后，Nginx 主动关闭连接（发送 Connection: close），客户端下次请求必须新建连接。这能避免连接长期空转、内存缓慢泄漏、或因连接老化引发的偶发错误。

• 设为 0：连接永不因请求数关闭（不推荐），易积累陈旧连接
• 设为 100（默认）：对传统多页网站够用，但 React 单页应用一次页面加载就可能触发 30+ 请求，很快耗尽
• 设为过高（如 100000）：若用户行为稀疏，连接会长期驻留，worker 进程中空闲连接数堆积，间接推高内存与文件描述符消耗

React 静态托管场景下的推荐取值

React 应用构建为静态资源后，首屏加载 + 后续 API 轮询（如每 5 秒 fetch）构成典型请求模式。此时建议：

• keepalive_requests 设为 2000：覆盖多数用户单次会话内的全部资源加载（JS/CSS/图片）+ 30–50 次短周期 API 请求
• 同步配置 keepalive_timeout 为 25s：防止低频用户连接空闲过久，两者形成“双保险”——任一条件满足即断连
• 配合启用 Gzip/Brotli 压缩与强缓存（max-age=31536000）：从源头减少重复请求量，比单纯调大 keepalive_requests 更有效降低连接压力

验证是否真正平衡了利用率与开销

不能只看配置生效，要观察实际连接行为：

• 用 ss -tnp | grep :80 | grep ESTAB | wc -l 查看活跃连接数是否稳定，而非持续攀升
• 压测时对比调整前后：相同 QPS 下，TIME_WAIT 数量是否下降、worker_rlimit_nofile 是否接近阈值
• 检查 Nginx 日志中是否有大量 “client closed connection while waiting for request” 类告警——可能是 timeout 过短，而非 requests 过小