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 安全审计工具,检查 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:客户端主动断连,可能是前端心跳异常或网络抖动










