worker_connections必须嵌套在events块中，配合use epoll、multi_accept和accept_mutex协同配置，并同步调优系统、进程及Nginx三级文件描述符限制，否则将导致启动失败或连接拒绝。
worker_connections 不是孤立参数，它必须和 events 模块内其他指令协同生效，同时依赖外部系统级配置。单独调大这个值，不配套调整，反而会引发连接拒绝或启动失败。
必须嵌套在 events 块中，位置不能错
该指令只能出现在 events { ... } 花括号内部，写在 http、server、location 甚至 main 层（events 外、http 前）都无效。Nginx 启动时会直接报错退出，例如：
nginx: [emerg] "worker_connections" directive is not allowed here- 常见正确写法：
events { worker_connections 4096; use epoll; multi_accept on; }
必须搭配 use epoll（Linux 环境）
在 Linux 2.6+ 系统上，worker_connections 要发挥高并发能力，需显式启用 epoll 事件模型。虽然 Nginx 默认会自动选择，但显式声明更可靠，避免因编译选项或环境异常导致回退到低效的 select/poll：
- 不写
use epoll;，高并发下可能无法充分利用 CPU 和连接队列 - 与
worker_connections同处 events 块，顺序无关，但建议放在一起便于维护
需与 multi_accept 和 accept_mutex 协同控制连接分发
这三个指令共同影响新连接如何被 worker 进程接收：
-
multi_accept on;：允许单个 worker 在一次事件循环中接收多个新连接，提升吞吐；关闭时每次只收一个，易成瓶颈 -
accept_mutex on;（默认）：防止“惊群”，避免多个 worker 同时争抢 accept，适合高并发；若关掉，需确保multi_accept已开且系统负载可控 - 三者组合建议：
multi_accept on; accept_mutex on;是 Linux 下稳定高并发的常用搭配
必须同步对齐三层文件描述符限制
worker_connections 的实际生效上限，受三个层级约束，缺一不可：
- 系统级：/proc/sys/fs/file-max（全系统总句柄数），建议 ≥ worker_processes × worker_connections × 2
- 进程级：ulimit -n（当前用户/进程最大打开文件数），必须 ≥ worker_connections
- Nginx 内部级：worker_rlimit_nofile（写在 events 外、http 前），建议 ≥ worker_processes × worker_connections，并留 10%～20% 余量
任一层未达标，Nginx 要么启动失败，要么连接静默拒绝（不报错但返回 503 或超时）。
