worker_connections在高频短连接场景下需与系统资源、连接生命周期、事件处理效率协同优化，单独调高无效；必须同步调整ulimit、somaxconn、keepalive_timeout和multi_accept四项参数。
worker_connections 在高频短连接场景下，不是越大越好，而是要和系统资源、连接生命周期、事件处理效率三者咬合。设高了没用，设低了压测直接失败；真正卡住的往往不是 Nginx 本身，而是 ulimit、somaxconn 或 keepalive_timeout 这些“配角”参数。
先看短连接的真实压力在哪
短连接每秒新建/关闭数千次，意味着：每个请求都走完整 TCP 三次握手 + 四次挥手，fd 频繁分配释放，TIME_WAIT 大量堆积，内核连接队列容易打满。此时 worker_connections 的数值只是“理论槽位”，实际吞吐受限于：
– 单 worker 进程能打开的文件描述符上限（ulimit -n）
– 内核监听队列长度（net.core.somaxconn）
– 是否禁用 keepalive 导致连接不滞留
– multi_accept 是否开启以批量收连接
必须同步调的四个关键项
只改 worker_connections 几乎无效，以下四项必须一起动：
-
ulimit 和 worker_rlimit_nofile 对齐：在 /etc/security/limits.conf 中为 nginx 用户设 soft/hard nofile 65536；nginx.conf 主块加
worker_rlimit_nofile 65536;，该值 ≥ worker_connections -
net.core.somaxconn 提到 65535：写入 /etc/sysctl.conf 并执行
sysctl -p，否则客户端 SYN 包会被静默丢弃，压测出现大量 Connection refused -
禁用 keepalive：在 http 或 server 块中设
keepalive_timeout 0;，避免连接挂起占用 worker_connections 槽位 -
启用 multi_accept：events 块中加
multi_accept on;，让一个 epoll 事件循环尽可能多地 accept 新连接，缓解突发流量排队
压测时怎么验证真生效了
别只看 nginx -s reload 成功，要查三层是否真正打通：
- 查运行中 worker 进程的 fd 上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认是 65536 而非 1024 - 查内核连接队列使用率：
ss -s | grep tcp，观察inuse是否长期逼近 somaxconn - 压测中监控
netstat -ant | awk '{print $6}' | sort | uniq -c，若 TIME_WAIT 超过 3 万且持续不降，需开net.ipv4.tcp_tw_reuse = 1 - 用
lsof -p $(pgrep nginx) | wc -l抽样统计单 worker 实际打开的 fd 数，应接近 worker_connections × 当前活跃连接比例
推荐起始配置（4核云主机为例）
不建议一上来就设 65535，先稳住再扩：
worker_processes auto;events { use epoll; multi_accept on; accept_mutex on; worker_connections 16384; }http { keepalive_timeout 0; reset_timedout_connection on; }
跑 wrk -t4 -c10000 -d30s http://xxx 测试，观察 active connections 曲线是否平稳、错误率是否低于 0.1%。达标后再按需将 worker_connections 逐步提到 32768，同步检查 ulimit 和 somaxconn 是否仍余量充足。
