worker_connections不能单独调高，它只是并发能力的“刻度标尺”，真正起效必须与系统资源、内核参数、Nginx进程限制形成完整闭环，否则将触发“Too many open files”或静默丢连接；需通过ss -s、错误日志、ulimit -n和/proc/sys/fs/file-max四层排查瓶颈，并同步调整limits.conf、worker_rlimit_nofile、sysctl参数及events块配置。
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 是无效的，必须同步调整以下四项：
-
系统级 ulimit：编辑 /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;
（高并发下关闭 accept_mutex 可减少锁竞争）
数值设定要匹配硬件与业务特征
不是越大越好，需结合 CPU 核心数、内存容量和连接生命周期综合判断：
- 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 nodelay; - 静态资源场景开启 sendfile on;、tcp_nopush on;，降低内核拷贝开销
- WebSocket 长连接需额外设置：
proxy_read_timeout 86400;
proxy_send_timeout 86400;
proxy_http_version 1.1;
