YY直播接口调用实战：网页抓包、WebSocket弹幕与常见坑

简介面向需要接入YY直播能力的开发者此压缩包提供了一套可直接部署的前端调用方案覆盖接口请求、页面交互与直播状态控制等常见场景适合具备基础HTML/JS知识、希望快速落地直播功能的工程师参考。包内共12个文件以3个CSS、3个JS和1个HTML为主配合若干图片资源构成完整页面骨架其中JS主要负责封装接口调用与动态渲染CSS用于界面布局HTML提供入口结构整体仅122KB轻量易部署。目前已有201人学习浏览。压缩包重点演示了YY接口获取直播数据、播放器控制、礼物及弹幕交互等逻辑并附有示例代码和注释开发者可基于自己的直播间信息直接修改参数后上传使用也可将调用思路迁移至其他直播平台。1. YY接口调用这套“最新.rar”到底解决什么问题做直播运营或数据监控的人大概率见过“YY调用最新.rar”这类压缩包朋友甩过来说是别人整理好的YY接口调用工具集。接手的第一反应通常是怀疑——里面到底是能跑的代码、抓包整理的接口文档还是带密码的过期脚本先说结论这类包的本质是把 YY直播官方叫 YY 直播域名 yy.com的网页接口和房间协议封装成一套可直接调用的“客户端 SDK 替代品”用来读房间信息、拉弹幕、盯主播上下播、同步礼物榜数据。它适合三类人给主播做自动播报机器人的小团队、做弹幕分析的运营、需要把 YY 数据接进内部告警大屏的后端。问题是 YY 并没有向个人开放一套免费通用的开放接口绝大多数实用接口走的是网页端登录态所以这套包的价值和坑都在同一个地方它把抓包结果、签名参数、心跳协议替你整理好了但倒在你面前的坑它不会替你写完。2. YY接口调用的三条技术路线官方开放平台、网页接口与房间私有协议拿到一个“YY调用最新.rar”后第一件事不是急着解压跑脚本而是先搞清楚包里的代码走的是哪一条调用路线。YY 直播的接口调用目前能走的路基本就三条官方开放平台、网页端 XHR/Fetch 接口、房间私有 WebSocket 协议。它们的目标、难度和合规边界完全不一样选错了路后面所有代码都是在给别人的接口打工。2.1 官方开放接口为什么“看得到却申请不下来”YY 是有开放平台的入口在 open.yy.com提供账号授权OAuth、部分直播数据和开发者文档。从接口调用角度说它是最正规的一条路文档齐全、鉴权流程清晰理论上支持 API 调用工具直接对接。但现实是它的开放范围偏向企业级合作需要企业资质、填写应用场景、走人工审核权限粒度也小。个人开发者想申请一个“读取任意房间在线人数”的接口权限大概率会被以“场景不明确”打回来。所以我的判断是官方接口适合把它当作背景知识不适合作为个人或小团队的首选方案。原因有三个。第一审核周期不以小时计以工作日计你等不起第二即使下来了接口覆盖的字段也未必覆盖弹幕、榜单一类运营刚需第三它要求应用的域名和回调地址固定本地开发调试要反复修改配置。那为什么江湖上流传的 .rar 里很少看到官方接口的代码因为官方接口的接入方式已经被平台侧规范死了没有信息差可以卖。真正的信息差在下面两条路上。2.2 网页端抓包接口更适合绝大多数调用需求打开任意一个 YY 直播间页面按 F12 切到 Network 面板刷新页面过滤 XHR 或 Fetch你会看到几十个请求。其中一部分返回 JSON字段里带着直播间状态、在线人数、主播信息、榜单数据——这就是网页端接口。这套接口的典型特征域名集中在 www.yy.com 和 p.yy.com 下路径大多是 /api/ 开头请求需要带完整 Cookie至少要有登录态相关字段部分接口匿名也能访问返回是标准 JSON带 code 字段code0 表示成功防爬手段以 Referer 校验和频率限制为主个别接口带 sign 签名参数。网页端接口适合绝大多数调用需求因为它成本最低不需要逆向加解密不需要处理二进制协议你只需要把浏览器发出的请求原样复刻一遍。做房间状态监控、定时截图前的数据准备、开播提醒轮询这套接口完全够用。但网页端接口有个容易被忽略的缺点它不是契约是现场。YY 前端改版频繁接口路径、参数名、返回字段可能一个月变一次。所以凡是做网页端接口调用的人至少要养一个习惯——抓包记录留在本地接口变了能比对。2.3 房间私有协议接口.rar里真正值钱的东西弹幕、礼物特效这类实时数据网页端页面走的是 WebSocket 长连接不是普通 HTTP 轮询。这也是“YY调用最新.rar”里通常最值钱的部分别人已经把连接地址、握手报文、心跳包格式、消息解包逻辑整理成了代码或文档。私有协议接口的调用流程一般是先用登录态拿一个会话凭证然后建立 WebSocket 连接连上后先发订阅消息指定关注哪一个房间之后周期性发心跳保活收到服务端推送后按消息类型解析。消息体里通常分文本帧和二进制帧文本帧可能是 JSON也可能是一层 base64二进制帧则按字节偏移读取压缩方式可能是 zlib 或自定义异或。需要说明一个边界私有协议接口不是官方承诺长期稳定的东西也不是官方文档里允许你“想怎么调就怎么调”的对象。做这个方向意味着你要接受协议随时可能变更的现实并且承担账号层面可能存在的限制风险。我一般建议能用网页端接口解决的场景就不要碰私有协议只有弹幕分析这类实时性要求极高的需求才值得付出维护成本。2.4 拿到“最新.rar”后先做三个检查再决定改哪套方案很多人拿到 .rar 的第一反应是双击解压然后在没看任何说明的情况下直接运行 exe 或 py结果遇到缺库报错就去百度。这里我给一套更稳的检查流程先把包摸清楚再决定要不要跑。第一步测试压缩包完整性并列出文件清单不要直接全量解压。命令如下unrar t YY调用最新.rar # 测试压缩包是否完整发现损坏就放弃 unrar l YY调用最新.rar # 列出全部文件优先看目录结构 unrar x YY调用最新.rar ./yy_sdk/ # 确认结构合理后解压到独立目录参数说明t只做完整性测试不解压适合第一时间排除“下载过程丢包”的问题l是列表模式能看到每个文件的路径和大小这时候你就能判断包是源码、文档还是编译产物x才会真正解压后面跟目标目录。把包解压到独立目录而不是当前目录是为了避免里面的配置文件和别的项目相互污染。第二步打开包里的 README 或说明文档优先找三类字段房间号、Cookie 配置项、WebSocket 地址。这三个字段决定了脚本能不能连上目标房间。如果没有说明文档就找配置文件里的占位符比如ROOM_ID 请填写这种。第三步确认脚本运行环境。注意看文件扩展名全是 .py 的说明依赖 Python 环境带 .exe 的说明作者已经打包好了运行环境带 .dll 的则可能依赖特定版本的运行库。不要一上来就双击 exe先看看包里有没有 md5 校验文件再决定是否信任。解压这一类来源不明的压缩包最稳妥的做法是先放到一个没有业务数据的虚拟机或容器里跑一遍观察它会不会访问你本地别的目录再接入真实 Cookie。这不是多疑是做接口调用这一行的基本卫生习惯。3. 把YY接口调用跑通的最小环境Python请求会话与登录态处理走通网页端接口的最短路径是拿 Python 的 requests 模拟一个带登录态的浏览器会话。这一章把环境、Cookie 处理和第一个真实调用拆开讲。3.1 环境准备Python 虚拟环境与三个依赖库做接口调用的人最忌讳把依赖直接装进系统 Python。同一个 .rar 里可能有多个脚本有的要 requests有的要 websocket-client还有的要 pycryptodome直接装系统环境会让你在两个项目之间互相踩。先建虚拟环境python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate pip install requests websocket-client pycryptodome逻辑说明python -m venv .venv创建独立环境activate 之后pip install 装的库只在这个环境里生效。requests 负责普通 HTTP 接口websocket-client 负责后面连弹幕长连接pycryptodome 是备用——如果包里有需要解密的字段AES 解包通常靠它。三者按需安装不是每个脚本都用得上全部。3.2 用抓包拿到的 Cookie 初始化请求会话网页端接口调用的核心是让服务端认为“你是你”。YY 的鉴权主要靠 Cookie 里的登录态字段所以你需要在浏览器里登录自己的账号然后在 DevTools 的 Network 面板里找到任意一个请求复制请求头里的 Cookie 整段值。拿到 Cookie 后初始化一个有状态的会话# session.py带登录态的YY请求会话初始化 import requests SESSION requests.Session() def load_cookie(cookie_text: str) - None: 把浏览器抓包拿到的 Cookie 字符串装进会话 for item in cookie_text.split(;): parts item.strip().split(, 1) if len(parts) 2: SESSION.cookies.set(parts[0], parts[1], domain.yy.com) COOKIE yyuid123456789; skeyxxxxxxxxxxxx; \ 其他字段按抓包结果替换 load_cookie(COOKIE) SESSION.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://www.yy.com/, Accept: application/json, text/plain, */*, })逻辑说明requests.Session()会自动维护 Cookie后续所有请求都复用同一个登录态。load_cookie把抓包得到的半角分号分隔字符串逐条拆开调用 cookies.set 写进会话同时指定 domain 为 .yy.com这样 www.yy.com 和 p.yy.com 两个子域都能带上这套 Cookie。请求头里的 User-Agent 和 Referer 是很多接口的“入场券”不带 Referer部分接口会直接返回 403。参数说明Cookie 里的字段名以你抓包结果为准我这里写的 yyuid 和 skey 是常见字段但 YY 改版后字段名会变。最关键的一点是Cookie 是有有效期的通常在几小时到几天之间。脚本跑着跑着突然从正常返回变成未登录第一反应就应该是去浏览器重新复制 Cookie而不是怀疑代码。3.3 第一次真实调用读取房间基本信息会话就绪后用最常见的房间信息接口练手。目标是传入一个房间短号返回房间名称、在线人数、直播状态等基础信息# room_info.py读取YY直播间基础信息 import json import logging logging.basicConfig(levellogging.INFO, format%(asctime)s %(levelname)s %(message)s) logger logging.getLogger(room) ROOM_ID 4520178 # 替换成你要调用的房间短号 def get_room_info(room_id: str) - dict: 拉取房间基础信息 注接口路径以你自己抓包结果为准这里只做调用结构示意 url https://www.yy.com/api/room/info params {roomId: room_id} resp SESSION.get(url, paramsparams, timeout5) data resp.json() if data.get(code) ! 0: raise RuntimeError( f接口返回异常 code{data.get(code)} msg{data.get(msg)} ) return data[data] if __name__ __main__: info get_room_info(ROOM_ID) logger.info(房间信息: %s, json.dumps(info, ensure_asciiFalse))逻辑说明SESSION.get的第二个参数是 paramsrequests 会把字典拼成 URL 查询串比手拼字符串安全。resp.json()把响应体解析成字典先判 code 再取 data这是 YY 接口的通用返回结构写其他接口时复用这个防御逻辑即可。timeout5 是必须的防止某个接口挂起把整个脚本拖死。参数说明房间短号不同于主播数字 ID。短号是直播间地址里那一串较短的数字主播 ID 一般是 10 位以上的长数字有的接口收 roomId有的收 uid两个字段不要混传。第一次调用如果不确定参数名回到抓包里看浏览器实际发的参数名照着抄不要凭感觉猜。3.4 把调用封装成带缓存的客户端类跑通了单个接口之后别急着往下写第二个脚本。先做一个统一封装让所有接口都从这里发出去后续加参数、加日志、加限流都只改一处# yy_client.py统一封装带内存缓存和失败重试 from functools import lru_cache import logging import time import requests logger logging.getLogger(yy_client) class YYClient: def __init__(self, session: requests.Session): self.session session lru_cache(maxsize256) def room_info_cached(self, room_id: str) - dict: return self._request(GET, https://www.yy.com/api/room/info, params{roomId: room_id}) def _request(self, method: str, url: str, **kwargs): kwargs.setdefault(timeout, 5) for attempt in range(3): try: resp self.session.request(method, url, **kwargs) data resp.json() if data.get(code) ! 0: raise RuntimeError(fcode{data.get(code)}) return data[data] except Exception as exc: logger.warning(第%s次请求失败: %s, attempt 1, exc) time.sleep(1 attempt) raise RuntimeError(f请求失败: {url})逻辑说明lru_cache(maxsize256)做内存缓存同一个房间短号的请求在短时间内只真正发一次网络请求接口调用频率立即降一个量级这是降低被限制的最有效手段。_request里做了最多三次重试每次重试前 sleep 递增等待避免在服务端临时抖动时火上浇油。注意缓存的副作用是拿不到“最新”数据对实时性要求高的状态类接口不要套缓存。4. 接入直播场景的三个高价值接口房间信息、弹幕流、开播状态轮询前面的会话层解决的是“能不能调”的问题这一章解决“调什么”的问题。结合我做 YY 接口调用的经验对业务最有用的接口分三类房间信息、弹幕流、开播状态。分别讲调用方式、返回字段和参数调优直接照着抄基本盘。4.1 房间信息接口先搞清返回字段再决定轮询频率房间信息接口是整套方案的底座弹幕要连哪个房间、主播是否开播都以它为准。接口刚才写过重点说返回字段和业务判断。常见返回字段以抓包为准liveStatus直播状态开播/未开播/重播是轮询脚本的核心判据onlineNum在线人数实时性较高做展示用没问题做统计别直接累加roomName / nick房间名和主播名用于日志和告警文案tags房间标签可以用来做分类监控。在线人数这类高频变化字段注意不能靠缓存拿否则你看到的是几分钟前的缓存值。而 liveStatus 这种低频状态字段反而建议走缓存降低对接口的压力。轮询频率的经验值是状态类接口 30 秒一次足够人数展示类 10 秒一次是上限低于 10 秒基本就在制造无效流量。如果你要同时监控几百个房间按房间数乘以频率算一下 QPS超过每秒 5 次请求就要考虑错峰和分片。4.2 弹幕WebSocket接入心跳是唯一不能省的东西弹幕走 WebSocket和普通接口调用的思维完全不同。长连接不是“请求-响应”而是“建立连接、订阅消息、持续收包”所以最容易出问题的地方反而在连接初始化和保活环节。最小可用代码如下# danmaku.pyYY直播间弹幕WebSocket接入 import json import threading import time import websocket WS_URL wss://chat.yy.com/ws # 以抓包为准域名和路径会随地区变化 def on_message(ws, message): 收到服务端推送统一打印原始消息先看结构再解析 try: data json.loads(message) print(f[MSG] {json.dumps(data, ensure_asciiFalse)}) except Exception: print(f[RAW] {message}) def on_open(ws): 连接建立后发送订阅房间消息 sub_msg { action: subscribe, roomId: 4520178, # 替换为目标房间短号 type: danmaku, } ws.send(json.dumps(sub_msg)) print([SYS] 已订阅弹幕) def heartbeat(ws): 独立线程定时发心跳服务端超时判定通常比较宽松 while True: time.sleep(50) try: ws.send(json.dumps({action: ping})) except Exception as exc: print(f[SYS] 心跳发送失败: {exc}) break def main(): ws websocket.WebSocketApp( WS_URL, on_openon_open, on_messageon_message, ) t threading.Thread(targetheartbeat, args(ws,), daemonTrue) t.start() ws.run_forever() if __name__ __main__: main()逻辑说明on_open里发订阅消息告诉服务端“我要看这个房间的弹幕”on_message收到所有推送调试阶段先全部打印不急着解析。heartbeat是一个守护线程每 50 秒发一次 ping。之所以用 50 秒而不是 30 秒是从抓包里观察到的服务端最长静默时长推断的心跳短于服务端判定时间也是浪费资源。参数说明websocket.WebSocketApp的第一个参数是连接地址必须从抓包里抄run_forever()是阻塞方法断线后不会自动重连生产环境需要在外面套一层 while 循环捕获异常后 sleep 几秒再重新连接。还有一个调试技巧run_forever()支持ping_interval和ping_timeout参数先用它们做基础保活再用手动心跳处理业务级 ping两者不冲突。4.3 开播状态轮询参数设计决定你账号能活多久开播提醒是最常见的业务场景实现不复杂难在参数设计。给一个带随机抖动的轮询模板# watcher.py开播状态监控带随机抖动 import random import time import logging from yy_client import YYClient logger logging.getLogger(watcher) def watch_streamer(client: YYClient, uid: int, base_interval: int 30): last_state None while True: try: data client.room_info_by_uid(uid) # 换成按uid查的接口 live_status data.get(liveStatus) if live_status ! last_state: logger.info(状态切换 %s - %s, last_state, live_status) last_state live_status # 在这里接你的告警钉钉/企微/飞书webhook except Exception as exc: logger.warning(轮询失败: %s继续重试, exc) # 基础间隔 随机抖动避免所有房间请求在同一时刻到达 time.sleep(base_interval random.randint(0, 10)) if __name__ __main__: client YYClient(SESSION) watch_streamer(client, uid123456789)逻辑说明base_interval30是基础轮询周期random.randint(0, 10)是随机抖动。抖动的意义在于如果你同时开 10 个这样的监控没有抖动的话所有请求会在同一秒挤到服务端有抖动就均匀散开了。last_state记录上一次状态只在状态切换时触发动作避免每 30 秒打一次告警。参数说明轮询类脚本在遇到接口返回异常时不要立刻重试要退避。一个简单的做法是连续失败次数越多间隔越长例如失败 1 次等 10 秒失败 5 次等 60 秒。这个模板里用固定 sleep是保守做法够用但不优秀等你要监控几百个主播时再把重试间隔改成指数退避。5. 调用YY接口的五个常见坑签名校验、断连、限流与编码问题接口调用这个方向跑通不算本事能稳定跑一周才算。这一章把我在 YY 接口调用上踩过的坑集中写出来按现象、原因、解决的顺序记方便你遇到问题的时候直接对号入座。5.1 一开播就连续报 403签名参数没跟着抓包走现象用浏览器能正常打开的接口换成 Python 请求就返回 403而且只有部分接口报其他接口正常。原因这些接口在请求参数里多了一个 sign 或 sig 字段。这个字段是把其他参数按字典序拼接后用固定密钥做的哈希密钥和拼接规则不在网页源码里明文写着而是在前端 JS 里通过混淆藏起来的。你从抓包里复制了 URL却漏了 sign服务端一算对不上就拒绝。解决不要自己猜签名算法先确认这个接口到底有没有签名要求。判断方法很简单在抓包详情里找到该请求的 URL 参数列表如果有个字段是 32 位十六进制字符串八成是 MD5 签名。然后去 .rar 包里搜“sign”或“sig”关键字大多数整理好的脚本里已经实现了算法直接调用。实在找不到就把浏览器里的请求复制成 cURL 格式转成 Python 代码跑一次能跑通说明签名携带没问题再逐步改成动态生成。5.2 弹幕连接几十秒就被断开心跳包没发出去现象WebSocket 连上了也订阅房间了消息正常收了一小会然后突然断开重连后又是几十秒掉线。原因服务端有个静默超时判定。你连接建立后如果长时间没有发任何数据服务端认为客户端已经死了主动断开。如果你代码里只写了订阅没写心跳或者心跳发的是 HTTP 协议的 ping 而不是业务层 JSON 包服务端都不认。解决抓包里找到浏览器在连接空闲时发出的心跳报文通常是{action:ping}或{op:2}这类固定结构按原样在独立线程里定时发送。间隔不要小于服务端超时的一半常见取 40-60 秒。如果加了心跳还是断看一眼日志里断开前的最后一条消息是不是服务端先发了一个“连接超时”通知——那说明你心跳间隔长于服务端预期调短即可。5.3 同一个 IP 调多了接口从偶尔超时到全部 403现象脚本跑了一段时间后所有接口开始随机超时随后变成稳定 403网页端用同一个账号登录没问题但脚本就是调不通。原因服务端做了请求频率限制判定维度通常是 IP 加 Cookie 双维度。单个 IP 的请求频率超过阈值会触发临时封禁封禁时间从几分钟到几小时不等。你切换 Cookie 没用因为 IP 维度已经记录了异常。解决先停掉脚本等封禁自然过期不要反复试探。然后给代码加两层保护第一层所有接口调用统一走前面写的_request封装在里面加一个最小请求间隔控制第二层对高频场景做本地缓存能用缓存就不要发网络请求。如果你是在服务器上跑只监控一个房间的弹幕不会触发限制但如果你一个 IP 同时跑几十个房间的轮询就要考虑把请求分散到不同的时间片里而不是整点齐发。5.4 .rar 里的脚本双击就闪退编码与运行库问题现象解压后双击 .py 文件黑窗口一闪而过或者双击 .exe 提示缺少某 DLL又或者运行时中文全部乱码。原因这类 .rar 的脚本作者大多在 Windows 上用 Python 2 或旧版 Python 3 写的代码文件可能是 GBK 编码而你的环境是 UTF-8print 中文直接报 UnicodeEncodeErrorexe 则可能依赖老版本 VC 运行库新系统上没有装。解决不要双击运行在命令行里执行让报错信息留在屏幕上再判断。用 Python 3 跑时在文件顶部加一行编码声明注释或把 print 改成print(repr(中文变量))先绕过编码错误。对 exe 缺失运行库的问题先看报错的是哪个 DLL再去微软官网下对应版本的 Visual C 运行库不要盲目装“运行库合集”。记住老脚本的工具链和今天的不是一套能用它的思路重写就不要执着于让原作者的程序原样跑起来。5.5 接口返回的是一串看不懂的密文数据被加密了现象有的接口返回的 JSON 里关键字段不是明文而是一长串 base64 或十六进制字符串压根没法直接取值。原因YY 的部分数据接口在传输层做了一层加密密钥要么固定写在网页打包的 JS 里要么由前一个接口动态下发。这在 .rar 包对应版本里如果没实现解包就是你接到手时的现状。解决先确认密文字段在抓包里是不是也是密的。如果在浏览器里显示明文说明加密和解密都在前端完成去 Sources 面板里搜索 base64 解码相关的 JS 代码找到密钥如果抓包里本身就是密文那说明密钥在更底层的模块里这个项目的投入产出比就得重新评估。一个折中做法是只依赖另一个明文接口拿到同等字段不一定非要啃加密接口。6. 让调用更稳的一招先抓包留档再写代码用日志回放校验接口变更接口调用项目最让人头疼的不是第一次调通而是跑了两周之后的某一天脚本突然全部失灵。YY 这类平台的前端接口没有版本承诺路径和参数说变就变。我现在的习惯是任何一次抓包都会把原始请求和响应存档代码里也会留一份请求日志。这不是为了写文档是为了出问题时能对比“之前能通的请求”和“现在不通的请求”差在哪。存档的格式不用复杂纯文本一行记录就够关键是字段要全# capture.py请求日志落盘接口变更时用来比对差异 import time import logging logging.basicConfig( filenamerequests.log, levellogging.INFO, format%(asctime)s|%(message)s, ) def dump_call(method: str, url: str, params: dict, status_code: int, body: str): logging.info( %s|%s|%s|%s|%s, method, url, sorted(params.items()), # 排序后更容易 diff status_code, body[:200], )日常调用时把这个方法挂在统一请求封装里每次请求都追加一行。接口失灵时把 requests.log 里出问题的时间段摘出来和上一次正常时间段的记录逐字段对比。多半是以下几种情况参数名从 roomId 变成了 room_id接口路径里加了个版本号或者返回体的字段从字符串变成了嵌套对象。找到差异改动就很小不用重新逆向一遍。有一件事我想提醒你留意抓包工具和代码不是一回事。代码是你以为服务端接收到的请求抓包是服务端实际接收到的请求。我见过太多人对着代码调了半天最后发现是 requests 自动做了 URL 编码把参数里的特殊字符变了样。所以在验证阶段用 Fiddler 或 Charles 这类抓包工具过一遍你的请求和浏览器的原始请求比对能省掉大量莫名其妙的排查时间。这也是我做接口调用的最后一条习惯每次改动代码后不只看返回结果对不对还要看抓包里实际发出的请求和浏览器原始请求是不是一致。字段名、顺序、编码方式任何一个细节都可能是接口玄学的根源。用日志回放去复盘每一处变更比靠记忆力盲猜靠谱得多。希望帮到你。本文还有配套的精品资源点击获取