必须同步调整系统级、用户级、进程级三层文件描述符限制，且 nginx 需配置 epoll、multi_accept 和 accept_mutex 等参数，再按业务类型合理设置 worker_connections 值并验证生效。
设置 worker_connections 超过 1024 时，不能只改 Nginx 配置文件里的一个数字。它实际生效受三层限制共同约束，任意一层卡住，值再大也白设，还会报 “worker_connections exceed open file resource limit” 或静默丢连接。
必须对齐的三层文件描述符限制
每个 TCP 连接至少占用 1 个文件描述符（fd），Nginx worker 进程还要额外用 fd 处理日志、SSL 缓存、上游连接、临时文件等。真实可用连接数 = 三者中的最小值：
-
系统级总上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.3～1.5 -
用户级限制：在
/etc/security/limits.conf中为 Nginx 运行用户（如nginx或www-data）添加：nginx soft nofile 65536<br>nginx hard nofile 65536
若使用 systemd，还需在/etc/systemd/system/nginx.service中加LimitNOFILE=65536并执行systemctl daemon-reload -
进程级声明：在
nginx.conf主块（events外、http前）添加：worker_rlimit_nofile 65536;
该值应 ≥worker_connections，推荐设为相同值或略高（如 1.2 倍）
必须同步配置的 Nginx 自身参数
worker_connections 必须放在 events { } 块内，且需配套启用高效事件机制：
- 显式指定
use epoll;（Linux 必须写，否则可能回退到有 1024 硬限的select） - 开启
multi_accept on;，让单次事件通知尽可能接受多个新连接 - 关闭
accept_mutex（默认 on），高并发下可减少锁竞争（但需配合epoll和足够 CPU 核心）
需按业务类型合理设值，不是越大越好
过高会浪费内存（每个连接占几 KB）、加剧上下文切换，甚至触发内核瓶颈：
-
高频短连接（如 H5 秒杀页、API 接口）：设 4096–16384，搭配
keepalive_timeout 0或 15–30s -
长连接保活型（如 WebSocket、HTTP/2、直播流）：设 2048–8192，
keepalive_timeout控制在 15–75s -
HTTPS 反向代理：SSL session cache、OCSP stapling 等额外消耗 fd，建议
worker_connections不超过单进程 ulimit 的 70%–80%
验证是否真正生效
改完配置后，别只看 Nginx 启动成功：
- 检查进程实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 观察运行时连接数：
nginx -T 2>/dev/null | grep worker_connections+ss -s | grep "TCP:" - 压测时关注错误日志中是否仍有 “too many open files” 或连接被静默拒绝现象
