调高keepalive_requests不能自动提升复用率，需匹配业务请求节奏、同步缩短keepalive_timeout，并确认客户端及链路支持HTTP/1.1长连接与资源复用。
直接调高 keepalive_requests 并不能自动提升复用率——它只是“允许复用的上限”，真正起效必须匹配业务请求节奏、同步收紧超时，并确认客户端和链路支持。
先看你的业务请求密度
这个值不是越大越好，关键要覆盖“一次典型会话内所有请求”，又不导致连接空闲滞留：
- 前端轮询（如订单状态、未读消息）：间隔 2–10 秒，用户会话常持续几分钟 → 建议设为 2000–5000
- 设备心跳或 SDK 保活：间隔 1–3 秒，期望单连接活跃 15–30 秒 → 推荐 1000–3000
- React/Vue 单页首屏加载+交互资源（JS/CSS/图片/接口）：通常 30–60 次请求 → 1000–2000 更稳妥
- 后端老旧或偶发内存泄漏：主动降低至 50–200，靠频繁轮转规避老化连接风险
必须同步缩短 keepalive_timeout
只调大 requests，但 timeout 还是默认 65 秒，多数连接根本达不到设定请求数就因空闲被关了。高频场景下，空闲比超时更危险：
- 心跳/轮询类：配 keepalive_timeout 15–30s，与 requests 形成“时间+次数”双控
- 避免设为 0 或过长（如 120s），否则低频请求会让连接长期占着 worker_connections 槽位
- 真实连接寿命 = 二者中先触发的那个（谁先到，谁断连）
确认客户端和协议层真在复用
配置写对了，不代表连接就在复用。需验证基础条件是否满足：
- 客户端发起的是 HTTP/1.1 请求，且没带 Connection: close（curl 测试响应头应含 Connection: keep-alive）
- Nginx 到后端的 upstream 长连接另有一套配置（upstream keepalive + proxy_http_version 1.1 + proxy_set_header Connection ""），它不影响 keepalive_requests，但整体复用效率依赖两端都通
- 系统级文件描述符足够：过高的 requests × 高并发连接数可能触发 “too many open files”，需检查并调大 worker_connections 和系统 nofile
别踩这些常见坑
- 不要设为 0：不限制会掩盖连接老化、内存缓慢增长等问题，生产环境不推荐
- 别只调 requests 忽略 timeout：二者是协同参数，单边优化基本无效
-
location 级配置可覆盖全局：比如 API 接口需要更高复用，可在
location /api/块里单独设keepalive_requests 3000 - 它只管客户端到 Nginx 这一段：对 Nginx 到后端的连接完全无影响，后者需单独配 upstream keepalive
