抖音直播弹幕抓取实战WebSocket逆向与实时数据管道【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcherDouyinLiveWebFetcher 是一个抖音直播弹幕抓取的开源 Python 工具。它逆向抖音直播网页版的 WebSocket 长连接与 Protobuf 推送协议把聊天、礼物、点赞、进场、房间统计等消息实时解析成结构化数据帮你搭出自己的直播数据监控与分析管道。一句话讲清这个抖音直播数据抓取工具解决什么问题抖音直播弹幕抓取实时输出终端截图占位你如果之前自己抓过直播间大概率干过这些事起个浏览器渲染页面用选择器抠 DOM再每隔几秒轮询一次。页面一改版脚本就废数据也永远慢半拍。这个工具的解法是把轮询换成订阅——直接连上抖音直播间自己的 WebSocket 推送通道消息到了就推给你。自己爬网页用 DouyinLiveWebFetcher数据来源页面 DOM / HTMLWebSocket 服务端实时推送数据时效轮询秒级甚至更慢消息到达即触发接近实时能拿到的内容页面渲染出来的部分礼物、点赞、粉丝团、统计等 10 种消息维护成本页面改版就改选择器协议字段相对稳定新增类型好扩展数据形态非结构化文本Protobuf 解析后的结构化字段典型用法有这么几类内容审核实时过一遍聊天消息命中敏感词立刻告警直播电商统计礼物、进场、点赞节奏分析带货时段的转化表现行为分析留存观看人数、累计观看等统计消息画直播间的流量曲线 五分钟跑通从克隆到第一行实时数据先克隆仓库并装依赖整个过程就三条命令git clone https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher cd DouyinLiveWebFetcher pip install -r requirements.txt可选步骤如果你以后要调用get_room_status内部走 PyExecJS 执行 a_bogus 签名需要装 Node.js主链路签名由 mini_racer 完成不依赖 Node。最小可运行示例在 main.py 里核心就三行——直播间地址https://live.douyin.com/xxx末尾的数字就是live_idfrom liveMan import DouyinLiveWebFetcher live_id 510200350291 # 换成任意正在直播的直播间 room DouyinLiveWebFetcher(live_id) room.start()运行后你会看到这样的输出取自 README 抓取样例【√】WebSocket连接成功. 【进场msg】[79026102598][男]尘埃 进入了直播间 【礼物msg】X L 送出了 为你点亮x1 【点赞msg】小程๑ 点了9个赞 【统计msg】当前观看人数: 22164, 累计观看人数: 43.6万 【聊天msg】[67197561586]说谎: 去拿 去拿去哪唯一要改的关键配置就是live_id心跳间隔5 秒写死在_sendHeartbeat里需要调整直接改time.sleep(5)那个数字即可。拆开看 WebSocket 逆向的原理一条连接如何喂活整个直播流这部分是全文最硬核的但别怕就三步连上、解开、分发。第一步建立连接——从 live_id 到带签名的 wss 地址这一步在干嘛把直播间链接里的数字翻译成服务器愿意让你连的 WebSocket 地址。它先请求抖音网页版首页拿ttwidcookie再请求房间页用正则抠出真正的room_id然后拼装出完整的 wss 推送地址。关键卡点是签名服务器要求 URL 里带一个signature参数它由 14 个参数的 MD5 值送进sign.js里一段被混淆的 JS 算出来项目用 mini_racer 直接执行这段 JS不用装 Node。wss wss://webcast100-ws-web-lq.douyin.com/webcast/im/push/v2/?... # 推送地址 signature generateSignature(wss) # 参数拼 MD5 后送 sign.js 计算 wss fsignature{signature} headers {cookie: fttwid{self.ttwid}, user-agent: self.user_agent} self.ws websocket.WebSocketApp(wss, headerheaders, on_openself._wsOnOpen, on_messageself._wsOnMessage) self.ws.run_forever()连上之后还会起一个心跳线程每 5 秒发一个payload_typehb的PushFrame保活防止空闲连接被服务端掐掉。完整链路在 liveMan.py 的_connectWebSocket里签名算法在 sign.js。第二步解析数据——二进制流怎么变成 Python 对象这一步在干嘛WebSocket 推过来的是压缩过的二进制不是 JSON。外层信封叫PushFrameProtobuf 结构字段包括 log_id、payload_type、payload 等里面的payload还要先 gzip 解压再解出真正的Response里面装着本次推送的所有消息列表。另外服务端有时会在响应里标记need_ack意思是收到请回执项目会立刻回发一个ack帧否则连接会被认为异常。def _wsOnMessage(self, ws, message): package PushFrame().parse(message) # 拆外层信封 response Response().parse(gzip.decompress(package.payload)) # 解压再解内层 if response.need_ack: # 服务端要求回执 ack PushFrame(log_idpackage.log_id, payload_typeack, payloadresponse.internal_ext.encode()).SerializeToString() ws.send(ack, websocket.ABNF.OPCODE_BINARY)所有协议类定义在 protobuf/douyin.py它是从 protobuf/douyin.proto 用 betterproto 生成的不用手写字节级解析。第三步消息分发——按 method 各归各家这一步在干嘛Response里的每条Message都带一个method字段比如WebcastChatMessage代表聊天、WebcastGiftMessage代表礼物。项目用一张method → 解析函数的字典做分发每个解析函数内部再解一次各自的 Protobuf 消息体取昵称、内容、礼物数这些字段后打印。整个循环包在 try/except 里单条消息解析失败被静默跳过不会打断整条连接。for msg in response.messages_list: { WebcastChatMessage: self._parseChatMsg, # 聊天 WebcastGiftMessage: self._parseGiftMsg, # 礼物 WebcastLikeMessage: self._parseLikeMsg, # 点赞 WebcastMemberMessage: self._parseMemberMsg, # 进场 WebcastRoomUserSeqMessage: self._parseRoomUserSeqMsg, # 房间统计 # ... 粉丝团、关注、直播间状态等类型同理 }.get(msg.method)(msg.payload)分发逻辑同样在 liveMan.py 的_wsOnMessage里想加新消息类型就在这张表里加一行再写个_parseXxxMsg。你能拿它做什么直播数据管道的四种扩展实时敏感词审核在_parseChatMsg里把print换成你自己的关键词匹配命中违规词立刻推告警。适合内容安全团队。多直播间并行采集一个实例对应一个live_id开多个DouyinLiveWebFetcher实例放进线程池即可对比多个房间。注意控制总连接数。适合竞品分析或 MCN 运营。封装成数据 API让采集进程常驻把各_parseXxxMsg的输出写入 Redis、Kafka 或数据库外面再套一层 Flask/FastAPI 做查询接口。适合数据产品团队。直播电商转化分析GiftMessage带礼物名和连击数LikeMessage带点赞数按时间落库后就能统计各时段的打赏热度与互动节奏。适合电商数据分析师。以上扩展思路来自项目独立实例 回调式解析方法的设计模式具体实现需自行适配。 跑稳了开源直播数据工具的部署、调优与踩坑笔记常驻运行要点项目本身是单进程长驻任务run_forever()维持连接5 秒心跳保活简单场景nohup python main.py 即可生产建议丢进容器或 systemd 服务配自动重启直播间下播时WebcastControlMessage的 status3 处理会自动调stop()关闭连接不用你手动清理依赖 Python 3.7签名主链路走 mini_racer不依赖 Node.js性能调优的几个抓手现象调整方向长时间运行后无数据先看心跳日志是否还在再查网络/代理是否掉线内存缓慢增长别在内存里攒消息列表改成边收边落盘大房间消息量高、CPU 飙减少打印/落盘频率或对低价值消息采样连接建立偶发失败检查 live_id 有效性、房间是否在播失败重试签名报错 / 连接被拒更新到最新代码取新的签名逻辑常见问题速查Q连上了却没数据或者立刻被断开A先确认live_id正确且房间正在直播再看网络环境能否正常访问抖音公司代理、防火墙常是元凶。Q签名报错、连接被拒A平台会不定期更新签名算法拉最新代码替换 sign.js 即可。README 里维护了历次测试成功日期可以对照判断你的版本是否过期。QWindows 控制台报编码错A是 GBK 与 UTF-8 混用导致的代码注释里给了办法把subprocess.Popen的encoding参数设为 utf-8。Q运行一段时间后内存一直在涨A项目默认只打印不缓存本身不会涨如果你加了消息列表缓存改成流式写出或给缓存设上限。Q某类消息解析出空字段A多半是 protobuf 协议加了字段对照 protobuf/douyin.proto 更新定义并重新生成 douyin.py。这个项目把连接、签名、解析这些最脏最累的活都干完了剩下的就是把你业务逻辑接进那些_parseXxxMsg。建议从 liveMan.py 的分发字典读起跑不通就去提 Issue。【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 抖音直播弹幕抓取实战：WebSocket逆向与实时数据管道
抖音直播弹幕抓取实战WebSocket逆向与实时数据管道【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcherDouyinLiveWebFetcher 是一个抖音直播弹幕抓取的开源 Python 工具。它逆向抖音直播网页版的 WebSocket 长连接与 Protobuf 推送协议把聊天、礼物、点赞、进场、房间统计等消息实时解析成结构化数据帮你搭出自己的直播数据监控与分析管道。一句话讲清这个抖音直播数据抓取工具解决什么问题抖音直播弹幕抓取实时输出终端截图占位你如果之前自己抓过直播间大概率干过这些事起个浏览器渲染页面用选择器抠 DOM再每隔几秒轮询一次。页面一改版脚本就废数据也永远慢半拍。这个工具的解法是把轮询换成订阅——直接连上抖音直播间自己的 WebSocket 推送通道消息到了就推给你。自己爬网页用 DouyinLiveWebFetcher数据来源页面 DOM / HTMLWebSocket 服务端实时推送数据时效轮询秒级甚至更慢消息到达即触发接近实时能拿到的内容页面渲染出来的部分礼物、点赞、粉丝团、统计等 10 种消息维护成本页面改版就改选择器协议字段相对稳定新增类型好扩展数据形态非结构化文本Protobuf 解析后的结构化字段典型用法有这么几类内容审核实时过一遍聊天消息命中敏感词立刻告警直播电商统计礼物、进场、点赞节奏分析带货时段的转化表现行为分析留存观看人数、累计观看等统计消息画直播间的流量曲线 五分钟跑通从克隆到第一行实时数据先克隆仓库并装依赖整个过程就三条命令git clone https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher cd DouyinLiveWebFetcher pip install -r requirements.txt可选步骤如果你以后要调用get_room_status内部走 PyExecJS 执行 a_bogus 签名需要装 Node.js主链路签名由 mini_racer 完成不依赖 Node。最小可运行示例在 main.py 里核心就三行——直播间地址https://live.douyin.com/xxx末尾的数字就是live_idfrom liveMan import DouyinLiveWebFetcher live_id 510200350291 # 换成任意正在直播的直播间 room DouyinLiveWebFetcher(live_id) room.start()运行后你会看到这样的输出取自 README 抓取样例【√】WebSocket连接成功. 【进场msg】[79026102598][男]尘埃 进入了直播间 【礼物msg】X L 送出了 为你点亮x1 【点赞msg】小程๑ 点了9个赞 【统计msg】当前观看人数: 22164, 累计观看人数: 43.6万 【聊天msg】[67197561586]说谎: 去拿 去拿去哪唯一要改的关键配置就是live_id心跳间隔5 秒写死在_sendHeartbeat里需要调整直接改time.sleep(5)那个数字即可。拆开看 WebSocket 逆向的原理一条连接如何喂活整个直播流这部分是全文最硬核的但别怕就三步连上、解开、分发。第一步建立连接——从 live_id 到带签名的 wss 地址这一步在干嘛把直播间链接里的数字翻译成服务器愿意让你连的 WebSocket 地址。它先请求抖音网页版首页拿ttwidcookie再请求房间页用正则抠出真正的room_id然后拼装出完整的 wss 推送地址。关键卡点是签名服务器要求 URL 里带一个signature参数它由 14 个参数的 MD5 值送进sign.js里一段被混淆的 JS 算出来项目用 mini_racer 直接执行这段 JS不用装 Node。wss wss://webcast100-ws-web-lq.douyin.com/webcast/im/push/v2/?... # 推送地址 signature generateSignature(wss) # 参数拼 MD5 后送 sign.js 计算 wss fsignature{signature} headers {cookie: fttwid{self.ttwid}, user-agent: self.user_agent} self.ws websocket.WebSocketApp(wss, headerheaders, on_openself._wsOnOpen, on_messageself._wsOnMessage) self.ws.run_forever()连上之后还会起一个心跳线程每 5 秒发一个payload_typehb的PushFrame保活防止空闲连接被服务端掐掉。完整链路在 liveMan.py 的_connectWebSocket里签名算法在 sign.js。第二步解析数据——二进制流怎么变成 Python 对象这一步在干嘛WebSocket 推过来的是压缩过的二进制不是 JSON。外层信封叫PushFrameProtobuf 结构字段包括 log_id、payload_type、payload 等里面的payload还要先 gzip 解压再解出真正的Response里面装着本次推送的所有消息列表。另外服务端有时会在响应里标记need_ack意思是收到请回执项目会立刻回发一个ack帧否则连接会被认为异常。def _wsOnMessage(self, ws, message): package PushFrame().parse(message) # 拆外层信封 response Response().parse(gzip.decompress(package.payload)) # 解压再解内层 if response.need_ack: # 服务端要求回执 ack PushFrame(log_idpackage.log_id, payload_typeack, payloadresponse.internal_ext.encode()).SerializeToString() ws.send(ack, websocket.ABNF.OPCODE_BINARY)所有协议类定义在 protobuf/douyin.py它是从 protobuf/douyin.proto 用 betterproto 生成的不用手写字节级解析。第三步消息分发——按 method 各归各家这一步在干嘛Response里的每条Message都带一个method字段比如WebcastChatMessage代表聊天、WebcastGiftMessage代表礼物。项目用一张method → 解析函数的字典做分发每个解析函数内部再解一次各自的 Protobuf 消息体取昵称、内容、礼物数这些字段后打印。整个循环包在 try/except 里单条消息解析失败被静默跳过不会打断整条连接。for msg in response.messages_list: { WebcastChatMessage: self._parseChatMsg, # 聊天 WebcastGiftMessage: self._parseGiftMsg, # 礼物 WebcastLikeMessage: self._parseLikeMsg, # 点赞 WebcastMemberMessage: self._parseMemberMsg, # 进场 WebcastRoomUserSeqMessage: self._parseRoomUserSeqMsg, # 房间统计 # ... 粉丝团、关注、直播间状态等类型同理 }.get(msg.method)(msg.payload)分发逻辑同样在 liveMan.py 的_wsOnMessage里想加新消息类型就在这张表里加一行再写个_parseXxxMsg。你能拿它做什么直播数据管道的四种扩展实时敏感词审核在_parseChatMsg里把print换成你自己的关键词匹配命中违规词立刻推告警。适合内容安全团队。多直播间并行采集一个实例对应一个live_id开多个DouyinLiveWebFetcher实例放进线程池即可对比多个房间。注意控制总连接数。适合竞品分析或 MCN 运营。封装成数据 API让采集进程常驻把各_parseXxxMsg的输出写入 Redis、Kafka 或数据库外面再套一层 Flask/FastAPI 做查询接口。适合数据产品团队。直播电商转化分析GiftMessage带礼物名和连击数LikeMessage带点赞数按时间落库后就能统计各时段的打赏热度与互动节奏。适合电商数据分析师。以上扩展思路来自项目独立实例 回调式解析方法的设计模式具体实现需自行适配。 跑稳了开源直播数据工具的部署、调优与踩坑笔记常驻运行要点项目本身是单进程长驻任务run_forever()维持连接5 秒心跳保活简单场景nohup python main.py 即可生产建议丢进容器或 systemd 服务配自动重启直播间下播时WebcastControlMessage的 status3 处理会自动调stop()关闭连接不用你手动清理依赖 Python 3.7签名主链路走 mini_racer不依赖 Node.js性能调优的几个抓手现象调整方向长时间运行后无数据先看心跳日志是否还在再查网络/代理是否掉线内存缓慢增长别在内存里攒消息列表改成边收边落盘大房间消息量高、CPU 飙减少打印/落盘频率或对低价值消息采样连接建立偶发失败检查 live_id 有效性、房间是否在播失败重试签名报错 / 连接被拒更新到最新代码取新的签名逻辑常见问题速查Q连上了却没数据或者立刻被断开A先确认live_id正确且房间正在直播再看网络环境能否正常访问抖音公司代理、防火墙常是元凶。Q签名报错、连接被拒A平台会不定期更新签名算法拉最新代码替换 sign.js 即可。README 里维护了历次测试成功日期可以对照判断你的版本是否过期。QWindows 控制台报编码错A是 GBK 与 UTF-8 混用导致的代码注释里给了办法把subprocess.Popen的encoding参数设为 utf-8。Q运行一段时间后内存一直在涨A项目默认只打印不缓存本身不会涨如果你加了消息列表缓存改成流式写出或给缓存设上限。Q某类消息解析出空字段A多半是 protobuf 协议加了字段对照 protobuf/douyin.proto 更新定义并重新生成 douyin.py。这个项目把连接、签名、解析这些最脏最累的活都干完了剩下的就是把你业务逻辑接进那些_parseXxxMsg。建议从 liveMan.py 的分发字典读起跑不通就去提 Issue。【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考