优化worker_connections关键在于系统资源、nginx机制与业务特征三者协同，需同步突破ulimit、配置worker_rlimit_nofile、匹配短连接场景（如keepalive_timeout 0、multi_accept on）、指定use epoll并调大somaxconn，否则仅调高数值会触发“too many open files”或静默丢连。
优化 worker_connections 应对瞬时高并发，关键不是堆高单个数值，而是让连接请求能“进得来、分得匀、不卡死”。它必须和系统资源、Nginx 运行机制、业务连接特征三者咬合，否则调再大也报 Too many open files 或静默丢连接。
先破系统文件描述符硬限
Linux 默认单进程最多打开 1024 个文件描述符（fd），而每个 TCP 连接至少占 1 个 fd。若你设 worker_connections 16384，但 ulimit -n 还是 1024，真实上限就是 1024。
- 永久生效：编辑
/etc/security/limits.conf，添加（把nginx换成实际运行用户，如www-data）：nginx soft nofile 65536nginx hard nofile 65536 - 确保 PAM 加载限制：检查
/etc/pam.d/common-session是否含session required pam_limits.so - 验证是否生效：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 soft/hard 值 ≥ 你计划的worker_connections × worker_processes
同步设置 Nginx 进程级句柄上限
系统允许 ≠ Nginx 能用。Nginx 主配置中必须显式声明它可申请的 fd 上限，否则启动会失败或自我降级。
- 在
events块外（即 http 块上方）、全局上下文添加：worker_rlimit_nofile 65536; - 该值应 ≥
worker_connections，推荐设为相同值或略高（如 1.2 倍），为日志、上游连接等留余量 - 若
worker_processes auto（比如 8 核机器启 8 个 worker），总理论连接上限为8 × worker_connections，那么worker_rlimit_nofile至少要 ≥ 单 worker 的连接数，不是总数
匹配瞬时流量特征设合理值
瞬时高并发多为短连接（如秒杀页刷新、API 批量轮询），连接建立快、关闭快，复用率低，更吃总吞吐能力，而非长连接保持数。
- 建议起步值：
worker_connections 8192～16384；压测后可逐步调至32768，避免一步到位引发稳定性风险 - 禁用 HTTP Keepalive：
keepalive_timeout 0;，强制每次请求后立即断连，释放连接槽位 - 启用快速接受：
multi_accept on;，让一个 worker 在一次 epoll 事件循环中尽可能多地 accept 新连接，缓解突发排队 - 高频短连下，
accept_mutex on（默认）仍建议保留，防止惊群；不必盲目关掉
配套内核与事件参数协同加固
只改 worker_connections 是无效的，必须打通底层链路：
- 明确指定事件模型：
use epoll;（Linux 必须显式写，避免回退到有 1024 硬限的select/poll） - 扩大内核连接队列：
net.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
写入/etc/sysctl.conf后执行sysctl -p - 加速 TIME_WAIT 回收（应对短连风暴）：
net.ipv4.tcp_tw_reuse = 1
