nginx并发极限测试关键在真实负载下验证稳定性：先逐层确认ulimit、/proc//limits及worker_rlimit_nofile三者一致且≥65535；再用wrk阶梯压测，以error.log出现“too many open files”及失败率＞0.5%为fd瓶颈点；最后通过stub_status、listen overflows和ip_local_port_range交叉验证，实测极限取多轮最小值并按70%留余量。
测试文件描述符调优后 Nginx 的并发支撑极限，关键不是“看配置写了多大”，而是验证在真实高负载下，系统是否能稳定维持住目标连接数、不报错、不丢请求。整个过程分三步走：先确认调优已生效，再施加压力并观测瓶颈点，最后交叉验证指标一致性。
确认文件描述符限制已真正生效
很多问题出在“以为调好了，其实没生效”。必须逐层检查：
- 系统级限制：运行
ulimit -n（在启动 Nginx 的用户 shell 下执行），应显示 ≥65535；否则检查/etc/security/limits.conf是否对对应用户（如 www-data 或 nginx）正确配置了soft nofile和hard nofile - Nginx 进程级限制：查主 worker 进程 PID（
ps aux | grep nginx | grep -v master），再执行cat /proc/<pid>/limits | grep "Max open files"</pid>，输出的Soft Limit应与 ulimit 一致，Hard Limit应 ≥ Soft Limit - Nginx 配置联动：确保
nginx.conf中设置了worker_rlimit_nofile 65535;，且events { worker_connections 65535; }—— 注意：后者不能超过前者，否则启动时会警告或静默截断
用 wrk 模拟真实并发连接并观察临界点
使用 wrk 发起长连接压测，重点盯住连接建立成功率和错误日志：
- 命令示例：
wrk -c 100000 -t 32 -d 300s --timeout 10s http://your-server/（-c 表示目标并发连接数，建议从 2 万起跳，每次 +2 万递增） - 实时监控：
ss -s查看 ESTAB 连接总数；tail -f /var/log/nginx/error.log留意accept() failed (24: Too many open files)或connect() failed (24: Too many open files)—— 出现即说明 FD 耗尽 - 关键判断：当 wrk 报 “Failed requests” 显著上升（>0.5%），且 error.log 出现上述错误时，当前并发值就是 FD 限制下的实际瓶颈点，而非理论值
结合 /nginx_status 和内核参数交叉验证
仅看连接数不够，要确认资源是否被其他环节卡住：
- 启用
stub_status模块，访问http://your-server/nginx_status，关注Active connections是否接近worker_processes × worker_connections；若远低于该值，说明瓶颈不在 FD，可能在net.core.somaxconn或 TCP 队列积压 - 检查内核连接队列：
netstat -s | grep -i "listen overflows"，数值持续增长说明net.core.somaxconn不足（建议设为 65535） - 反向代理场景下，还需确认本地端口是否耗尽：
cat /proc/sys/net/ipv4/ip_local_port_range，范围应为1024 65000或更宽，否则后端建连失败也会表现为“连接拒绝”
记录可复现的极限值并留出安全余量
最终得到的极限并发数不是上线值，而是基准参考：
- 多次测试取稳定值：同一配置下至少跑 3 轮，取最小成功并发数（例如三次分别撑住 8.2 万、7.9 万、8.1 万，则以 7.9 万为实测极限）
- 生产环境建议按 70% 使用：即实测极限为 8 万，线上最大连接数建议控制在 5.6 万以内，避免突发流量或日志刷盘等干扰触发边界抖动
- 配套检查内存：高并发下每个连接约占用 10–20KB 内存（含缓冲区），8 万连接可能消耗 1–1.6GB 内存，需确保物理内存充足且未触发 swap
