worker_connections 是单个 worker 进程可管理的连接数上限，其实际生效需系统级（file-max）、用户级（limits.conf）、进程级（worker_rlimit_nofile）三者文件描述符限制协同保障，且须配套 events 参数优化与内核调优。
worker_connections 本身不直接“应对”海量请求，它只是单个 worker 进程能同时管理的连接数上限。真正让 Nginx 承载海量请求的，是一整套协同配置：系统资源放开、Nginx 进程声明、事件模型优化、连接行为适配，缺一不可。
必须打通三层文件描述符限制
每个 TCP 连接至少占用 1 个文件描述符（fd），而 worker_connections 的值只有在 fd 资源充足时才真正生效。这三者取最小值，任一环节卡住，连接就上不去：
-
系统级总上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.3～1.5，预留日志、SSL 缓存、TIME_WAIT 等开销 -
用户级限制：在
/etc/security/limits.conf中为 Nginx 运行用户（如nginx或www-data）设置：nginx soft nofile 65536nginx hard nofile 65536
systemd 管理的服务还需在/etc/systemd/system/nginx.service中加LimitNOFILE=65536并执行systemctl daemon-reload -
Nginx 进程级声明：在
nginx.conf全局块（events 外）添加：worker_rlimit_nofile 65536;
该值应 ≥ worker_connections，推荐设为相同或略高（如 1.2 倍）
按业务类型设合理数值，不是越大越好
盲目拉高 worker_connections 会加剧内存压力和上下文切换，还可能触发内核瓶颈。应结合连接模式设定：
-
高频短连接（如 H5 秒杀页、CDN 回源）：设 4096–16384，配合
keepalive_timeout 15–30s，并启用net.ipv4.tcp_tw_reuse = 1 -
长连接保活型（如 WebSocket、HTTP/2 上报、直播 HTTP-FLV）：设 2048–8192 即可满足多数场景；重点保障
worker_rlimit_nofile和file-max充足，避免 fd 耗尽 - HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling 等额外 fd，建议 worker_connections 不超过单进程 ulimit 的 80%
配套 events 参数必须同步开启
只改 worker_connections 几乎无效，必须搭配事件驱动机制才能释放并发潜力：
-
use epoll;：Linux 下必须显式指定，避免回退到有 1024 硬限的 select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群”；高并发且启用reuseport时可考虑关掉以提升吞吐 -
内核 listen 队列要跟上：修改
/etc/sysctl.conf设置net.core.somaxconn = 65535，确保内核不丢 SYN 包；其值应 ≥worker_connections / worker_processes，留余量应对分布不均
验证是否真正跑得通
配置 reload 成功 ≠ 生效。必须实测确认：
- 查任一 worker 进程实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，软硬限制都应是你设的数值 - 压测时观察：
lsof -p $(pgrep nginx) | wc -l查 fd 实际占用；ss -s看 ESTABLISHED 连接数是否接近理论峰值 - 用
stub_status模块访问/nginx_status，看 Active connections 是否稳定在worker_processes × worker_connections的 70%～90%，过高说明资源吃紧，过低说明上游或业务逻辑成瓶颈
