worker_connections 是资源上限阈值而非性能拐点参数，其真实极限取决于系统资源、Nginx 配置与业务连接模型三者协同；压测目标是验证在真实流量下能否稳定承载预期并发，且不触发拒绝、延迟飙升或 fd 耗尽，必须对齐系统级、用户级、Nginx 级三层限制。
单机 Nginx 的 worker_connections 不是“调大就能突破”的性能开关，它的真实连接极限由系统资源、Nginx 配置、业务行为三者共同决定。压测目标不是找一个最大数字，而是验证：在你的真实流量模型下，Nginx 能否稳定维持预期并发连接数，且不触发拒绝、延迟飙升或 fd 耗尽。
必须对齐的三层硬限制
任意一层未达标，压测结果就失真，连接数卡在远低于配置值的位置：
-
系统级：
/proc/sys/fs/file-max≥worker_processes × worker_connections × 1.3～1.5（预留 TIME_WAIT、SSL 缓存、日志等开销） -
用户级：运行 Nginx 的用户（如
www-data或nginx）的ulimit -n≥worker_processes × worker_connections；需在/etc/security/limits.conf中永久设置并重启会话 -
Nginx 级：主配置中
worker_rlimit_nofile≥worker_connections（推荐设为相同值或略高），且 reload 后用cat /proc/$(pgrep nginx)/limits | grep "Max open files"确认生效
用 wrk 做定向连接层压测
避免用 ab，wrk 支持长连接、可控并发、可复现连接池压力：
- 先跑基准：
wrk -t4 -c2048 -d30s http://127.0.0.1/（-c略高于单 worker 上限） - 逐步加压：从
-c 4096 → 8192 → 16384 → 32768，每次持续 30 秒以上，观察Active connections是否线性增长 - 盯临界点：当
Active接近worker_processes × worker_connections，且出现以下任一现象，说明已触达瓶颈：-
Waiting或Reading显著升高 - P95 延迟跳升 >30%
-
error.log出现accept() failed (24: Too many open files) -
ss -s | grep tcp中orphanedsockets 持续增加
-
按业务连接模型反推真实承载力
同样设为 8192，短连 API 和 WebSocket 的压力逻辑完全不同：
-
短连接型（静态资源、JSON 接口、秒杀页）：连接生命周期短，fd 快速释放，理论值接近可用值；建议
worker_connections设为 4096–16384，并配合keepalive_timeout 5–15; -
长连接型（WebSocket、HTTP/2 上报、直播流）：单连接驻留时间长，内存与 fd 占用稳定但总量大；建议 2048–8192，并设
keepalive_timeout 15–30;控制空闲时长 -
反向代理型：1 个客户端请求消耗 2 个 fd（客户端 + 后端），实际对外并发能力 ≈
worker_connections / 2；若后端响应慢，优先调大proxy_read_timeout和优化重试策略，而非盲目提高worker_connections
关键监控指标驱动调优
不靠猜测，靠数据判断是否需要调整：
-
Active connections持续 >80% × (worker_processes × worker_connections) → 配置吃紧，需扩容或优化 -
Waiting占比长期超 90% → 大量 keepalive 空闲连接，重点查内存与 fd 是否充足，而非提升吞吐 -
lsof -p $(pgrep nginx) | wc -l接近ulimit -n→ fd 即将耗尽，必须检查三层限制 - CPU 使用率仍低，但
Active无法提升 → 可能未启用use epoll;或multi_accept on;，连接接收效率低 - 内存明显上涨，
Active却无增长 →worker_connections设得过高，每个连接占几 KB，造成虚耗
