优化worker_connections需协同突破系统ulimit、配置worker_rlimit_nofile、匹配业务连接模型（短连/长连）及events参数（epoll、multi_accept），否则仅调大数值会因文件描述符不足导致“too many open files”或连接静默拒绝。
优化 worker_connections 不是单纯调大一个数字，而是让这个值在系统资源、Nginx 运行机制和业务连接模型之间真正“跑得通”。它卡住时，常见现象是 too many open files、连接被静默拒绝、或 Active connections 长期逼近配置上限却无法提升吞吐。
先确认并突破系统文件描述符限制
Linux 默认每个进程最多打开 1024 个文件描述符（fd），而每个 TCP 连接至少占 1 个 fd。如果 worker_connections 8192，但 ulimit -n 还是 1024，那真实上限就是 1024。
- 临时生效：启动 Nginx 前执行
ulimit -n 65536（需 root 或对应权限） - 永久生效：编辑
/etc/security/limits.conf，添加两行（把nginx替换为实际运行用户，如www-data）：nginx soft nofile 65536nginx hard nofile 65536 - 验证是否生效：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"
同步设置 Nginx 进程级句柄上限
仅靠系统 limits 不够。Nginx 主配置中必须显式声明它能申请的 fd 上限，否则即使系统允许，Nginx 也会自我限制。
- 在
events块之外添加：worker_rlimit_nofile 65536; - 该值应 ≥
worker_connections，推荐设为相同值或略高（如 1.2 倍），为日志、上游连接等留余量
结合业务类型设合理值，不是越大越好
每个连接占用几 KB 内存，过高会加剧内存压力与上下文切换开销。数值要匹配真实连接行为：
- 静态资源或短连接 API（如 H5 秒杀页）：可设
4096–16384 - WebSocket、HTTP/2 或直播流（HTTP-FLV）长连接：建议
2048–8192，并配合keepalive_timeout 15–30控制空闲时长 - 反向代理且后端响应慢：连接会在 Nginx 中等待，此时更需优化
proxy_read_timeout和重试策略，而非盲目提高worker_connections
配套 events 参数必须协同调整
只改 worker_connections 效果有限。必须匹配事件模型和连接接收机制：
-
use epoll;：Linux 必须显式指定，避免回退到有 1024 硬限的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接造成“惊群”
