worker_connections必须置于events块内，且需同步调整系统文件描述符限制、worker_rlimit_nofile和CPU匹配策略，否则无效或触发“too many open files”错误；默认值512不满足高并发，应按业务类型合理设置并配套use epoll、multi_accept on等参数。
直接在 nginx.conf 的 events 块内设置 worker_connections，但必须同步调整系统文件描述符限制、worker_rlimit_nofile 和 CPU 匹配策略，否则配置无效或触发 “too many open files” 错误。
写对位置：必须放在 events 块里
该指令只在 events { ... } 作用域中生效。写在 http、server 或全局块下会被忽略。
- 正确示例：
events {
use epoll;
multi_accept on;
worker_connections 8192;
}
- 默认值是 512，生产环境必须显式修改；不设则沿用默认，无法支撑高并发。
设多少合适：看业务类型，不是越大越好
数值需匹配实际连接模型，盲目调高会增加内存占用和上下文切换开销。
- 短连接 API 或静态资源服务（如 H5 秒杀页）：8192–16384
- 长连接场景（WebSocket / HTTP/2 / 直播流）：4096–8192，并配合
keepalive_timeout 15–30 - 反向代理且后端响应慢：重点优化
proxy_read_timeout和重试逻辑，而非堆高worker_connections
必须同步调的三项关键配置
worker_connections 不是独立参数，它只是整条资源链路中的一环。缺一不可：
-
系统级文件描述符限制：用
ulimit -n查看当前值，若低于目标值，需在/etc/security/limits.conf中为 nginx 用户添加：
nginx soft nofile 65536
nginx hard nofile 65536 -
Nginx 进程级上限声明：在
events块外、http块之上添加：
worker_rlimit_nofile 65536;（该值 ≥worker_connections，推荐相等或略高） -
CPU 与 worker 进程数对齐：设
worker_processes auto;，Nginx 自动匹配逻辑核心数；总理论连接数 =worker_processes × worker_connections，该乘积不能超过系统可用 fd 总量。
配套事件模型不能少
仅改数值不改事件策略，相当于拓宽了车道却没升级红绿灯系统：
-
use epoll;：Linux 必须显式指定，避免回退到有 1024 硬限的select/poll -
multi_accept on;：让单个 worker 在一次事件循环中尽可能多地接收新连接，缓解突发流量堆积 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢连接造成“惊群”
