核心是验证worker_connections在真实业务压力下能否持续、可控、不降级承载目标连接规模，重点观察是否撑住、是否丢连接、是否触发系统瓶颈；须用wrk而非ab压测，通过-c参数模拟长连接模型，结合ss -s与stub_status比对estab和active值，并同步监控错误日志、进程句柄上限、fd占用率及连接状态分布，确保系统级、用户级、nginx级三层限制对齐。
测试 worker_connections 在超大规模连接下的稳定性与健壮性，核心不是“压到崩溃”，而是验证它能否在真实业务压力下持续、可控、不降级地承载目标连接规模。重点看三件事：是否真能撑住、是否悄悄丢连接、是否触发系统级瓶颈。
用 wrk 模拟真实连接模型做定向压测
避免用 ab 这类短连接工具——它测的是 QPS，不是连接池能力。wrk 支持长连接、可设连接数（-c）和线程数（-t），更贴近真实场景：
- 先跑基线：
wrk -t4 -c8192 -d60s http://127.0.0.1/，观察Active connections是否稳定接近 8192，P95 延迟是否平稳 - 逐步加压：从
-c16384→-c32768→-c65536，每次运行至少 2 分钟，中间不 reload - 关键指标盯紧：
ss -s | grep "TCP:"中的 ESTAB 数，必须和 Nginxstub_status的 Active 值基本一致；若 ss 显示 5 万 ESTAB，但 Nginx Active 卡在 3 万，说明卡在了 accept 层或 ulimit
监控四项硬指标，识别静默失败
很多“不稳定”不报错，只表现为延迟跳升、连接复位或请求丢失。必须实时盯这四个地方：
- 错误日志：grep “accept.*failed|Too many open files” /var/log/nginx/error.log，1 分钟内出现 ≥3 次即为风险信号
-
进程句柄上限：执行
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 soft/hard 值 ≥worker_processes × worker_connections -
当前 fd 占用：
lsof -p $(pgrep nginx) | wc -l，持续 > 85% 上限时，内存和上下文切换压力已明显上升 -
连接状态分布：
ss -s输出中重点关注 ESTAB、SYN-RECV、TIME-WAIT 比例；若 SYN-RECV 长期 > 100，说明内核 backlog 不足（需调net.core.somaxconn）
验证三层限制是否真正对齐
worker_connections 是“纸面能力”，实际可用连接数由三者最小值决定。缺一不可：
-
系统级：
cat /proc/sys/fs/file-max≥worker_processes × worker_connections × 1.3（预留 SSL 缓存、日志、临时文件） -
用户级：用 Nginx 运行用户（如 www-data）执行
ulimit -n，输出值必须 ≥worker_processes × worker_connections -
Nginx 级：配置中
worker_rlimit_nofile必须显式声明，且 reload 后用/proc/$(pgrep nginx)/limits验证是否生效
结合业务连接特征做差异化验证
同样 5 万连接，对短连 API 和 WebSocket 的压力完全不同：
- 短连接密集型（如秒杀接口）：压测时开启 keepalive off，关注 Accepts/Handled 比例是否下降、Requests 是否堆积；若 Requests 持续低于 Accepts，说明连接被 accept 但没处理完，可能是 CPU 或 upstream 卡住
-
长连接保活型（如 WebSocket）：用 wrk 加
--timeout 300模拟 5 分钟长连，观察 Waiting 连接是否缓慢增长但无异常断连；重点检查keepalive_timeout和worker_rlimit_nofile是否充足 - HTTPS 反向代理：启用 OCSP stapling 和 session cache 后，额外消耗 500–2000+ fd，建议压测时开启完整 TLS 配置，而非 HTTP 回源
