Nginx代理WebSocket高并发压测关键在于验证其作为流量枢纽的稳定性与可追踪性，而非测试Nginx自身性能；需严格完成四配对配置、三项连通性验证、JMeter规范压测及连接质量日志分析。
测试 Nginx 代理 WebSocket 的高并发性能，关键不是压测 Nginx 本身，而是验证它能否稳定、可追踪地把长连接压力传导到后端，并暴露真实瓶颈。整个过程分三步：配置校验 → 连通性确认 → 可控压测。
一、先确保 Nginx 配置完全合规
WebSocket 握手失败或连接频繁中断，90% 源于基础配置缺失。以下四点必须同时满足：
-
强制 HTTP/1.1：
proxy_http_version 1.1;（不能省略，Nginx 默认可能用 1.0） -
透传升级头：必须写成
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";（注意大小写和引号，$HTTP_UPGRADE或$connection_upgrade均无效） -
超时设合理值：如后端心跳间隔为 30 秒，
proxy_read_timeout 90;（单位秒），不建议盲目设 86400；过长会堆积空闲连接 -
禁用缓冲保实时性：
proxy_buffering off;；若需支持大消息，再单独配proxy_buffer_size 128k;和proxy_busy_buffers_size 256k;
二、压测前必须人工验证三项连通性
跳过这步直接开压，大概率得到的是“假失败”——问题出在链路没通，而非性能不足。
-
curl 握手检查：执行命令，确认返回
HTTP/1.1 101 Switching Protocolscurl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" http://your-nginx-ip/ws/ -
TCP 层抓包确认：用 Wireshark 过滤
tcp.port == 80 or tcp.port == 443，看到完整的三次握手 + 后续连续数据帧，无 RST 或 FIN 异常中断 -
后端日志溯源：在后端服务中打印连接来源 IP 或自定义 header（如
X-Upstream: nginx-proxy），确认请求确实经由 Nginx 分发，且每个连接有唯一标识
三、用 JMeter 实现真实、可扩展的 WebSocket 压测
JMeter 是目前对 WebSocket 压测控制最细、扩展性最强的开源工具，但需避开几个典型陷阱：
-
插件安装要规范：必须先装 Plugins Manager，再通过它安装 WebSocket Samplers by Peter Doornbosch；手动丢 JAR 包进
lib/ext不生效 -
wss 必须配 SSL 上下文：不只是改 URL 为
wss://，还要在 Test Plan 级添加 HTTP(S) Test Script Recorder 或设置 JVM 参数-Djavax.net.ssl.trustStore=... - 分布式压测才接近真实场景：单机 JMeter 很难突破 5000 并发 WebSocket 连接；需部署多台 JMeter Slave，主节点协调，避免本机端口耗尽或 CPU 瓶颈
- 依赖上传要完整：所有自定义 JSR223 脚本、证书、CSV 数据文件，必须显式上传到每台 Slave 的对应路径，否则运行时报错
四、监控与分析要聚焦连接质量，不止看吞吐量
Nginx 日志是定位问题的第一现场，重点看这几个字段：
-
$upstream_addr：确认连接是否按预期分发到各后端（比如 ip_hash 是否生效、sticky cookie 是否一致） -
$upstream_response_time：区分是握手慢（首次 101 响应耗时高），还是后续帧延迟高 -
$status+$request_time：过滤出非 101 的响应，排查 Nginx 主动断连（如超时、缓冲溢出） - 配合
nginx_status页面，观察Active connections是否持续增长却不释放，判断连接泄漏
