worker_connections需按内存、业务类型与系统限制三者协同设定：先估算单连接内存开销（20kb至1mb不等），再结合可用内存和worker_processes反推合理值，同时确保ulimit -n、worker_rlimit_nofile及内核参数同步配平，避免oom或资源浪费。
worker_connections 不是随便设大的数字，它必须和服务器实际可用内存匹配。每个连接会占用几十KB到几百KB不等的内存，设得过高会导致内存吃紧甚至 OOM；设得太低又压不住并发流量。关键不是“能设多大”，而是“该设多大才稳”。
先算清楚单连接真实内存开销
不同配置下内存消耗差异很大：
- 纯静态服务（无 SSL、无代理）：约 20–50 KB/连接
- 启用 HTTPS（SSL/TLS 上下文 + 缓冲）：约 100–250 KB/连接
- 反向代理 + HTTP/1.1 + 默认 proxy_buffer：约 300–600 KB/连接
- 若启用了 large_client_header_buffers 或自定义 buffer 大小，单连接可能突破 1 MB
举例：8 GB 内存服务器，预留 2 GB 给系统和其他进程，Nginx 可用约 6 GB。若走代理且平均连接占 400 KB，则理论最大连接数 ≈ 6 × 1024 ÷ 0.4 ≈ 15,360。再除以 worker_processes（比如设为 4），单个 worker_connections 就应控制在 3840 左右，取整为 4096 更稳妥。
按业务类型反推合理区间
不要只看峰值连接数，要看连接“停留时间”和“资源占用模式”：
- 短连接 API（如 H5 秒杀、登录接口）：连接存活时间短，可设高些，4096–16384
- 长连接场景（WebSocket、HTTP/2 流式响应）：连接常驻内存，建议 2048–8192，并配合 keepalive_timeout 控制空闲释放
- 后端响应慢的代理服务：连接会在 Nginx 中排队等待，此时更需调优 proxy_read_timeout 和重试逻辑，而非盲目拉高 worker_connections
必须同步配平的三个硬约束
光算内存不够，还得让这个值在系统层跑得通：
- 系统文件描述符上限：每个连接至少占 1 个 fd，ulimit -n 至少要比 worker_connections × worker_processes 高 20%
- Nginx 进程级限制：必须在主配置中写 worker_rlimit_nofile，且该值 ≥ worker_connections（推荐设为相同或 1.2 倍）
- 内核 socket 缓冲区总容量：大量长连接时，net.core.wmem_max 和 net.core.rmem_max 也要适当调大，避免因缓冲不足触发重传或丢包
上线前验证是否真“跑得动”
设完不能就完事，要观察真实压力下的表现：
- 用 nginx -t 检查语法，再 reload 后观察 /proc/$(pgrep nginx)/status 中 VmRSS 是否稳定增长
- 监控 active connections 和 waiting connections 比例：waiting 长期 > 10%，说明连接堆积，可能是后端慢或 timeout 设置不合理
- 检查 dmesg | grep -i "out of memory" 或 oom-killer 日志，确认没被系统强制 kill
