chrome开发者工具原生支持websocket调试，关键帧级信息在network面板frames标签页中直接可见；需确保连接已建立、过滤器设为ws或勾选ws、type列显示websocket。
Chrome开发者工具原生支持WebSocket调试，不需要装插件、不依赖Wireshark或Fiddler，所有关键帧级信息都在Network面板里直接可见——前提是连接已触发、过滤设置正确、Frames标签页被主动打开。
Network面板里找不到WebSocket连接？检查这三件事
不是工具失效，而是连接没被“捕获”到。常见原因包括：
- WebSocket连接尚未建立：页面加载后未调用
new WebSocket()，或JS执行被阻塞（比如报错中断） - 过滤器没开：Network面板左上角筛选框必须输入
ws或勾选WS复选框（部分Chrome版本需手动勾选） - Type列未显示：右键Network表头，确认勾选了
Type列——真正的WebSocket请求Type值是websocket，不是fetch或xhr
如果Initiator列显示chat.js:42这类路径，说明连接来自该文件第42行，可快速回溯代码上下文。
Messages标签页为空？切换到Frames标签页再看
Chrome 117+版本中，“Messages”标签页已被重命名为Frames，且是唯一能查看实际数据帧的地方。旧教程提到的“Messages”在新版里已不可见。
点击WebSocket请求条目后，务必切换到Frames子标签页。这里会列出所有帧，每条带明确标识：
-
client或server：标明方向 -
Text/Binary/Close：帧类型，JSON消息一定是Text，Protobuf通常是Binary - 时间戳精确到毫秒，可用于分析延迟是否集中在某次send之后
若仍为空，先发一条测试消息（如socket.send("ping")），再刷新Frames视图——有时需手动触发重载。
看到乱码或二进制数据？别急着导出，先点开解码
Chrome对Binary帧提供内置解码视图，无需外部工具：
- 点击某条
Binary帧，在右侧展开区能看到ArrayBuffer、Hex、UTF-8三种视图切换按钮 - 如果服务端用
Uint8Array发送结构化数据，选Hex更易识别协议头（比如前4字节是否为预期magic number） - JSON字符串误传为Binary时，切到
UTF-8视图常能直接读出明文，说明序列化逻辑有误
注意：Hex视图显示的是原始字节，不是Base64编码；若看到大量00或重复模式，大概率是未压缩的图像/音频流或内存填充残留。
连接建立慢或频繁断开？去Timing和Headers里挖根因
WebSocket握手失败或延迟高，问题往往不在JS代码里，而在网络或服务端配置：
-
Timing标签页：重点看TLS Setup（WSS下耗时过长说明证书链或OCSP响应慢）、Waiting (TTFB)（服务器处理Upgrade请求超时） -
Headers标签页：检查响应头是否有Sec-WebSocket-Accept，缺失说明服务端未正确实现WebSocket握手；若含Connection: close，可能是反向代理（如Nginx）未配置upgrade指令 - 断开时无error事件？查看
Frames末尾是否有Close帧，并记录其code（如1006=异常关闭，1001=服务端退出）
真正容易被忽略的是：Chrome不会记录连接断开后的帧，所以一旦发现Close帧，要立刻截图或复制内容——它不会保留在历史记录里。
