WebSocket连接需用专用库（如websocket-client）而非requests，因其是长连接协议；须手动处理回调、心跳、认证及JS动态参数逆向。
WebSocket连接不是HTTP请求，不能用requests抓
requests库只处理HTTP/HTTPS单次请求响应，而WebSocket是长连接、双向通信协议。直接对ws://或wss://地址发requests.get()会报InvalidURL或ConnectionError——这不是代理或证书问题，是协议根本不支持。
必须换用专门的WebSocket客户端库。主流选择是websocket-client（同步）或websockets（异步），前者更轻量、调试友好，后者适合高并发场景。
- 安装：
pip install websocket-client - 不要尝试用Selenium + DevTools Protocol模拟WebSocket：它不暴露原始帧，且无法稳定捕获send/receive时序
- 浏览器F12里看到的“WS”标签页只是调试视图，实际数据帧未经过HTTP中间层，抓包工具（如Charles/Fiddler）默认也看不到——需启用WebSocket流量捕获（部分工具需插件或高级版）
用websocket-client监听消息要手动处理on_message和异常重连
WebSocket连接不稳定，网络抖动、服务端心跳超时、鉴权过期都会导致断连。仅靠ws.run_forever()不够，必须显式定义on_open、on_message、on_error、on_close回调，并在on_error和on_close里触发重连逻辑。
示例关键片段：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import websocket
import time
<p>def on_message(ws, message):
print("收到:", message)</p><p>def on_error(ws, error):
print("错误:", error)</p><p>def on_close(ws, close_status_code, close_msg):
print("连接关闭")</p><p>def on_open(ws):
print("已连接")</p><h1>有些服务需要先发认证消息</h1><pre class='brush:python;toolbar:false;'>ws.send('{"type":"auth","token":"xxx"}')if name == "main": ws = websocket.WebSocketApp( "wss://example.com/ws", on_open=on_open, on_message=on_message, on_error=on_error, on_close=on_close ) ws.run_forever(ping_interval=30, ping_timeout=10) # 主动心跳防断连
-
ping_interval和ping_timeout必须设，否则多数服务端30–60秒无心跳就强制断开 - 服务端返回的
message通常是JSON字符串，需用json.loads()解析，别直接当字典用 - 如果服务端要求先发认证帧才能收数据，漏掉
ws.send()会导致一直收不到消息——这不是连接失败，而是被静默拦截
抓取真实业务数据前，先确认WebSocket是否受前端逻辑控制
很多网站的WebSocket连接由前端JavaScript动态建立，URL、参数、初始消息都通过JS计算生成（比如含时间戳、签名、加密token）。直接硬编码wss://xxx可能连不上，或连上后被服务端拒绝。
必须逆向分析前端代码：
- 在浏览器Network → WS → 点击连接 → 查看Headers里的
Request URL，注意查询参数（如?token=xxx&ts=171...&sign=yyy） - 搜索页面源码或Source面板中的
new WebSocket(，定位构造URL的JS逻辑 - 常见陷阱：sign是用当前时间+密钥+其他字段拼接后HMAC-SHA256，每次连接都要重算；token可能从Cookie或localStorage读取，需同步提取
- 若JS做了混淆或依赖运行时环境（如webpack模块），可用Puppeteer/Playwright启动真实浏览器，用
page.evaluate()执行JS获取连接参数，再传给Python客户端
多线程/多协程并发连多个WebSocket时，连接数和服务端限制是瓶颈
每个WebSocket连接占用一个TCP socket和线程/协程资源。websocket-client是同步阻塞模型，100个连接就得开100个线程，极易触发系统文件描述符上限或服务端IP频控。
- Linux下默认
ulimit -n常为1024，单机连200+连接大概率报OSError: [Errno 24] Too many open files - 服务端通常限制单IP每分钟建连次数（如5次）、单IP最大并发连接数（如10个），超限直接拒绝或封禁
- 解决思路：用
websockets+ asyncio做协程复用；或加连接池+退避重试（指数级延迟）；必要时分散到多台机器或代理IP - 别忽略服务端心跳响应——某些场景下，不及时回复pong帧会被当成死连接踢出，导致看似“连着”实则收不到新数据
真正难的不是连上，而是让连接活下来、消息不丢、参数跟得上前端变化。这些细节藏在JS里、服务端策略里、网络波动里，不在文档里。
