合理设置 keepalive_requests 能显著降低连接建立频率，缓解 worker_connections 压力；前者是单连接最大请求数（复用效率指标），后者是每个 worker 进程最大并发连接数（硬性资源上限）；默认值 100 易致 React 页面频繁重连，建议静态资源设 2000–3000、微前端设 5000，并配合 keepalive_timeout 15–30s 及 upstream keepalive、压缩缓存、系统文件描述符调优。
合理设置 keepalive_requests 能显著降低连接建立频率，从而缓解 worker_connections 的压力——它不直接增加连接数上限，而是让每个连接“多干活”，减少新建连接的必要性。
理解两者的关系
worker_connections 是每个 worker 进程能同时处理的**最大连接数**，属于硬性资源上限；keepalive_requests 是单个长连接上允许承载的**最大请求数**，属于连接复用效率指标。当 keepalive_requests 过小（如默认 100），一个用户加载页面+轮询几次就触发断连重连，短时间内反复消耗 worker_connections 槽位，尤其在 React 应用中，一次首屏可能触发 30+ 请求，若每 5 个请求就换连接，连接复用率极低。
针对高频场景调高 keepalive_requests
对以 React 为主的前端服务或 API 网关类部署，建议按实际请求密度调整：
- React 静态资源托管：设为 2000–3000，覆盖整页资源加载 + 多轮心跳或轮询（如每 5 秒 fetch 一次，持续 2 分钟内约 24 次请求）
- 微前端子应用频繁加载 JS 包：可设至 5000，避免子应用切换时大量连接重建
- 配合 keepalive_timeout 15–30s 使用，防止空闲连接长期占位却不被复用
必须同步优化上游与系统支撑
只调大 keepalive_requests 不足以释放压力，需配套动作：
- 启用 Gzip/Brotli 压缩和强缓存（如
Cache-Control: public, max-age=31536000），从源头减少重复请求量 - 确认 worker_rlimit_nofile 和系统
ulimit -n足够支撑目标连接数（例如 worker_connections 设为 65535，则系统文件描述符至少需 ≥80000） - 若 Nginx 兼作反向代理，还需在 upstream 中配置 keepalive（如
keepalive 64）并开启proxy_http_version 1.1，否则后端连接仍会频繁重建，间接拖累前端连接池稳定性
验证是否真正减轻了建连压力
不能只看配置生效，要观察真实连接行为：
- 用
netstat -an | grep :443 | grep ESTABLISHED | wc -l对比调优前后稳定连接数变化 - 用
curl -I多次请求同一资源，检查响应头是否持续返回Connection: keep-alive，且 TCP 连接未频繁重置 - 监控
nginx_stub_status中 Active connections 与 Reading/Writing/Waiting 的比例，若 Waiting 占比明显下降，说明复用效率提升
