直接调高 worker_connections 不能单独解决突发大流量问题，它只是并发上限，需协同系统资源、内核参数及Nginx其他配置；否则将触发“Too many open files”或连接拒绝。
直接调高 worker_connections 本身不能单独解决突发大流量问题，它只是并发能力的“上限刻度”，真正生效的前提是系统资源、内核参数和 Nginx 其他配置协同到位。否则只会触发“Too many open files”或连接被拒绝。
确认当前瓶颈是否真在 worker_connections
很多报错看似是连接数不够，实则是其他环节卡住：
- 用
ss -s或netstat -ant | wc -l查看当前 ESTABLISHED 连接总数，对比worker_processes × worker_connections理论上限 - 检查 Nginx 错误日志：
grep "worker_connections" /var/log/nginx/error.log，确认是否出现accept() failed (24: Too many open files) - 运行
ulimit -n，看当前用户级文件描述符限制是否低于你设的worker_connections - 查系统级最大文件数：
cat /proc/sys/fs/file-max，确保它远大于总连接需求（例如 10 万以上）
同步调整关键配套项
只改 worker_connections 是无效的，必须联动以下三项：
-
系统文件描述符限制：编辑
/etc/security/limits.conf，加入* soft nofile 65535* hard nofile 65535
再确保/etc/pam.d/common-session包含session required pam_limits.so，重启登录或重载 PAM -
Nginx 进程级限制：在
nginx.conf的主上下文（http外）添加worker_rlimit_nofile 65535;
该值应 ≥worker_connections，推荐设为相同数值 -
内核网络队列：修改
/etc/sysctl.confnet.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
执行sysctl -p生效
合理设置 worker_connections 数值
不是越大越好，需结合硬件与业务特征：
- 普通中型网站（日活 10 万以内）：设为
2048～4096已足够 - API 服务或短连接高频场景：可设为
16384～65535，但务必同步调高worker_rlimit_nofile和系统限制 - 若启用大量
keepalive（如超时设为 300s），每个长连接会持续占用一个连接槽位，此时更需评估真实并发连接峰值而非 QPS - 注意：单个 worker 进程能处理的连接数还受限于可用内存（每个连接约占用 2–4KB），8GB 内存服务器不建议单 worker 超过 65535
搭配限流与连接复用更有效
单纯堆高连接数治标不治本，突发流量下应组合使用：
- 用
limit_req控制请求速率，带burst缓冲应对瞬时毛刺，例如：limit_req zone=perip burst=30 nodelay; - 调低
keepalive_timeout（如 15–30 秒），加速释放空闲连接，避免连接堆积 - 开启
tcp_nodelay on;减少小包延迟，提升响应灵敏度 - 静态资源强制启用
gzip和expires，从源头降低连接压力
