worker_connections是每个worker进程并发连接数上限，keepalive_requests是单连接最大请求数；前者管容量天花板，后者管复用深度，二者协同提升连接复用率、降低建连压力。
worker_connections 和 keepalive_requests 是 Nginx 连接复用中两个不同层级、但高度协同的参数：前者决定“能同时撑住多少连接”，后者决定“每个连接最多干多少活”。它们不互为替代，而是分工配合——一个管容量上限，一个管复用深度。
worker_connections：并发连接的硬性天花板
它定义每个 worker 进程最多可维持的**并发连接数**（包括客户端连接和 upstream 连接），本质受系统文件描述符限制。这个值设低了，新连接直接被拒绝或排队；设高了但没配齐 ulimit、worker_rlimit_nofile 或 epoll 优化，反而引发 502/503 或内存抖动。
- 反向代理场景下，1 个客户端请求实际占用 2 个连接（client ↔ Nginx + Nginx ↔ upstream），可用客户端并发 ≈ (worker_processes × worker_connections) ÷ 2
- 它不区分连接是刚建的还是复用的——只要处于 ESTABLISHED 状态，就占 1 个 slot
- 连接复用率越低（比如 keepalive_requests 太小），同样 QPS 下消耗的 worker_connections 就越多
keepalive_requests：单连接复用效率的核心开关
它控制一条 keep-alive 连接最多处理多少个 HTTP 请求后主动关闭。这不是超时机制，而是“计件制”退出：达到设定值，Nginx 就在响应头加 Connection: close 并断连，哪怕连接还空闲着、远未到 keepalive_timeout。
- 默认值 100 在 React、微前端等密集请求场景下极易成为瓶颈：一次首屏加载 30+ 资源，5 次轮询就耗尽，频繁重建连接
- 静态资源建议设 2000–3000，微前端子应用可到 5000；API 网关类服务视 QPS 和后端稳定性，常设 1000–3000
- 该参数只作用于客户端直连（server 块），对 upstream 长连接无效——后者需在 upstream 块中单独配
keepalive N和keepalive_requests M
二者如何协同影响复用效果
真实连接生命周期由 keepalive_timeout 和 keepalive_requests 共同决定，取先触发者。如果 timeout 设 60s、requests 设 5000，而用户平均每秒发 20 个请求，那连接约 250 秒才达限，实际由 timeout 主导关闭；但如果 timeout 缩短到 15s，即使 requests 设再大也难生效。
- keepalive_requests 过小 → 连接复用率低 → 同样流量下 worker_connections 槽位快速耗尽，TIME_WAIT 堆积，建连开销激增
- keepalive_requests 过大（如 0 或 10000）→ 单连接长期驻留 → worker 内存缓慢增长、异常连接不易释放、监控指标失真
- 只调大 keepalive_requests 但忽略系统文件描述符、upstream keepalive、压缩缓存等配套，效果会打折扣甚至引发新问题
验证是否真正提升了复用质量
不能只看配置是否写进 nginx.conf，要观察真实行为：
- 用
curl -v连续请求，第 N+1 次（N = keepalive_requests）响应头应出现Connection: close - 通过
nginx_stub_status观察 Active connections 中 Waiting 连接数是否明显下降，说明连接更“活跃”而非空闲堆积 - 用
ss -tni或 Prometheus + nginx-vts-exporter 查看各连接已处理请求数分布，确认是否集中在设定阈值附近截断 - 对比调优前后
netstat -an | grep :443 | grep ESTABLISHED | wc -l的稳定连接数变化
