直接调高 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.conf
net.core.somaxconn = 65535
net.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，从源头降低连接压力