测试worker_connections满载需观察接近满、刚满、超限三临界状态，用wrk精准施压并联动监控Nginx连接状态、系统连接快照、进程fd占用及error.log错误信号，同步验证系统限制对齐。
测试 worker_connections 满载时的表现，核心不是“让它满”，而是观察它**接近满、刚满、超限**三个临界状态下的系统行为——是否丢连接、延迟是否跳变、错误是否出现、资源是否耗尽。关键在精准施压 + 多层指标联动验证。
用 wrk 模拟真实连接压力
别用 ab，wrk 支持长连接、可控并发、输出稳定：
- 先跑基线：
wrk -t4 -c2048 -d30s http://127.0.0.1/（-c值建议略高于单 worker 理论上限，例如worker_processes=4×worker_connections=4096→ 起始-c=8192） - 逐步加压：每次翻倍
-c值（如 8192 → 16384 → 32768），每轮持续 30 秒以上，避免瞬时抖动干扰 - 重点看
-c值是否 ≥worker_processes × worker_connections；若-c=32768但Active connections始终卡在 16000，说明瓶颈不在 Nginx 配置层，而是 ulimit 或内核队列已堵死
实时监控三类关键指标
压测过程中必须同步采集以下数据，缺一不可：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
Nginx 连接状态：开启
stub_status后访问/nginx_status，盯住Active connections是否逼近配置值，Waiting是否突增（>80% 表示连接积压）、Accepts/Handled比值是否跌破 0.95 -
系统连接快照：执行
ss -s查看ESTAB数量是否与 Active 接近；执行netstat -s | grep "listen overflows"，数字上涨即表示内核 accept 队列已溢出，连接被静默丢弃 -
进程文件描述符占用：对每个 worker 进程运行
ls /proc/PID/fd | wc -l，数值长期 >90% 的worker_rlimit_nofile值，说明 fd 即将耗尽
检查 error.log 中的拒绝信号
满载时 Nginx 不会静默失败，会在日志中留下明确线索：
-
accept() failed (11: Resource temporarily unavailable)：常见于突发流量下内核 backlog 溢出或 worker 已满 -
accept() failed (24: Too many open files)：系统级或进程级 fd 耗尽，需立刻检查ulimit -n和worker_rlimit_nofile -
epoll_ctl() failed (2: No such file or directory)：事件模型资源不足，常伴随高并发连接创建/销毁
验证系统限制是否真正对齐
很多“满载”其实是假象——配置没生效，瓶颈卡在别处：
- 查运行中 worker 的实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 soft/hard 值 ≥worker_rlimit_nofile - 查内核连接队列：
ss -lnt看Send-Q（即somaxconn值），若Recv-Q长期 >80%Send-Q，说明内核入口已排队 - 查系统总文件数：
cat /proc/sys/fs/file-max，应 ≥worker_processes × worker_connections × 1.3
不复杂但容易忽略。
