打开浏览器控制台，测试敲下 `new WebSocket('wss://echo.websocket.org')`，测试回车。测试如果状态码变成 101，测试说明握手成功。测试这就是测试最原始的 WebSocket 在线测试——不需要任何工具，浏览器自带的测试就是最直接的调试器。
但很多人不知道的测试是，`echo.websocket.org` 这个老牌公共测试服务已经关停过一轮，测试后来由 Lob 公司接手才恢复运行。测试我去年帮一个前端新人排查问题，测试他死活连不上，测试最后发现用的测试是已经失效的旧域名。这种坑，测试只有真正动手测过的测试人才会踩到。
在线测试工具到底在测什么
市面上常见的 WebSocket 在线测试平台，比如 PieSocket 的在线客户端、WebSocket King、Postman 的 WebSocket 面板，核心功能就三件事：建立连接、收发消息、查看帧数据。
听起来简单，但实际用起来差别很大。PieSocket 的界面清爽，适合快速验证接口通不通；Postman 的优势在于能把 WebSocket 请求和 HTTP 请求放在同一个项目里管理，调试全栈应用时不用来回切工具；WebSocket King 则支持自定义握手头，测鉴权逻辑时特别顺手。
我自己的习惯是：临时测公共 echo 服务用浏览器控制台，测自己项目的私有协议用 Postman，需要模拟复杂握手场景才打开 WebSocket King。工具没有绝对好坏，看你当下要解决什么问题。
一个真实案例：心跳包没发导致连接断开
上个月有个做物联网平台的朋友找我，说设备端 WebSocket 连上后大概 60 秒就断，但用在线测试工具手动发消息又正常。我让他把在线工具的心跳间隔调到 30 秒再试——果然稳定了。
问题出在 Nginx 的 `proxy_read_timeout` 默认 60 秒，连接上没有数据流动就会被代理层掐断。手动发消息相当于人为制造了数据流，所以看起来“正常”。在线测试工具如果支持自动心跳，这种问题几秒钟就能定位。可惜很多免费工具没这个功能，得自己写个 `setInterval` 往控制台里跑。
浏览器控制台才是被低估的测试利器
const ws = new WebSocket('wss://ws.postman-echo.com/raw'); ws.onopen = () => ws.send('hello'); ws.onmessage = (e) => console.log('收到:', e.data); ws.onclose = (e) => console.log('关闭码:', e.code, '原因:', e.reason);这段代码我用了不下五十次。`onclose` 事件里的 `code` 和 `reason` 是排查问题的关键——1000 是正常关闭，1006 是异常断开，4000 系列是服务端自定义的业务错误码。在线工具通常只显示“已断开”，而控制台能告诉你为什么断。
还有个细节：Chrome DevTools 的 Network 面板里，WebSocket 连接会以 101 状态码出现，点进去能看到每一帧的发送和接收数据，包括 Ping/Pong 帧。这个视角比任何第三方在线工具都底层。
选工具时注意两个坑
第一，确认工具是否支持 `wss://`。有些免费在线测试页面只允许 `ws://`，测生产环境直接歇菜。第二，注意消息格式。WebSocket 可以传文本也可以传二进制，在线工具如果默认按文本处理，你发过去的 ArrayBuffer 可能被转成乱码字符串，服务端解析直接报错。
我一般会先用在线工具发一条纯文本的 `ping`，确认链路通了，再切到代码里测二进制协议。这个顺序能省不少来回折腾的时间。
说到底，WebSocket 在线测试工具解决的是“快速验证”的需求，不是“全面调试”。真要深入排查，浏览器控制台加抓包工具的组合拳，比任何在线页面都可靠。工具是死的，知道什么时候该用哪个，才是活的。