worker_connections必须与系统文件描述符、内核参数及nginx自身限制（worker_rlimit_nofile）三者对齐，否则触发“too many open files”或静默丢连；需检查limits.conf、systemd limitnofile、nginx.conf中worker_rlimit_nofile和events块配置，并按业务类型合理设值。
worker_connections 不是填个数字就能用的参数，它必须和系统文件描述符、内核限制、Nginx 自身声明三者对齐，否则会直接触发 “Too many open files” 或静默拒绝新连接。以下是一份面向企业级生产环境的基线配置核查清单，聚焦可落地、可验证的关键项。
系统级文件描述符限制是否到位
每个 TCP 连接至少占用 1 个文件描述符（fd），若 worker_processes 是 8、worker_connections 设为 65535，理论需 524280 个 fd ——但系统不放行，实际就卡在默认的 1024。
- 检查 /etc/security/limits.conf 是否为 Nginx 运行用户（如 nginx 或 www-data）设置了软硬限制：
nginx soft nofile 65535nginx hard nofile 65535 - 若使用 systemd（绝大多数现代发行版），确认 /etc/systemd/system/nginx.service.d/override.conf 存在且含：
[Service]<br>LimitNOFILE=65535
- 执行
systemctl daemon-reload && systemctl restart nginx后，用以下命令验证生效：cat /proc/$(pgrep -f "nginx: master")/limits | grep "Max open files"
输出中 Soft Limit 和 Hard Limit 均应 ≥ 65535
Nginx 进程级句柄上限是否显式声明
系统允许 ≠ Nginx 能用。Nginx 默认不会主动申请高 fd 限额，必须在主配置中明确“申请”。
- 确认 nginx.conf 的全局块（events 外、http 前）包含：
worker_rlimit_nofile 65535; - 该值应 ≥ worker_connections，推荐设为相同值或略高（如 1.1–1.2 倍），为日志、上游连接、SSL 缓存等留余量
- 若
worker_rlimit_nofile超过系统 hard limit，Nginx 启动时可能失败或静默降级为默认值（1024），务必核对
worker_connections 是否置于正确位置并匹配业务类型
该指令仅在 events { } 块内有效，写错位置（如 http 或 server 块）会导致配置不生效或启动报错。
- 确认配置位于标准 events 块中，且配套关键参数：
events {<br> worker_connections 65535;<br> use epoll;<br> multi_accept on;<br>} - 数值不是越大越好：过高会增加内存占用（每连接约数 KB）、加剧上下文切换，还可能触发内核瓶颈
- 按典型业务场景参考基线：
• 短连接密集型（API 网关、CDN 回源）：4096–16384
• 长连接保活型（WebSocket、HTTP/2 上报、直播流）：2048–8192
• HTTPS 反向代理：建议 ≤ 单进程 ulimit 的 70%–80%，即不超过 45874（65535 × 0.7）
内核网络队列与事件模型是否同步调优
连接还没进 Nginx 就被内核丢弃，调高 worker_connections 也无意义。
- 检查 /etc/sysctl.conf 是否设置：
net.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
执行sysctl -p生效 - 确认 events 块中已启用高效 I/O 模型：
use epoll;（Linux 必须显式指定，不能依赖默认） -
multi_accept on;应开启，让单次事件循环尽可能多地 accept 新连接，减少延迟
