高频短连接下，Nginx需协同调优worker_connections、系统ulimit、worker_processes、epoll事件模型及keepalive_timeout等参数；单worker并发上限受ulimit -n限制，建议worker_processes auto、worker_connections 8192～16384，禁用keepalive并启用multi_accept与reset_timedout_connection，结合lsof和/nginx_status验证实效。
高频短连接场景下，Nginx 的 worker_connections 配置不是孤立调优项，必须与操作系统限制、worker 进程数、事件模型及超时策略协同调整，否则容易出现“已配置很大值却仍报 too many open files”或连接被异常拒绝的问题。
确认并突破系统级文件描述符限制
Nginx 每个 worker 进程能处理的并发连接数直接受限于系统单进程最大打开文件数（ulimit -n）。即使 worker_connections 65535，若系统默认只允许 1024，则实际生效值仅为 1024。
- 临时提升：在启动 Nginx 前执行
ulimit -n 65536（需 root 或对应权限） - 永久生效：修改
/etc/security/limits.conf，添加两行：nginx soft nofile 65536nginx hard nofile 65536
注意：需确保 Nginx 以nginx用户身份运行，且 PAM limits 已启用 - 验证方式：进入正在运行的 worker 进程目录（如
/proc/$(pgrep nginx)/limits），检查Max open files行
合理设置 worker_processes 与 worker_connections 的乘积
理论最大并发连接数 = worker_processes × worker_connections，但高频短连接意味着连接建立-处理-关闭极快，连接复用率低，更依赖总连接吞吐能力而非长连接保持数。此时应避免盲目堆高单 worker_connections，而要平衡 CPU 利用与上下文切换开销。
- 建议初值：设
worker_processes auto（自动匹配 CPU 核心数），worker_connections 8192～16384 - 若观测到
nginx -s reload后连接陡增或Active connections持续接近上限，可小幅上调worker_connections，但不建议超过 32768 - 避免将
worker_processes设为远超 CPU 核心数（如 32 核机器设 64 进程），会加剧调度竞争，对短连接反而降低吞吐
启用高效事件模型并调优短连接行为
Linux 下必须使用 epoll（Nginx 默认），并配合以下关键参数抑制短连接带来的资源抖动：
-
use epoll;— 显式声明（虽默认，但显式更稳妥） -
multi_accept on;— 允许单次事件通知中接受多个新连接，减少系统调用次数，对突发短连接尤其有效 -
keepalive_timeout 0;— 彻底禁用 HTTP Keepalive，强制每次请求后立即断连，避免连接滞留占用worker_connections槽位 -
reset_timedout_connection on;— 对超时未完成握手或读写的连接快速重置（RST），释放 fd 更及时
监控与验证是否真正生效
仅看配置文件无意义，需结合运行时指标交叉验证：
- 用
nginx -t && nginx -s reload确保配置加载成功 - 访问
/nginx_status（需启用stub_status）查看Active connections峰值是否逼近预期上限 - 用
lsof -p $(pgrep nginx) | wc -l统计某 worker 进程当前打开的 fd 数，应稳定在worker_connections × 1.1范围内（含监听 socket、临时文件等） - 观察系统日志：
dmesg | grep "file limit"或journalctl -u nginx | grep "Too many open files"，若仍有报错，说明 ulimit 未生效或存在其他服务争抢 fd
