直接压测到worker_connections满载可验证其连接控制能力，需用hey -disable-keepalive高频短连打满，并交叉验证fd数、内核队列与错误日志，确保拒绝行为干净可预测。
直接压测到 worker_connections 满载，观察 Nginx 是否在连接入口处主动拒绝新连接（而非卡住、超时或崩溃），是验证其连接数控制能力最真实的方式。关键不是“能不能撑住”，而是“满的时候怎么退”——是否干净、可预测、不拖累其他请求。
用短连接暴力打满连接槽位
高频短连接最能暴露 worker_connections 的实际承载边界。推荐使用 hey 强制每请求新建 TCP 连接：
hey -n 10000 -c 2000 -disable-keepalive http://your-domain.com/-
-c 2000表示并发 2000 连接，若单 worker 设为 1024、共 4 个 worker，则理论最大活跃连接为 4096；持续压测会快速逼近并突破该值 - 注意：必须搭配
-disable-keepalive，否则 HTTP/1.1 复用会让实际 TCP 连接数远低于并发数，测不准
三层指标交叉验证是否真满载
不能只看响应码，要确认系统层、内核层、Nginx 层是否同步达到极限：
-
查 Nginx 实际打开的 fd 数：
lsof -p $(pgrep nginx | head -1) | wc -l，结果应接近worker_connections × worker_processes，超过说明配置未生效或被绕过 -
查内核监听队列堆积：
ss -lnt | grep :80看Recv-Q值，若长期 > 0（尤其接近somaxconn），说明新连接已在内核排队，Nginx 还没来得及处理 -
查错误日志是否触发拒绝信号：压测中
tail -f /var/log/nginx/error.log出现accept() failed (24: Too many open files)或connect() failed (24: Too many open files)，表明已触达文件描述符硬限，不是优雅拒绝，而是系统级失败
观察拒绝行为是否符合预期
真正有效的满载防御，应表现为快速、明确、无残留的连接拒绝：
- 客户端收到
Connection refused（TCP RST）或503 Service Unavailable，而不是长时间等待后超时 - 用
tcpdump抓包验证：对满载中的 IP 发起新连接，应看到服务端立即返回 RST 包，而非 SYN-ACK 后挂起 - 监控
ss -s | grep "tcp:"中orphan和TIME_WAIT数量——若orphan持续升高，说明连接被内核丢弃前已进入半建立状态，worker_connections未及时拦截
排除常见假满载干扰
很多“满载失败”其实和 worker_connections 无关，而是下游堵点提前卡死：
- 检查
ulimit -n和worker_rlimit_nofile是否 ≥worker_connections × worker_processes，否则 Nginx 根本拿不到足够 fd - 确认
net.core.somaxconn已调高（如设为 65535），否则客户端 SYN 包被内核静默丢弃，表现为大量Connection refused，但 Nginx 日志里完全无记录 - 关闭
keepalive_timeout（设为 0）再测，避免长连接占槽不放，掩盖真实短连吞吐能力
