简介这是一份面向后端开发、测试工程师及实时通信应用开发者的WebSocket测试工具合集用于验证客户端与服务端之间的全双工通信是否稳定、高效且安全。包内共19个文件以js脚本、css样式、html页面、png与gif图示为主辅以exe可执行程序、dll动态库、rar压缩包及txt说明文档整体约2.87MB涵盖在线测试页面、客户端测试工具、服务端示例与使用说明等模块。工具支持创建与断开连接、收发文本帧和二进制帧、查看连接状态、捕获分析传输数据并可用于心跳检测、性能压测与故障排查等场景。已有382人学习下载适合需要快速搭建调试环境、理解握手协议与帧结构、排查通信异常的开发者参考使用。1. websocket测试工具从连不上到压不垮一条命令先跑通你写好了 WebSocket 服务端前端同事说“连不上”运维说“连接数一上来就掉”你自己用浏览器控制台试了试发现连是连上了但消息发出去石沉大海。这时候你需要的不是翻代码而是一个趁手的 websocket 测试工具把“连接、收发、心跳、并发、断线重连”这几件事拆开单独验证。WebSocket 和普通 HTTP 接口最大的区别在于它是全双工长连接握手之后双方随时可以推消息所以测试工具要能同时扮演客户端和服务端两个角色还要能观察帧级别的内容。这篇文章面向的是正在做 websocket 实时推送数据、接口测试工具选型、或者需要自己写一个 websocket test client 的工程师。我会从最小可复现的命令行工具讲起再到 Python 脚本、浏览器端调试、心跳机制验证和并发压测每一步都给出能直接抄的代码和参数说明。不管你是刚接触 websocket 使用的新手还是想给团队搭一套渗透辅助测试工具开发里那种可编排的测试链路下面这些踩坑记录和参数边界应该都能帮你省掉几个晚上的排查时间。2. 选型命令行、脚本还是浏览器先看你要测什么2.1 三类 websocket 测试工具的适用边界很多人一上来就问“哪个 websocket 测试工具最好用”这个问题没有统一答案因为测试目标不同工具形态完全不一样。我一般按“被测对象”和“观察粒度”两个维度来分。如果你只是想知道一个 ws 地址能不能握手成功、服务端会不会主动推消息命令行工具最快一条命令就能看到帧内容。如果你要模拟业务逻辑比如带上 token、按顺序发多条消息、根据响应决定下一步那就得用 Python 或 Node.js 写脚本。如果你要验证的是前端页面在真实浏览器环境下的表现比如 react sse/websocket 轮询文件变化这种场景那浏览器 DevTools 的 Network 面板里 WS 标签页才是第一现场。命令行工具里websocat和wscat是两个最常被提到的名字。wscat是 Node.js 生态里的老牌工具安装简单交互式发消息方便。websocat功能更强支持二进制帧、代理、自动重连但参数多新手容易看花眼。我自己的习惯是快速验证用wscat需要脚本化或复杂帧操作时用websocat业务逻辑模拟用 Python 的websockets库。下面这张表是我在选型时实际对比过的几个维度你可以直接对照自己的场景选。工具安装方式交互式发消息二进制帧自动重连适合场景wscatnpm i -g wscat支持有限不支持快速握手验证、手动发文本websocat单二进制下载支持支持支持复杂帧、代理、脚本化Python websocketspip install websockets需写代码支持需写代码业务逻辑模拟、批量测试浏览器 DevTools内置支持有限不支持前端联调、观察真实帧选型时还有一个容易被忽略的点你的服务端有没有开 CORS 或者 Origin 校验。浏览器 DevTools 发起的连接会带 Origin 头而命令行工具默认不带有时候命令行能连上、浏览器连不上或者反过来就是这个问题。所以如果你测的是给前端用的 ws 接口最终一定要在浏览器里再验一遍。2.2 用 wscat 和 websocat 跑通第一次握手先装工具。Node.js 环境直接全局装wscat如果你没有 Node.js去官网下 LTS 版本这里不展开。装完之后假设你本地有一个 ws 服务在ws://127.0.0.1:8000/ws连上去的命令是# 安装 wscat npm install -g wscat # 连接本地 websocket 服务 wscat -c ws://127.0.0.1:8000/ws # 连接时带上自定义请求头比如 token wscat -c ws://127.0.0.1:8000/ws -H Authorization: Bearer test-token # 连接 wss 地址时忽略证书校验仅测试环境用 wscat -c wss://127.0.0.1:8443/ws -n连上之后终端会进入交互模式你输入一行文本回车就会作为一帧发出去服务端推过来的消息也会直接打印。-c指定地址-H加请求头-n是--no-check的简写跳过证书校验。这里有个细节wscat默认发的是文本帧如果你要发二进制帧得用websocat。websocat的安装更简单去它的发布页下对应平台的单文件二进制放到 PATH 里就行。常用命令# 连接并进入交互模式 websocat ws://127.0.0.1:8000/ws # 从标准输入读数据发过去同时打印服务端返回 echo hello | websocat ws://127.0.0.1:8000/ws # 自动重连断线后每隔 1 秒重试 websocat - autoreconnect:ws://127.0.0.1:8000/ws # 发送二进制帧-b 表示 binary websocat -b ws://127.0.0.1:8000/wswebsocat的autoreconnect:前缀是它比较实用的一个特性做断线重连验证时不用自己写循环。-b参数控制二进制模式-t是文本模式默认文本。如果你连的是wss且证书是自签的加-k跳过校验。这两个工具跑通之后你至少能确认“握手能不能成、消息能不能通”这两个最基本的问题。提示如果wscat连不上但浏览器能连上先检查服务端是不是校验了Origin头wscat默认不带 Origin可以用-H Origin: http://localhost:3000补上。3. 用 Python 写一个可复用的 websocket test client3.1 websockets 库的连接、收发与超时控制命令行工具适合手动试但一旦你要做“连接后等 5 秒没消息就发心跳”“收到特定消息后自动回复”这类逻辑就得写脚本。Python 的websockets库是目前最省心的选择异步模型清晰API 稳定。先装库pip install websockets下面是一个最小但完整的测试客户端覆盖连接、发消息、收消息、超时、关闭五个动作import asyncio import websockets async def test_client(): uri ws://127.0.0.1:8000/ws try: # open_timeout 控制握手超时ping_interval 控制心跳间隔 async with websockets.connect( uri, open_timeout5, ping_interval20, ping_timeout10, extra_headers{Authorization: Bearer test-token} ) as ws: # 发送一条文本消息 await ws.send(hello server) # 等待服务端返回最多等 3 秒 try: reply await asyncio.wait_for(ws.recv(), timeout3) print(f收到: {reply}) except asyncio.TimeoutError: print(3 秒内没有收到消息) # 主动关闭code 和 reason 会发给服务端 await ws.close(code1000, reasontest done) except websockets.exceptions.InvalidStatusCode as e: print(f握手失败状态码: {e.status_code}) except ConnectionRefusedError: print(连接被拒绝检查服务是否启动) asyncio.run(test_client())这段代码里几个参数值得展开说。open_timeout5是握手阶段的最长等待时间超过就抛异常默认是 10 秒测试环境可以调短一点快速失败。ping_interval20和ping_timeout10是库自带的保活机制每隔 20 秒发一个 ping 帧如果 10 秒内没收到 pong 就认为连接断了。这两个参数直接关系到 websocket 心跳机制实现很多“连接但不接受信息”的问题就是心跳没配对导致的。extra_headers用来带认证信息注意在旧版本里这个参数叫extra_headers新版本可能改成additional_headers装完库后看一眼版本不一致就换名字。asyncio.wait_for(ws.recv(), timeout3)是给单次接收加超时和连接级的ping_timeout不是一回事。前者控制“我等你这条消息等多久”后者控制“底层连接还活着吗”。这两个超时经常被混淆实际排查时要分开看日志。3.2 模拟心跳、断线重连与消息顺序验证真实业务里客户端通常要自己维护心跳而不是完全依赖库的 ping/pong。比如有些服务端要求客户端每 30 秒发一个 JSON 格式的{type:ping}文本帧收到{type:pong}才算活着。下面这个脚本模拟了这种应用层心跳并且带断线重连import asyncio import json import websockets async def heartbeat_client(): uri ws://127.0.0.1:8000/ws retry_delay 2 # 重连间隔秒数 while True: try: async with websockets.connect(uri, ping_intervalNone) as ws: print(已连接) # 关闭库自带 ping改用手动心跳 async def send_heartbeat(): while True: await ws.send(json.dumps({type: ping})) await asyncio.sleep(30) hb_task asyncio.create_task(send_heartbeat()) try: async for message in ws: data json.loads(message) if data.get(type) pong: print(心跳正常) else: print(f业务消息: {data}) finally: hb_task.cancel() except (websockets.exceptions.ConnectionClosed, ConnectionRefusedError) as e: print(f连接断开: {e}{retry_delay} 秒后重连) await asyncio.sleep(retry_delay) except Exception as e: print(f未知错误: {e}) break asyncio.run(heartbeat_client())这里把ping_interval设成None关掉库的自动 ping改由send_heartbeat协程每 30 秒发一条应用层心跳。为什么要这么做因为很多服务端的保活逻辑是看业务消息的底层 pong 帧它不认。async for message in ws会持续接收直到连接关闭。hb_task.cancel()放在finally里保证连接断开时心跳协程也被清理掉不然会泄漏任务。消息顺序验证是另一个高频需求。WebSocket 本身保证同一连接内消息有序但如果你在客户端并发调用ws.send()顺序就不一定了。要验证服务端是否按顺序处理可以发一批带序号的消息然后在接收端检查序号是否连续async def order_test(): async with websockets.connect(ws://127.0.0.1:8000/ws) as ws: for i in range(100): await ws.send(json.dumps({seq: i})) received [] for _ in range(100): msg await asyncio.wait_for(ws.recv(), timeout5) received.append(json.loads(msg)[seq]) # 检查是否严格递增 assert received sorted(received), 消息乱序 print(顺序验证通过) asyncio.run(order_test())await ws.send()是串行等待的所以发送顺序有保证。接收端用sorted对比如果服务端做了异步处理导致乱序这里就会断言失败。这个测试在验证“通过 websocket 发送 post 请求”这类网关场景时特别有用因为网关内部可能把消息丢到线程池处理顺序容易乱。4. 避坑连接成功但收不到消息的 5 种排查路径4.1 现象是连上了但 recv 一直阻塞这是被问得最多的一类问题现象是wscat或脚本显示连接成功但发出去的消息没有回recv一直卡着。原因通常不在 websocket 协议本身而在服务端的业务逻辑或中间层。我按排查顺序列几条。第一条检查服务端是不是在等客户端先发消息。有些实现是“客户端连上后服务端不主动推必须客户端先发一个订阅指令”。用wscat手动发一条{type:subscribe}试试如果回了就是协议约定问题不是连接问题。第二条检查消息是不是被压缩或分帧了。WebSocket 支持permessage-deflate扩展如果服务端开了压缩而客户端没开或者反过来消息可能被静默丢弃。websocat可以用--compress强制开启Python 库默认协商一般不用管但如果你用裸 socket 手写握手就要注意Sec-WebSocket-Extensions头。第三条检查代理或网关有没有缓冲。Nginx 反代 WebSocket 时如果proxy_buffering没关消息可能被攒着不发。配置里要有proxy_buffering off;和proxy_set_header Upgrade $http_upgrade;。这个坑在“websocket 连接但不接受信息”的搜索里出现频率极高。第四条检查服务端是不是把消息发到了错误的连接上。多房间、多用户场景下如果服务端用连接 ID 做路由而客户端重连后 ID 变了消息就会发到旧连接。表现就是“刚连上能收过一会儿收不到”。解决方法是重连后重新订阅。第五条检查防火墙或负载均衡的空闲超时。有些云负载均衡默认 60 秒没数据就断连而客户端和服务端都以为连接还在。表现是“每隔一分钟左右就收不到消息”。解决办法是把心跳间隔设得比空闲超时短比如 30 秒。4.2 现象是握手返回 400 或 403握手阶段失败状态码直接告诉你原因。400 通常是请求头不合法比如Sec-WebSocket-Key缺失或Upgrade头不对。用wscat时如果地址写成了http://而不是ws://也会 400。403 一般是鉴权失败或 Origin 被拒。浏览器里连不上但命令行能连上九成是 Origin 校验。服务端如果只允许特定域名命令行工具默认不带 Origin反而能过浏览器带了 Origin反而被拒。反过来如果服务端要求必须带 Origin命令行就要手动加-H Origin: ...。还有一个隐蔽的 403 来源是路径大小写。/ws和/WS在某些框架里路由不匹配但错误信息不会明说。用curl -i先探一下 HTTP 升级请求能看到更详细的响应头curl -i -N \ -H Connection: Upgrade \ -H Upgrade: websocket \ -H Sec-WebSocket-Version: 13 \ -H Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ \ http://127.0.0.1:8000/ws如果返回 101说明握手逻辑没问题问题在后续帧如果返回 4xx响应体里通常有原因。这个命令在排查 CORS 测试工具相关问题时也常用因为 WebSocket 握手不受 CORS 限制但服务端可能自己做了 Origin 白名单。4.3 现象是压测时连接数上不去用脚本开几百个并发连接时经常遇到“开到 200 个就卡住”或者“报 Too many open files”。前者通常是服务端的连接数限制或文件描述符限制后者是客户端本机的限制。Linux 下ulimit -n默认可能是 1024每个 WebSocket 连接占一个 fd开到 1000 左右就满了。临时调大ulimit -n 65535服务端如果是 Nginx还要看worker_connections配置。另外Python 的asyncio默认事件循环在某些平台上对高并发连接处理不够好可以换uvlooppip install uvloop然后在代码开头加import uvloop uvloop.install()压测时还要注意每个连接如果都发心跳总消息量是连接数乘以频率服务端可能先被消息量打垮而不是连接数。我一般先用空连接压到目标数量确认连接层没问题再逐步加消息频率。4.4 现象是消息发出去但服务端说格式错误WebSocket 帧分文本和二进制文本帧的 payload 必须是合法 UTF-8。如果你用websocat -b发了二进制但服务端按文本解析就会报格式错误。反过来如果服务端期望二进制比如 protobuf你用文本发也会失败。排查时先用wscat发一条纯 ASCII 文本确认通道没问题再换二进制。Python 里发二进制用await ws.send(b\x01\x02)发文本用await ws.send(text)类型不对库会直接报错不会静默。另一个格式坑是 JSON 里的换行。有些服务端按行解析如果你发的 JSON 带换行会被截断。发之前用json.dumps(data, separators(,, :))压成一行。4.5 现象是 wss 连接报证书错误测试环境用自签证书时wscat加-nwebsocat加-kPython 库加sslssl._create_unverified_context()。但要注意跳过证书校验只应该出现在测试环境生产环境必须校验。如果你在代码里硬编码了跳过校验上线前记得改回来。这个坑属于“后悔药”类型的出事就是大事。5. 进阶把测试工具变成可编排的验证链路5.1 用 pytest 把 websocket 测试纳入 CI手动跑脚本只能验证一次要长期保证服务端行为不变得把测试写成用例。pytest配合pytest-asyncio可以很好地组织 WebSocket 测试。先装pip install pytest pytest-asyncio然后写一个测试文件import pytest import json import websockets pytest.mark.asyncio async def test_echo(): async with websockets.connect(ws://127.0.0.1:8000/ws) as ws: await ws.send(ping) reply await ws.recv() assert reply pong pytest.mark.asyncio async def test_heartbeat(): async with websockets.connect(ws://127.0.0.1:8000/ws) as ws: await ws.send(json.dumps({type: ping})) reply json.loads(await ws.recv()) assert reply[type] pongpytest.mark.asyncio告诉 pytest 这是异步用例pytest-asyncio负责跑事件循环。每个用例独立连接、独立关闭互不影响。CI 里跑之前要确保服务端已经启动可以用fixture做前置启动或者用docker-compose起一套环境。这种组织方式比散落的脚本好维护也方便统计通过率。5.2 用 websocat 做服务端模拟验证客户端重连逻辑前面都是测服务端反过来测客户端时你需要一个可控的服务端。websocat可以监听端口并回显消息# 监听 9000 端口把收到的消息原样发回 websocat -s 9000 # 监听并每隔 5 秒主动推一条消息 websocat -s 9000 --exec while true; do echo server push; sleep 5; done-s是 server 模式--exec后面跟一个命令命令的输出会作为消息推给客户端。用这个可以模拟“服务端主动推送”和“服务端突然断开”两种场景。验证客户端重连时先让客户端连上然后 CtrlC 杀掉websocat观察客户端是否按预期重连。这个手法在验证 react sse/websocket 轮询文件变化这类前端逻辑时特别直观因为你可以精确控制服务端什么时候推、什么时候断。5.3 参数速查与验证清单最后给一张我常用的参数速查表覆盖连接、心跳、超时、重连四个维度。每次搭新测试环境时对着过一遍能省不少排查时间。参数作用常用值调错后果open_timeout握手超时5s太短误报失败太长卡住ping_interval底层 ping 间隔20s大于空闲超时会被断连ping_timeout等 pong 超时10s太短误判断线close_timeout关闭握手超时5s太长导致进程退出慢max_size单帧最大字节1MB太小收大消息报错retry_delay重连间隔2s太短打爆服务端验证清单我一般按这个顺序走先用wscat确认握手再用 Python 脚本确认收发然后开两个客户端确认广播接着模拟断线确认重连最后用pytest固化下来。每一步都过了这个 websocket 接口才算真正测完。我自己踩过最深的坑是心跳间隔设得比负载均衡空闲超时还长表现是“测试环境一切正常上了预发每隔一分钟断一次”查了两天才定位到。所以现在不管什么环境心跳间隔一律先设 30 秒再根据实际超时调整。希望帮到你。本文还有配套的精品资源点击获取