worker_connections本身只是上限阈值，真瓶颈常在系统层、内核队列或事件处理；高频短连压测需验证三层限制对齐（进程句柄、somaxconn、file-max），用wrk禁keepalive逐步加压，结合nginx_status、错误日志、连接状态与fd占用交叉判断饱和点。
直接压测 worker_connections 本身没意义——它只是个上限阈值，真瓶颈往往藏在系统层、连接队列或事件处理环节。高频短连接（如秒杀、API网关）每秒新建/关闭成千上万连接，压力集中在 fd 分配释放、TCP 队列堆积和 accept 效率上。测试目标不是“它能设多大”，而是“当前配置下，连接能否被真正接收、处理、释放而不丢、不卡、不报错”。
先验证三层限制是否对齐
90% 的压测失败源于这三处没配平，只改 worker_connections 纯属白忙：
- 查运行中 worker 进程的句柄上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，输出值必须 ≥worker_connections - 查内核监听队列长度：
sysctl net.core.somaxconn，应设为 65535；若压测中大量出现Connection refused，大概率是它卡住了 - 查系统总文件描述符池：
cat /proc/sys/fs/file-max，建议 ≥worker_processes × worker_connections × 1.3（电商类场景不低于 200 万）
用 wrk 模拟真实短连接冲击
别用 ab，wrk 支持可控并发、可禁 keepalive，更贴近短连模型：
- 禁用长连接：
wrk -t4 -c8192 -d30s --timeout 1s -H "Connection: close" http://127.0.0.1/ - 逐步加压：从
-c4096→-c16384→-c32768，每次观察nginx_status中Active connections是否线性增长 - 关键拐点信号：
Active接近worker_processes × worker_connections时，若P95 延迟跳升 >30%或Waiting突增，说明连接池开始饱和
看错误日志和连接状态双指标
静默失败比报错更危险，得交叉验证：
- 查错误日志：
grep "Too many open files\|accept() failed" /var/log/nginx/error.log，1 分钟内出现多次即为真实瓶颈 - 查连接生命周期：
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -nr，若TIME_WAIT持续超 3 万且不回落，需开net.ipv4.tcp_tw_reuse = 1 - 查实际 fd 占用：
lsof -p $(pgrep nginx) | wc -l抽样统计，应接近worker_connections × 当前活跃连接比例，明显偏低说明连接根本没被 accept 进来
配套参数必须同步验证
高频短连下，这几个参数不生效，worker_connections 再大也白搭：
-
multi_accept on;：用ss -s | grep "inuse"看监听队列是否长期逼近somaxconn，若逼近但Active上不去，说明没批量收连接 -
keepalive_timeout 0;：确认nginx_status中Reading和Writing占比合理（通常 -
reset_timedout_connection on;：避免半开连接堆积，压测中观察ss -s输出的orphan数是否异常升高
