最可靠方式是用wrk压测至理论连接上限附近，观察Nginx拒绝连接、系统资源触顶及error.log中“Too many open files”等提示；需结合stub_status、ss -s和错误日志三指标交叉验证，并排除ulimit、file-max、somaxconn等配置干扰。
直接用压测工具打到理论连接上限附近，观察 Nginx 是否开始拒绝新连接、系统资源是否触顶、错误日志是否出现关键提示——这是验证 worker_connections 是否被真正打满的最可靠方式。
用 wrk 精准模拟连接池压力
推荐使用 wrk（比 ab 更稳定，支持长连接与连接复用控制）：
-
基础测试：`wrk -t4 -c8192 -d30s http://127.0.0.1/`，其中
-c值应 ≥ 单个 worker 的worker_connections×worker_processes的 80% -
逼近上限：若配置为
worker_processes 4;和worker_connections 2048;，理论最大连接数为 8192，则用-c 6553（约 80%）起步，再逐步加到 7500、8000、8192 -
强制新建连接：加
-H "Connection: close"或禁用 keepalive，避免单连接发多个请求干扰“连接数”统计
三项核心指标交叉验证是否真打满
不能只看响应成功与否，要同步盯住以下三类输出：
-
Nginx 实时连接状态：启用
stub_status模块后访问/nginx_status，重点关注Active connections是否稳定接近worker_processes × worker_connections；若卡在 6000 不再上升，说明存在瓶颈 -
系统级连接统计：运行
ss -s | grep "TCP:"，查看ESTAB数是否与 Active connections 基本一致；若ESTAB明显偏低，可能是内核队列溢出或 ulimit 未生效 -
错误日志关键词：实时监控
tail -f /var/log/nginx/error.log，出现accept() failed (24: Too many open files)或worker_connections are not enough即表示已触及硬限制
排除常见干扰项
很多“打不满”其实是配置没对齐造成的假象：
-
检查进程实际限制：执行
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 soft/hard 值 ≥worker_rlimit_nofile，且该值 ≥worker_connections -
确认系统总池充足：
cat /proc/sys/fs/file-max应 ≥worker_processes × worker_connections × 1.3（预留 TIME_WAIT、SSL 缓存等开销） -
验证内核网络队列：若
netstat -s | grep "listen overflows"非零，说明net.core.somaxconn太小，连接在进入 Nginx 前就被丢弃
观察打满后的典型表现
真正打满时，会出现可预期的组合现象，而非单一指标异常：
- 客户端开始收到
Connection refused或超时，而非 HTTP 错误码 -
stub_status中Waiting连接数激增，Reading和Writing比例失衡 - CPU
%sy（系统态）明显升高，因频繁处理 accept/fd 分配等内核调用 - QPS 不再随并发增长而提升，P95 延迟跳升 >30%，错误率快速上升
