worker_connections性能提升依赖系统file-max、用户limits.conf、nginx.conf中worker_rlimit_nofile三层fd限制对齐，并需配套use epoll、multi_accept on等events参数及业务连接特征适配，否则设再高也无效。
worker_connections 不是“设大就高性能”，而是整套资源链协同运转的结果。它真正起作用的前提，是系统文件描述符、Nginx 进程声明、内核网络队列和业务连接模型全部对齐——任一环节卡住，连接数再高也白搭。
必须打通的三层文件描述符限制
每个 TCP 连接至少占用 1 个文件描述符（fd），而 Nginx 实际能用的 fd 数，取以下三者的最小值：
- 系统级总上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.3～1.5，预留 TIME_WAIT、SSL 缓存、日志等开销 - 用户级限制：在
/etc/security/limits.conf中为 Nginx 运行用户（如www-data或nginx）添加两行：nginx soft nofile 65536nginx hard nofile 65536 - Nginx 进程级声明：在
nginx.conf主块（events块外、http块前）添加：worker_rlimit_nofile 65536;（该值应 ≥worker_connections，推荐相同或略高 10%～20%）
配套 events 参数必须同步启用
只改 worker_connections，连接来了也接不快、抢不过、复用不了：
-
use epoll;：Linux 下必须显式指定，避免回退到有 1024 硬限的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群”；高并发多 worker 场景下可尝试off+reuseport组合
按业务连接特征设合理值
数值不是越大越好——每连接占几 KB 内存，过高会加剧内存压力与上下文切换开销：
- 短连接密集型（如 H5 秒杀页、REST API）：设
4096–16384，配合较短的keepalive_timeout（如 5–15s） - 长连接保活型（如 WebSocket、HTTP/2 上报、直播流）：设
2048–8192，重点保障worker_rlimit_nofile和file-max充足，并设keepalive_timeout 15–30 - HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling 等额外 fd，建议
worker_connections不超过单进程 ulimit 的 80%
验证是否真正生效
配置 reload 成功 ≠ 连接数真正提升，需实测验证：
- 查进程实际句柄上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 观察活跃连接状态：
ss -s中括号内数字（kernel 维护的 socket 总数），比netstat更准确 - 压测时关注错误日志：若出现
accept() failed (24: Too many open files)或worker_connections are not enough，说明某层限制仍未突破
