worker_connections必须与系统file-max、用户级limits.conf、nginx.conf中worker_rlimit_nofile三者对齐，且按短连接、长连接、https等业务类型差异化设值，并同步配置epoll、multi_accept等事件参数，否则将触发“too many open files”或静默丢连。
worker_connections 不是孤立可调的数字，它必须和系统资源、Nginx 运行机制、业务连接特征三者咬合，否则调再大也报 “too many open files” 或静默丢连接。
对齐三层文件描述符限制
真正起作用的是以下三者的最小值，缺一不可：
-
系统总上限：修改
/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
然后重载 systemd 或重启会话 -
Nginx 进程级声明：在
nginx.conf主块（http外）添加：worker_rlimit_nofile 65536;
该值应 ≥worker_connections，推荐设为相同或略高（如 1.2 倍）
按业务连接类型设合理数值
不同连接模式对 fd 消耗差异很大，不能一刀切：
-
高频短连接（如秒杀页、API 轮询）：连接建立快、关闭快，复用率低。建议
worker_connections 8192～16384，并配keepalive_timeout 0;强制断连释放槽位 -
长连接保活型（如 HTTP/2 上报、MQTT）：单连接复用时间长，fd 占用稳定但总量大。建议
32768～65535，重点保障worker_rlimit_nofile和file-max充足 -
HTTPS 代理场景：除 socket 外还需 SSL session cache、OCSP stapling、证书文件等额外 fd。建议
worker_connections不超过单进程 ulimit 的 80%
配套事件模型与接收策略协同
只改 worker_connections 效果有限，需同步调整底层行为：
-
use epoll;：Linux 下必须显式指定，避免回退到有 1024 硬限的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发排队 -
accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群” - 关闭未启用的日志写入，或启用
buffer+flush，减少每个请求占用的 fd
验证是否真正生效
配置完不能只看 reload 成功，要实测验证：
- 查已运行 worker 进程的实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 压测时用：
lsof -p $(pgrep nginx) | wc -l观察 fd 实际占用ss -s查看连接状态分布（ESTABLISHED 应 >85%，TIME_WAIT 应 - 监控 fd 使用率是否持续 >85%，是否出现
accept() failed (24: Too many open files)日志
