chrome network面板默认不显示websocket连接，需手动启用ws过滤器（输入ws或勾选ws），并确保在连接建立前刷新页面；若仍无记录，需检查连接是否成功建立、initiator来源及onopen回调中执行send。
Network面板里找不到WS连接？检查过滤和刷新时机
Chrome默认不自动聚焦WebSocket流量，Network面板里看不到ws://或wss://条目，大概率是过滤没开或连接还没触发。
必须手动启用WS过滤器：在Network左上角筛选框输入ws并回车，或勾选WS复选框（部分版本需先点Filter再输）；如果页面靠用户交互才建连（比如点“开始聊天”），得先操作再刷新——光按F5可能抓不到。
常见错误现象：
-
Network列表为空白，或只有documentscript等类型，没websocket字样 - 连接明明控制台报
WebSocket connection to ... failed，但Network里无记录
这时优先确认：Initiator列是否显示发起脚本（如chat.js:42），再回头查JS里new WebSocket(...)是否被条件跳过。
点击WS条目后看不到Messages或Frames内容？强制刷新视图
WebSocket连接条目点了却只显示Headers，Messages或Frames标签页空白——不是数据没发，而是Chrome有时不自动加载帧列表。
实操建议：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 先切到
Headers页，再切回Messages或Frames，多数情况能触发加载 - 确认连接已处于
open状态：看Headers里响应状态码是否为101 Switching Protocols，若还是pending或failed，说明握手卡住 - 文本帧会直接显示UTF-8字符串，二进制帧默认用
base64或十六进制呈现；右键表头可勾选Opcode和Mask，快速识别客户端发出的掩码帧（浏览器强制加Mask，服务端不加）
WSS加密连接看不到明文？别硬啃，走SSL密钥日志路线
Chrome开发者工具对wss://连接只展示帧结构（时间、长度、opcode），不暴露TLS解密后的内容。想看到原始JSON或Protobuf载荷，必须绕过浏览器界面限制。
关键步骤：
- 关闭所有Chrome进程（任务管理器里确认
chrome.exe全退出） - 命令行启动Chrome，加参数：
--ssl-key-log-file=/path/to/sslkey.log（Windows路径建议用C:\temp\sslkey.log，避免权限问题） - 在该Chrome实例中访问目标页面，复现通信
- 用Wireshark捕获
tcp.port == 443流量，导入sslkey.log后即可解密TLS层，还原WebSocket帧明文
注意：sslkey.log文件必须在Chrome启动前就存在且可写，否则日志不生成；Wireshark需开启SSL/TLS协议解析，并指定密钥日志路径。
消息发送了但Frames里没记录？检查连接状态和send调用时机
代码里写了socket.send("hello")，但Frames页始终没新消息——大概率是send执行时连接还没open。
典型场景与应对：
- 在
onopen回调外直接send：浏览器会静默丢弃，不报错也不入帧列表 - 连接因跨域失败（
Failed to construct 'WebSocket': The URL's origin is not allowed）：Headers里看不到101响应，Messages自然为空 - 服务端未正确响应
Upgrade请求（如Nginx漏配proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade）：握手卡在pending，后续send无效
最稳妥的做法：在onopen里发测试消息，并监听onmessage确认回包；onerror和onclose里打日志，避免连接异常时完全失察。
