worker_connections不是突发流量开关，必须与系统文件描述符、内核参数、worker_rlimit_nofile及events模型协同调优，单独调高会触发“Too many open files”或静默丢连接。
worker_connections 本身不是“应对”突发流量的开关，它只是并发连接能力的上限刻度。真正起效必须和系统资源、内核参数、Nginx 进程限制、事件模型形成闭环。单独调高只会触发 “Too many open files” 或静默丢连接。
先确认是不是真卡在连接数
很多“扛不住”不是连接不够，而是其他环节堵住了：
- 用 ss -s 查当前 ESTABLISHED 连接总数，对比 worker_processes × worker_connections 理论值
- 查 Nginx 错误日志：grep "accept.*failed.*Too many open files" /var/log/nginx/error.log
- 运行 ulimit -n，看 nginx 用户当前文件描述符限制是否低于你设的 worker_connections
- 查系统总句柄池：cat /proc/sys/fs/file-max，大促建议 ≥ 200 万
四层联动调参，缺一不可
只改 worker_connections 是无效的，必须同步调整以下四项：
-
系统文件描述符限制：编辑 /etc/security/limits.conf，添加
* soft nofile 1048576
* hard nofile 1048576
并确保 /etc/pam.d/common-session 含 session required pam_limits.so -
Nginx 进程级限制：在 nginx.conf 主上下文（http 外）加
worker_rlimit_nofile 1048576;
该值应 ≥ worker_connections，推荐设为相同值 -
内核网络队列：修改 /etc/sysctl.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 25000
net.ipv4.tcp_tw_reuse = 1
执行 sysctl -p 生效 -
events 块优化：在 nginx.conf 的 events 块中配置
use epoll;
multi_accept on;
accept_mutex off;（高并发下关闭可减少锁竞争）
合理设定 worker_connections 数值
不是越大越好，要结合硬件与业务特征：
- 8 核服务器配 worker_processes auto（即 8），单 worker 推荐 worker_connections 16384～32768，总理论并发约 13 万～26 万
- 若启用长连接（如 keepalive_timeout 300;），每个连接持续占槽位，此时更应按真实并发连接峰值而非 QPS 设定
- 内存约束：每个连接约占 2–4 KB，8GB 内存服务器不建议单 worker 超过 65535
- 起步可设为 8192，压测后逐步调至 32768，避免一步到位引发稳定性风险
搭配限流与连接复用，提升实际吞吐
单纯堆高连接数治标不治本，必须组合防御性策略：
- 用 limit_req 控制请求速率，例如秒杀接口：
limit_req zone=seckill burst=50; - 调低 keepalive_timeout（如 15–30 秒），加速释放空闲连接
- 对上游服务设置 proxy_connect_timeout、proxy_read_timeout 为 5~10 秒，避免慢后端拖垮全部 worker
- 启用 OCSP Stapling 和 ssl_session_cache，降低 HTTPS 握手开销
