Nginx报“worker_connections are not enough”表明并发连接已达瓶颈，需按顺序排查配置、系统文件描述符限制及反向代理连接倍增效应，并通过调整worker_processes、worker_connections和ulimit等分层扩容，reload生效后用ss、stub_status和日志监控验证效果。

看到 error_log 里反复出现 “worker_connections are not enough”，说明当前 Nginx 的并发连接处理能力已到瓶颈，不是简单重启就能解决的，必须结合日志线索做针对性扩容。关键不在于盲目调大数值，而在于看清真实压力来源和系统约束边界。

确认错误是否真实发生且持续存在

先别急着改配置，用以下命令快速验证问题规模：

• grep "worker_connections are not enough" /var/log/nginx/error.log | tail -20 —— 看最近20条是否密集出现（如1分钟内多于5次，基本可判定为持续性瓶颈）
• awk '/worker_connections are not enough/{count++} END{print count+0}' /var/log/nginx/error.log —— 统计历史总触发次数，辅助判断业务增长节奏
• 注意区分警告（warn）和错误（error）级别：warn 表示连接被复用，error 才代表连接被直接拒绝，后者需立即响应

定位是配置限制还是系统资源卡点

这个报错表面是 worker_connections 不够，但根因常在底层。需同步检查三项：

• 当前生效的 worker_connections 值：执行 nginx -T 2>/dev/null | grep -A 5 'events {'，确认实际加载的是哪个值（注意 include 指令可能覆盖主配置）
• 系统级文件描述符上限：运行 ulimit -n 查看当前 Nginx 进程能打开的文件数；若结果 ≤ 1024，即使把 worker_connections 设为 10000 也无效
• 反向代理场景的连接倍增效应：每个客户端请求通常消耗 2 个连接（client ↔ nginx + nginx ↔ upstream），若后端响应慢或启用了 keepalive，连接堆积会更快

分层扩容：从进程、连接数到系统限制

扩容要按顺序推进，跳过任一环都可能白调：

• 调整 worker_processes：设为 CPU 核心数（grep -c ^processor /proc/cpuinfo），避免单核过载导致连接排队
• 合理提升 worker_connections：建议初始设为 10240（10 倍默认值），而非一步到位 65535；观察 24 小时后 error_log 是否收敛
• 同步放宽文件描述符限制：在 nginx.conf 的 main 块中加入 worker_rlimit_nofile 65535;，并确保系统级 limits.conf 已配 * soft nofile 65535 和 * hard nofile 65535
• reload 而非 restart：执行 nginx -s reload 平滑生效，避免连接中断；OpenShift 环境则需 patch ConfigMap 后 rollout restart

验证扩容效果与防复发

改完不是终点，要用数据闭环验证：

• 执行 ss -s | grep "tcp:" 查看当前 ESTAB 连接总数，对比扩容前后峰值变化
• 开启 nginx stub_status 模块（需编译支持），通过 curl http://localhost/nginx_status 实时看 Active connections 数值是否稳定在新上限 70% 以内
• 设置日志监控告警：当 error_log 中该关键词 5 分钟内出现 ≥ 3 次，自动触发告警，避免下次被动响应