worker_connections是连接承载能力的标尺而非吞吐量开关，需与系统fd限制、events模型、业务连接特性协同调优：须对齐三层nofile限制，按短/长连接场景设4096–16384或2048–8192，配套use epoll;、multi_accept on;及合理worker_processes。
worker_connections 本身不是吞吐量的“开关”，而是连接承载能力的标尺。真正实现高吞吐，靠的是它与系统资源、事件模型、业务行为三者严丝合缝的协同——单改这个值，几乎必然失败。
必须对齐三层文件描述符限制
每个 TCP 连接至少占用 1 个文件描述符（fd），而 Nginx 的实际并发上限 = worker_processes × worker_connections。若这乘积超出任一层 fd 限制，就会报 “too many open files” 或静默拒绝新连接。
- 系统级：编辑 /etc/security/limits.conf，为运行用户（如 www-data）设软硬限制：
www-data soft nofile 65536<br>www-data hard nofile 65536
- 服务级：若用 systemd 启动，需在 /etc/systemd/system/nginx.service 中添加：
LimitNOFILE=65536，然后 systemctl daemon-reload && systemctl restart nginx - Nginx 进程级：在 nginx.conf 主上下文（http 块外）加：
worker_rlimit_nofile 65536;，该值应 ≥ worker_processes × worker_connections
匹配业务连接模型设合理数值
数值过大反而拖慢性能：每连接占几 KB 内存，还加剧上下文切换。要按真实连接生命周期来定：
- 短连接密集型（如 H5 秒杀页、REST API）：4096–16384，配合
keepalive_timeout 5–15快速回收 - 长连接场景（WebSocket、HTTP/2、HTTP-FLV 直播）：2048–8192，搭配
keepalive_timeout 15–30防空闲堆积 - 反向代理且后端响应慢：优先调
proxy_read_timeout和重试策略，而非堆高 worker_connections
events 块必须配套启用高效机制
只改 worker_connections 不起作用。Linux 下必须显式激活现代事件模型和接收策略：
-
use epoll;：避免回退到 select/poll 的 1024 硬限制 -
multi_accept on;：让 worker 在一次 epoll_wait 返回后，尽可能多地 accept 就绪连接，缓解突发流量排队 -
accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致惊群；高并发下可测试关掉，但需结合worker_cpu_affinity使用
硬件与进程数要同步规划
理论最大并发 = worker_processes × worker_connections，这个数字必须落在物理资源可支撑范围内：
-
worker_processes auto;：适合大多数物理机或虚拟机，自动匹配 CPU 物理核心数 - 容器环境建议显式设置，例如 Docker 分配了 4 核，就写
worker_processes 4; - 内存估算：每万连接约消耗 100–200 MB 内存（含缓冲区、SSL 上下文等），8192 是较稳妥的起步值
