worker_connections不是孤立调大的数字，必须与系统资源、nginx进程声明、业务连接特征三者对齐，否则仅调高会触发“too many open files”或静默丢连；需同步突破ulimit、worker_rlimit_nofile、somaxconn及events参数（epoll/multi_accept），并按短连/长连场景设定合理值。
worker_connections 不是单独调大的数字，它必须和系统资源、Nginx 进程声明、业务连接特征三者对齐。只改这个值，大概率触发 “Too many open files” 或静默丢连接，起不到扩容效果。
先确认瓶颈在哪
别一看到错误就改配置。先用这几条命令快速定位真实卡点：
- 查错误频率：
grep "worker_connections are not enough" /var/log/nginx/error.log | tail -10—— 如果 1 分钟内出现多次，说明是持续性瓶颈 - 看当前限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"—— 输出的 soft/hard 值，才是 Nginx 实际能用的上限 - 统计连接总数：
ss -s | grep "TCP:"—— 对比worker_processes × worker_connections是否接近或超过 - 检查系统总池：
cat /proc/sys/fs/file-max—— 电商类场景建议 ≥ 200 万
分层同步调参，缺一不可
扩容是四层联动的事，跳过任何一层都会失效：
-
系统级 ulimit：编辑
/etc/security/limits.conf，为 Nginx 用户（如 nginx 或 www-data）加两行：nginx soft nofile 65536nginx hard nofile 65536
若用 systemd，还需在/etc/systemd/system/nginx.service.d/override.conf中加LimitNOFILE=65536，然后systemctl daemon-reload && systemctl restart nginx -
Nginx 进程级声明：在
nginx.conf主块（http 外）加：worker_rlimit_nofile 65536;
该值应 ≥worker_connections，推荐设为相同或略高（如 1.2 倍） -
内核网络队列：修改
/etc/sysctl.conf：net.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
执行sysctl -p生效 -
events 块优化：确保有：
use epoll;multi_accept on;accept_mutex off;（高并发下关闭可减少锁竞争）
按层级与业务设合理值
不同角色、不同连接模式，worker_connections 的“够用”标准完全不同：
- 接入层（L7 入口）：直面海量客户端，短连接为主，建议 4096–8192；QPS 超 5K 且连接持续时间短时，可上探至 16384
- 网关层（API 路由）：连接收敛、复用率高，重点调 keepalive 和 buffer，2048–4096 即可
-
应用层（静态/缓存）：I/O 是瓶颈，非连接数，1024–2048 足够；启用
sendfile on后更无需堆高 -
短连接 API：每秒新建连接多，建议 8192–16384，配合
keepalive_timeout 15防堆积 -
长连接场景（WebSocket/HTTP/2）：连接生命周期长，fd 占用稳定但总量大，建议 32768–65535，同时保障
worker_rlimit_nofile和file-max充足
验证是否真正生效
reload 后不能只看语法通过，要实测验证：
- 压测时运行：
lsof -p $(pgrep nginx) | wc -l和ss -s，观察 fd 实际占用是否接近设定值 - 监控
Active connections（通过 stub_status 模块），看是否稳定在预期区间 - 再查 error.log，确认 “worker_connections are not enough” 是否消失，且无 “Too many open files” 报错
- 内存注意：每个连接约占 2–4 KB，8GB 内存服务器单 worker 不建议超 65535
