最可靠方式是控制变量、分层对比并结合服务端监控：客户端与Nginx物理分离，统一1KB静态资源，关闭无关进程、禁用swap、提升文件描述符至65535，局域网测试，每次压测前重启Nginx并清空page cache。
直接用 ab（Apache Bench）或 wrk 对 Nginx 静态文件路径发起高并发请求，是最常用、最贴近真实场景的测试方式。关键不是跑出多高 QPS，而是观察连接是否堆积、响应是否延迟、错误率是否突增——这些才是稳定性的核心指标。
选对工具和目标文件
静态服务压测必须避开动态逻辑干扰，所以目标 URL 必须是明确存在的纯静态资源，比如：http://your-domain.com/static/logo.png 或 /index.html。
推荐使用 wrk（比 ab 更现代，支持 HTTP/1.1 持久连接和 pipeline）：
-
wrk -t4 -c1000 -d30s http://localhost/static/test.jpg：4 线程、1000 并发连接、持续 30 秒 - 加
-H "Connection: close"可模拟短连接场景，更贴近某些爬虫或老旧客户端行为 - 避免压测
/根路径——它可能触发重定向、SSI 或 index 生成逻辑，不再是纯静态服务
监控 Nginx 自身状态指标
光看 wrk 输出不够，要同步查 Nginx 内置的 stub_status 模块（需在配置中启用）：
- 确认已开启：
location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } - 压测中反复执行
curl http://localhost/nginx_status，重点关注三组数字：
Active connections：应平稳波动，若持续接近worker_connections上限，说明连接耗尽风险高
Reading/Writing/Waiting：Waiting 值长期 >90% 表示大量连接空闲挂起，可能是超时设置过长或客户端异常
Accepts/Handled/Requests：三者差值过大（如 Requests 远小于 Handled）说明请求被丢弃或中断
配合系统层关键参数验证
Nginx 稳定性最终受限于操作系统资源，压测时必须同步观察：
-
ss -s：查看 ESTAB 连接数是否逼近系统net.ipv4.ip_local_port_range或net.core.somaxconn限制 -
free -h && cat /proc/meminfo | grep -i "oom\|commit"：确认无 OOM killer 干预 -
dmesg -T | tail -20：检查是否有 TCP 调优相关警告（如nf_conntrack: table full） - 打开
error.log的debug级别（临时），搜索"accept() failed"或"too many open files"，定位底层瓶颈
验证缓存与文件句柄效率
静态服务性能一大瓶颈是磁盘 IO 和文件打开开销，压测中要确认缓存机制生效：
- 确保配置了
open_file_cache max=5000 inactive=60s;，并用lsof -p $(pgrep nginx) | wc -l观察 worker 进程打开的文件描述符数量是否趋于稳定（而非随并发线性增长） - 若使用 SSD，挂载时加上
noatime，避免每次读取都触发元数据更新 - 用
perf top -p $(pgrep nginx)看热点函数，若频繁出现sys_open或do_syscall_64，说明文件缓存未起效或命中率低
