Nginx代理WebSocket压测核心是验证其作为可追踪流量枢纽的能力，需四步：环境准备→链路验证（curl查101、抓包看TCP、后端日志验分发）→JMeter可控压测（正确装插件、配SSL、阶梯加压）→Nginx日志分析（$upstream_addr、$upstream_response_time等字段定位瓶颈）。

测试 Nginx 代理 WebSocket 的并发性能，核心不是测 Nginx 能扛多少连接，而是验证它是否把真实长连接压力无损、可追踪地打到后端，并能看清每条连接的去向、耗时和稳定性。整个过程分四步：环境准备 → 链路验证 → 压测执行 → 结果分析。

一、先调通并确认 Nginx 真正转发了 WebSocket

压测前必须排除配置级故障，否则所有数据都不可信：

• 用 curl 模拟握手，检查是否返回 101 Switching Protocols：
  curl -i -k -H "Connection: upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" https://your-domain.com/ws
• 抓包确认 TCP 层连接建立成功（Wireshark 过滤 tcp.port == 443），看是否有三次握手 + 无 RST 包
• 查后端日志，确认收到连接且带唯一标识（如 X-Backend: node-2），证明 Nginx 分发逻辑生效

二、确保系统和 Nginx 资源不成为瓶颈

单机并发卡在 1k–5k，90% 是资源没放开，不是代码问题：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 调高文件描述符上限：
  在 /etc/security/limits.conf 加：
  * soft nofile 1048576
  * hard nofile 1048576
  并确保 Nginx 启动用户受此限制
• 同步优化内核参数（/etc/sysctl.conf）：
  net.core.somaxconn = 65535
  net.ipv4.tcp_tw_reuse = 1
  net.ipv4.ip_local_port_range = 1024 65535
  执行 sysctl -p 生效
• Nginx 配置中补全关键项：
  worker_rlimit_nofile 1048576;
  proxy_read_timeout 86400;
  proxy_send_timeout 86400;
  proxy_buffering off;
  proxy_cache off;

三、用 JMeter 做可控压测

JMeter 是目前最实用的 WebSocket 压测工具，但需避开几个典型坑：

• 插件必须通过 Plugins Manager 安装 WebSocket Samplers by Peter Doornbosch；手动丢 JAR 包进 lib/ext 无效
• wss 场景必须配 SSL 上下文：
  在 Test Plan 级添加 SSL Manager，并导入服务端证书（或设为信任全部）；只改 URL 不配 SSL 会卡在 TLS 握手
• 分布式扩展时，所有从节点需上传完整依赖（含插件 JAR 和证书），主节点无法自动同步
• 连接数建议阶梯式加压（如 100 → 500 → 1000 → 2000），每档稳定运行 2–3 分钟，观察错误率与响应时间拐点

四、从 Nginx 日志定位真实瓶颈

别只盯着“连接数”，重点看连接质量：

• 在 log_format 中加入关键字段：
  $upstream_addr $upstream_response_time $upstream_http_x_backend $status $request_time
• 分析维度：
  —— $upstream_addr：看连接是否按预期分发（如 ip_hash 是否均匀）
  —— $upstream_response_time：区分是 Nginx 转发慢，还是后端处理慢
  —— 502/504 错误突增：大概率是后端挂了或超时配置不匹配
  —— 大量 499：客户端主动断连，可能是前端心跳异常或网络抖动