keepalive_requests核心是平衡复用与驻留：设为N即单连接处理N次请求后强制关闭，与超时无关；只作用于客户端到Nginx段；React应用建议2000，高频API可设1000–3000，需协同keepalive_timeout、压缩与缓存优化。

调优 keepalive_requests 的核心，是让单个客户端连接在“足够复用”和“不过度驻留”之间取得平衡——它不控制连接存活时长，而是控制连接能处理多少次请求后必须关闭。这个值设低了，会逼客户端反复建连；设高了，又可能让异常或低频连接长期占着内存和文件描述符。

理解它的实际作用机制

当设为 keepalive_requests 1000，意味着：一个 TCP 连接从建立开始，无论中间空闲多久（只要没超 keepalive_timeout），只要累计处理满 1000 个请求，Nginx 就会主动断开它。这和超时无关，是硬性计数上限。

• 它只影响客户端到 Nginx 这一段，对 Nginx 到后端（upstream）完全无效
• 它不是“越大越好”，过高的值会让连接生命周期脱离真实业务节奏，尤其在请求稀疏时容易堆积空闲连接
• 设为 0 表示不限制，但会掩盖连接老化、状态异常等问题，还可能引发内存缓慢增长

按业务类型选合理数值

关键判断依据是：一个典型用户会话周期内，大概会发起多少次请求？目标是尽量覆盖完整会话，又不显著超出。

• React/Vue 单页应用：首屏加载 + 后续交互 + 轮询，通常 20–50 个资源请求起步，建议设为 2000
• 高频轻量 API（如心跳、状态轮询，每 2–5 秒一次）：可设 1000–3000，配合较短的 keepalive_timeout（15–30 秒）加快周转
• 低频后台接口或管理页：用户操作间隔长，设 200–500 更稳妥，避免连接空转太久
• 后端偶发延迟或不稳定时：适当调低至 200–500，强制连接轮转，减少因单连接卡死影响整体可用性

必须同步检查的配套配置

单独调 keepalive_requests 效果有限，以下几项必须协同：

• keepalive_timeout 应 ≥ 30 秒（静态资源）或 15–25 秒（API），确保连接有足够“休眠窗口”，避免刚建好就因空闲被关
• 反向代理场景下，upstream 块中必须单独配置 keepalive、proxy_http_version 1.1 和 proxy_set_header Connection ""，否则后端连接仍无法复用
• 前端应启用 Gzip/Brotli 压缩 + 静态资源加 Cache-Control: max-age=31536000，否则重复请求压不下来，再高的 keepalive_requests 也意义不大

验证是否调得合适

不能只看配置写没写对，要观察真实行为：

• 用 curl -I 查响应头是否有 Connection: keep-alive
• 连续发请求，用 ss -s 或 netstat -an | grep ESTABLISHED | wc -l 观察连接数是否稳定、不剧烈波动
• 开启 Nginx 日志变量 $connection_requests，分析单连接平均承载请求数，若普遍远低于设定值，说明设高了；若大量连接刚建好就断，说明设低了