worker_connections 控制每个 worker 进程最大并发连接数，非请求数；http/2 多路复用在单连接内并行处理多请求，降低连接需求，等效提升其承载能力，但需系统、nginx、协议及业务层协同调优。
worker_connections 控制的是每个 worker 进程能同时维持的 TCP 连接数上限，而 HTTP/2 多路复用改变的是“单个连接上能承载多少请求”，两者作用层级不同：前者管资源容量，后者管资源利用率。
worker_connections 管的是“连接总数”，不是“请求数”
它限制的是每个 worker 进程可打开的文件描述符数量，包括：
- 客户端发起的 HTTP/HTTPS、WebSocket、gRPC 等长连接
- 反向代理时与后端服务（如 PHP-FPM、Node.js）建立的上游连接
- 一个 keepalive 的 HTTP/1.1 连接只占 1 个计数，哪怕它后续处理了几十个请求
- HTTP/2 连接同样只占 1 个计数，哪怕内部跑了上百个 stream
HTTP/2 多路复用不减少连接数，但大幅降低连接需求
它本身不改变 worker_connections 的数值含义，但会显著影响你“需要多少连接”：
- HTTP/1.1 下，浏览器通常对同一域名并发 6~8 个连接，100 个请求可能需开 100+ 连接（短连）或至少 6~8 个长连
- HTTP/2 允许单连接内并行传输多个请求（stream），100 个请求可能只需 1~2 个连接
- 这意味着相同 QPS 下，HTTP/2 实际占用的连接数更少，等效放大了 worker_connections 的承载能力
长连接 + HTTP/2 会让连接“更持久、更密集”
这对 Nginx 资源调度提出新要求：
- 连接空闲时间变长 → 需调大 keepalive_timeout，避免过早断连
- 单连接压力集中 → 需关注事件循环延迟和内存占用（每个连接维护更多 stream 状态）
- 连接复用率升高 → 反向代理场景下，upstream connection pool 配置要同步优化，防止后端连接堆积
- 即使 client 只建 1 个 HTTP/2 连接，Nginx 仍可能为它分配多个 event handler 和 buffer，资源消耗不等于“1”
配置必须协同调整，不能只改一个参数
单纯把 worker_connections 设高没用，必须配套：
- 系统级：ulimit -n 至少 ≥ worker_connections × worker_processes
- Nginx 级：启用 epoll、multi_accept on、worker_cpu_affinity
- 协议级：HTTP/2 开启 + 合理设置 http2_max_concurrent_streams（默认128，可根据业务压测调整）
- 业务级：后端服务连接池大小、超时策略、keepalive 设置需与前端匹配
