keepalive_requests直接决定单个长连接最多处理N个请求后强制关闭，影响复用效率、资源占用与稳定性：设太小（如100）致频繁建连、TIME_WAIT激增；设太大（如10000+）易造成空闲连接堆积；React应用建议2000，轻量API可设1000–3000，需协同压缩与缓存优化。
keepalive_requests 直接决定单个长连接能承载多少次请求，它不是“越大越好”，而是影响连接复用效率、资源占用和稳定性之间的关键平衡点。
它怎么影响长连接性能？
这个参数设为 N，意味着：一个客户端与 Nginx 建立的 keep-alive 连接，最多处理 N 个请求后，Nginx 就会主动关闭该连接（即使还没到超时时间）。它的作用是防止单个连接长期驻留、累积内存开销或掩盖连接老化问题。
- 设得太小（如默认 100），在高 QPS 场景下会导致连接频繁新建/关闭，引发大量 TIME_WAIT、端口耗尽、TCP 握手开销上升；
- 设得过大（如 10000+），若客户端实际请求稀疏，连接可能空闲很久才被
keepalive_timeout清理，造成 worker 进程连接数堆积； - 对 React 单页应用这类资源密集型前端，一次页面加载就可能触发 20–50 个静态资源请求 + 多轮 API 调用，100 明显不够用。
怎么设才合理？
目标是让一个典型用户会话周期内的全部请求，尽量落在同一个连接上完成，同时避免连接“过期”或“僵死”。推荐参考值和判断依据：
- React 应用托管场景：建议设为 2000，覆盖首屏加载 + 后续交互 + 若干轮轮询或微前端子应用资源加载；
- 轻量级 JSON API 服务：QPS > 5000 时，可设为 1000–3000；若后端存在偶发延迟或连接不稳定，可降到 200–500 强制轮转；
- 不建议设为 0（不限制），这会掩盖真实连接管理问题，且长期复用可能引发内存缓慢增长；
- 需同步确认前端构建已启用 Gzip/Brotli 压缩 + 静态资源加了
Cache-Control: max-age=31536000，否则再高的keepalive_requests也压不住重复请求量。
它和 upstream 的 keepalive 是两回事
这个参数只控制客户端到 Nginx这一段的连接行为，不影响 Nginx 到后端服务的连接池。如果 Nginx 做反向代理，你还得单独配置 upstream 的 keepalive、proxy_http_version 1.1 和 proxy_set_header Connection ''，否则后端仍收不到复用连接。
怎么验证调优是否生效？
不能只看配置文件是否写对，要观察真实连接行为：
- 用
curl -I http://your-site.com/static/main.js查响应头是否有Connection: keep-alive； - 连续执行多次 curl，配合
netstat -an | grep :80 | grep ESTABLISHED | wc -l观察连接数是否稳定、不剧烈波动； - 压测时对比开启前后 Nginx 的
Active connections和Reading/Writing/Waiting指标变化，重点关注 Waiting 数是否明显下降。
