worker_connections 控制每个 worker 进程最大并发连接数，非直接请求数；实际 QPS 取决于连接复用（如 keepalive）、反向代理双连接开销及系统/用户/Nginx 三层文件描述符限制，需配套 epoll、multi_accept 等事件优化。
worker_connections 不是直接处理“请求数”的参数，而是控制每个 worker 进程能同时维持的**最大并发连接数**。高并发场景下，真正决定请求吞吐能力的，是连接如何被复用、释放和调度——它背后是一整套资源协同机制。
连接数 ≠ 请求总数
一个 HTTP 连接（尤其是启用了 keepalive）可承载多个请求。例如：
- 短连接 API：每个请求新建+关闭连接 → worker_connections 几乎等于每秒可处理的请求数上限（受系统 fd 和网络延迟限制）
- 长连接 WebSocket 或 HTTP/2 流式上报：单连接持续数分钟 → 同一连接反复收发请求 → 实际 QPS 可远超 worker_connections 数值
- 反向代理场景：1 个客户端连接 + 1 个上游连接 → 实际并发能力约打五折（两个连接共占 2 个 fd）
必须对齐的三层限制
哪怕把 worker_connections 设为 65535，只要其中任一层卡住，就无法生效：
- 系统级：/proc/sys/fs/file-max 建议 ≥ worker_processes × worker_connections × 1.3（预留 TIME_WAIT、SSL 缓存、日志等开销）
- 用户级：/etc/security/limits.conf 中为 nginx 用户设 soft/hard nofile 至少等于目标值（如 65536）
- Nginx 级：nginx.conf 主块中添加 worker_rlimit_nofile 65536;，且该值 ≥ worker_connections
配套事件模型不能少
只调大 worker_connections 而不配事件策略，相当于修宽了门却没换锁芯：
- use epoll;：Linux 下必须显式声明，避免回退到 select/poll（有 1024 硬限制）
- multi_accept on;：让 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量堆积
- accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接导致“惊群”
按业务类型设合理值
盲目堆高数值反而引发内存压力和上下文切换开销：
- 短连接 API / 静态服务：worker_connections 可设 8192–16384，配合 net.ipv4.tcp_tw_reuse = 1
- WebSocket / HTTP/2 / MQTT：建议 4096–8192，重点保障 keepalive_timeout 和 worker_rlimit_nofile 充足
- HTTPS 代理：SSL session cache、OCSP stapling 等额外消耗 fd，worker_connections 不宜超过 ulimit 的 80%
