首先，看起来您会收到多个帧作为对单个调用的响应，如documentation所示：
碎片化
WebSocket消息可能会被分割成几个帧。在这种情况下，第一个帧是普通文本或二进制帧，但它的final位将被清除。后续帧将是连续帧（无论是文本还是二进制都由第一个帧来推断），最后一个连续帧将设置final位。插件支持连续帧，但是由于插件是面向帧的，您必须自己读取它们。如果片段的数量事先已知，那么为您期望的每个连续帧添加一个额外的WebSocketReadSampler就很容易了。如果连续帧的数量未知，您需要创建一个循环来读取所有的连续帧。为此，这个插件提供了一个新的JMeter变量websocket.last_frame_final，它可以指示最后一个帧是否是最终帧。使用表达式${__javaScript(! ${websocket.last_frame_final},)}作为条件。使用JMeter If控制器，条件可以简化为! ${websocket.last_frame_final}，因为该控制器会自动将条件解释为JavaScript。有关使用While或If控制器读取连续帧的示例，请参见Read continuation frames.jmx测试计划示例。
如果您不确定服务器是否发送了连续帧或发送了多少，请打开调试日志记录：阅读帧的采样器将记录所接收的帧是“正常”单帧、非最后帧（即，第一片段）、连续帧还是最后连续帧（最后片段）。
如果不是这种情况，我能想到的另一个可能的原因是，有什么东西正在终止您的机器上的WebSocket连接，我不知道具体是什么，可能是firewall或antivirus或您的corporate proxy server
尝试打开java进程的入站和出站流量，将其添加到您的防病毒白名单中，并询问周围的人，也许您的网络管理员可以提供一些线索。
如果您想获得更多的故障排除信息，可以在JMeter的system.properties file中添加下一行：

javax.net.debug=all

并检查JMeter的stdout以查看是否存在线索。
更多信息：Debugging SSL/TLS Connections