做WebSocket压测时，很多人前面不是录不到流量，而是录出来以后脚本能生成，回放却总是握手失败、连接断开，或者连上以后消息发不出去。这类问题往往不是某一行代码单独写错，而是录制入口、握手头、代理链路和回放协议边界没有放在同一套思路里看。OpenText官方文档里已经把这件事拆开了，DevWeb的Proxy Recorder支持WebSocket录制，脚本里也有专门的`web_websocket_connect`和`web_websocket_send`这类步骤，所以要把问题收住，关键是先把录制链路和握手层站稳。

　　一、LoadRunner怎么录制WebSocket请求

　　录制WebSocket请求时，不要随便选一个Web协议就直接开录。更稳的做法，是先选支持WebSocket的正式录制路径，再去确认本机地址、代理和HTTPS证书这些前置条件，不然后面就算脚本生成了，内容也可能是不完整的。

　　1、先优先用DevWeb Proxy Recorder

　　官方文档明确写到，DevWeb Proxy Recorder支持基于HTTP、HTTPS、HTTP/2和WebSocket的录制，录制结束后会先生成HAR，再由Offline Script Generator转成VuGen脚本。也就是说，录WebSocket时，先走DevWeb这条路比事后手补更稳。

　　2、录制本机服务时不要用localhost

　　如果被测服务就在本机，官方特别提醒不要用`127.0.0.1`或`localhost`，而要改成实际本地IP。因为代理录制器要真正经过网络转发才能抓到数据，这一步漏掉以后，最容易出现页面操作录到了，WebSocket却没录完整。

　　3、需要代理和HTTPS时先把前置条件补齐

　　如果录制环境在企业代理后面，要先在Recording Options里补代理信息；如果是HTTPS，还要让DevWeb CA证书正确安装。否则浏览器表面能打开页面，代理链路却不一定真的把握手和消息完整交给VuGen。

　　4、脚本生成后先确认有没有WebSocket关键步骤

　　录完以后，先看脚本里是不是已经生成了`web_websocket_connect`、发送消息和关闭连接这些关键步骤。先确认骨架完整，再去看业务消息，比一上来就改发送内容更有效。

　　二、LoadRunner WebSocket脚本回放为什么会失败

　　回放失败时，很多人第一反应是消息体不对。实际上，WebSocket在LoadRunner里更容易先卡在握手层，尤其是头信息、Cookie、协议协商值和回放协议边界不一致时，连接都建不起来，后面的发送自然都会跟着失败。

　　1、握手头没有补齐

　　官方函数说明写得很清楚，录制时检测到的头会自动生成，但`Sec-WebSocket-Key`不会被录制，需要时要手工补；如果还要加其他握手头，也要在`web_websocket_connect`前先放`web_add_header`或`web_add_cookie`。这也是最常见的失败点之一。

　　2、Origin、Protocol或Extensions不一致

　　`Origin`、`Sec-WebSocket-Protocol`和`Sec-WebSocket-Extensions`这些字段，只有录制时检测到才会自动带出来。测试环境、网关或服务端协商条件一变，脚本里的这些值就可能要重新核，不然握手会直接被拒。

　　3、HTTP/2场景下边界没看清

　　OpenText的已知问题页明确说明，当脚本按HTTP/2回放时，WebSocket相关API仍然使用HTTP/1.1。也就是说，如果你的链路本身对HTTP/2行为很敏感，就不能只看业务流程一样，还要先接受这层协议边界。

　　4、录制阶段本来就没把关键流量带进来

　　如果一开始录制时用了localhost、代理没配对，或者没有真正经过Proxy Recorder，那么脚本虽然能生成，但关键握手和消息交换很可能根本没完整录进来。后面回放失败，表面看是脚本问题，实际根源还在录制阶段。

　　三、LoadRunner排查WebSocket脚本先查哪一层

　　这类问题最怕的不是不会改，而是顺序反了。明明连接都还没建起来，却一直改消息体；明明录制链路没打通，却在回放阶段反复补函数。更稳的排查顺序，应该是先查录制，再查握手，最后才查业务消息，这样每一层都能判断问题到底卡在前面还是后面。

　　1、第一层先查录制链路

　　先确认你走的是DevWeb Proxy Recorder这条支持WebSocket的正式路径，再确认录制时没有用localhost，企业代理和HTTPS证书也都已经处理好。录制链路不通，后面脚本再怎么改都只是补表面。

　　2、第二层再查`web_websocket_connect`

　　把`URI`、`Origin`、`Sec-WebSocket-Protocol`、`Sec-WebSocket-Extensions`、Cookie和附加头一起核一遍，必要时手工补`Sec-WebSocket-Key`。这一层才是真正决定能不能把连接建起来的地方。

　　3、第三层最后才查业务消息

　　只有当握手已经稳定通过，再去检查`web_websocket_send`的消息内容、文本还是二进制、发送时机和回调处理，排查才不会把连接问题和业务问题混在一起。这个顺序比一上来就改Buffer内容更有效。

　　4、若环境跑在HTTP/2上，再单独核协议边界

　　只要你的业务环境和HTTP/2强相关，就把官方已知限制先摆在前面，再决定是继续沿当前脚本路线排，还是先把这层差异隔离出来。这样做能少走很多无效弯路。

　　总结

　　LoadRunner怎么录制WebSocket请求，关键不是先点开始录制，而是先选对支持WebSocket的录制路径，再把本机地址、代理和HTTPS前置条件收好。LoadRunner WebSocket脚本回放为什么会失败，重点也不只是消息体，而是先看握手头有没有补齐，再看回放协议边界，最后才看业务消息本身。按“先录制、后握手、再消息”的顺序去排，WebSocket脚本通常会比一上来就改发送内容更容易收住。