ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

网易云Cookie获取全指南:手动抓包与Playwright自动化保存MUSIC_U

2026/9/20 6:49:54 拓冰建站 浏览量
网易云Cookie获取全指南:手动抓包与Playwright自动化保存MUSIC_U 做网易云相关的个人小工具比如歌单备份、歌词导出、把网页版歌单同步到第三方播放器都会遇到同一个问题网易云网页端的接口需要登录态而登录态基本都体现在Cookie上。我接触过的绝大多数脚本框架、第三方客户端配置文档里都会留一个位置让你填Cookie不填就只能访问公开接口一碰私有歌单就是401或者直接跳登录页。这篇内容我就把获取个人网易云Cookie的完整方法拆开讲清楚手动怎么抓、自动怎么抓、抓完怎么维护适合正在写网易云相关脚本、想用第三方客户端、或者单纯想把数据备份搞明白的人。1. 获取网易云Cookie之前先搞懂登录态跟Cookie的关系1.1 为什么第三方工具都让你填Cookie而不是直接交账号密码网易云没有开放稳定且公开的第三方登录API这是个很现实的问题。你以为那些脚本作者不想直接用账号密码登录吗他们想得很但网易云网页端的接口设计决定了所有需要用户身份的操作都必须依赖登录后下发的Cookie。你打开music.163.com输入账号密码、过了滑块和短信验证服务端会在浏览器里种下一堆Cookie字段之后你每发一个请求浏览器都会自动把这些Cookie带上。服务器看到Cookie里有MUSIC_U就知道“这个请求来自某某用户”。Cookie和Session的关系可以简单理解成寄存柜的号码牌服务端是寄存处Session是柜子里存的那件外套Cookie是你手里的号码牌。你每次去取东西不需要报名字只需要递上牌子柜员看编号对得上就把东西给你。第三方工具让你填Cookie本质上就是让你把号码牌的复制件交给它它拿着这个复制件去请求接口服务端只看牌子编号对不对不关心你是怎么拿到牌的。为什么不直接在脚本里模拟“输入账号密码”呢两个原因。第一明文密码在脚本里传输和存储风险比Cookie泄露还大工具开发者也不希望替用户保管这么敏感的东西第二网页登录链路里经常出现滑块验证、行为风控、短信二次确认脚本纯模拟登录的成功率很低而且一旦触发风控反而给账号添麻烦。所以最主流的方案就是人负责完成登录动作脚本只负责拿到登录后的Cookie然后保存、复用。1.2 手动抓包和自动化脚本两种获取路径的适用场景获取Cookie有两条主流路径。第一条是手动抓包打开浏览器开发者工具登录后从请求头里复制Cookie串整个过程几分钟搞定。这条路径适合临时用一次的场景比如给第三方播放器填一次配置、写个小脚本处理一下歌单之后可能很久都用不上。手动抓包的好处是零成本、不需要装任何额外工具坏处是每次Cookie失效都得重新走一遍登录流程有点烦人。第二条是自动化脚本通过Playwright这类工具自动打开浏览器你扫码登录脚本检测到登录成功后自动把Cookie保存为文件。这个路径适合长期维护任务的场景比如每周跑一次歌单同步、在服务器上跑定时任务、或者需要管理多个账号。自动化脚本的优点是登录态可以集中管理过期后重新扫码就行缺点是前期搭建需要一点代码基础。这两条路并不冲突。我自己的习惯是第一次先用手动抓包解决问题同时把自动化脚本搭起来之后每次失效就交给脚本处理。但无论哪条路都要记一个前提网页版Cookie和手机App的登录态不是一套体系。手机端走的是Token体系不是浏览器Cookie机制。网上有些人从手机App抓包出来一堆字符串拿去填网页版第三方工具结果各种失效和报错。如果你的目标是网页版Cookie就老老实实从桌面浏览器里抓别绕弯路。2. 手动抓取网易云Cookie浏览器开发者工具5分钟搞定2.1 完整操作步骤登录、抓请求、复制Cookie串手动抓取Cookie的操作我拆成下面几个步骤照着做基本不会出错。第一步建议用Chrome或Edge浏览器打开一个无痕窗口访问https://music.163.com。无痕窗口的好处是干净不会被旧登录态干扰也不会因为浏览器插件往请求头里加了东西而影响后续使用。第二步先在页面上完成登录。用手机号、邮箱或者扫码都可以如果遇到滑块验证就按提示拖一下。登录成功后你会看到页面上出现了自己的头像和昵称这一步很关键没登录就往下走抓到的一定是游客状态的数据。第三步按F12打开开发者工具切到Network面板也就是网络面板。注意要勾选上Preserve log也就是保留日志。如果不勾选刷新页面时之前抓到的请求记录会被清空。第四步刷新一下页面然后在Network面板的过滤框里输入music.163.com或者直接在请求列表里找任意一个以这个域名开头的请求。这些请求可能是接口请求也可能是文档请求不用太挑。第五步点开一个XHR请求。你在请求列表里看到的名字带/api/、/weapi/之类的基本就是XHR请求。点开后在右侧Headers面板里找到Request Headers区域往下翻找到Cookie:这一行。第六步复制Cookie字段的值。我建议不要手动去选那一长串文字容易漏。直接右键请求名称选择Copy再选择Copy request headers把整个请求头复制到文本编辑器里从里面挑出Cookie行。这样做的好处是如果后面要调试接口User-Agent、Referer这些信息也能一起保留。这里有个非常重要的操作细节一定要在登录完成之后再刷新页面刷新之后再去抓请求。很多人习惯先打开F12再登录或者登录后不刷新直接点开登录前的某个请求结果复制出来的Cookie里没有MUSIC_U字段拿去用才发现所有隐私接口都调不了。判断自己抓到的Cookie是不是有效的登录态方法很简单看里面有没有MUSIC_U。2.2 Cookie关键字段拆解MUSIC_U和__csrf才是主角抓到的Cookie串往往很长密密麻麻的全是分号分隔的键值对。很多新手一看就头大其实不用怕你不需要理解每个字段但最好知道几个关键的因为后面排查问题的时候会用到。字段作用详细说明MUSIC_U用户身份令牌最核心的字段登录后才会出现第三方工具靠它识别用户身份__csrf防跨站请求伪造令牌很多接口提交数据时做校验抓取到的Cookie串里通常带它NMTID浏览器设备标识用于风控和行为追踪未登录时也可能出现MUSIC_A匿名用户标识未登录状态也会存在部分接口会读取MUSIC_T / MUSIC_R用户分类和推荐算法标记普通调用不用关心复制时保留即可MUSIC_U是重中之重。你在GitHub上翻各种网易云相关的脚本看他们判断“是否登录”基本都是检查Cookie里有没有MUSIC_U。只要Cookie里有这个字段说明你抓到的是登录用户的会话。如果只有一堆MUSIC_A、NMTID说明还是游客态拿去请求私有歌单、收藏列表、每日推荐大概率是失败或者拿不到完整数据。__csrf这个字段也很重要。网易云很多接口提交数据时不仅要在请求体里传csrf_token还会校验Cookie里的__csrf是否匹配。如果你把Cookie串里的__csrf字段弄丢了或者复制的时候漏掉了可能连发个评论都报错。所以手动复制的时候建议整段复制别只挑自以为有用的字段。2.3 新手最容易踩的3个手动抓取误区误区一从Application面板里复制Cookie。Chrome的Application面板里确实能看到每个Cookie值但那是分散的键值对你还得手动拼成Cookie串很容易漏字段、拼错顺序。我见过有人把Application面板里的单个MUSIC_U复制出来当Cookie用结果当然报错。从请求头里整段复制是最稳妥、最不容易出错的方式。误区二登录后不刷新页面抓的是登录前的请求。很多现代网页是单页应用登录成功后页面不会自动跳转所以Network面板里可能还保留着登录前的请求记录。你点开其中一个Cookie里自然没有MUSIC_U。记住一个原则登录完成后刷新页面再抓新产生的请求。误区三抓完就把Cookie贴到公共平台。这点我必须多说一句之前在一些交流群里见过有人为了帮别人调试问题直接把Cookie截图或者文本发到群里这非常危险。Cookie就是账号钥匙拿到它的人完全可以冒充你的身份操作你的账号。Cookie只该保存在自己的电脑或私人配置里不该出现在任何公开场景中。3. 自动化获取与长期复用Playwright一键保存Cookie到本地3.1 为什么推荐用Playwright而不是Selenium如果你已经决定用自动化脚本维护多个账号或长期任务工具选型是个绕不开的问题。市面上主流的浏览器自动化工具就是Selenium、Puppeteer和Playwright这几个我最后选了Playwright原因很直接。Selenium最老牌生态成熟但配置起来很烦。你需要下载浏览器驱动还要保证驱动版本和浏览器版本匹配一升级就翻车。而且Selenium模拟浏览器的特征比较明显很多网站的反爬策略对它不太友好。Puppeteer本身是Node.js生态的如果你主力语言是Python用它还要再搞一层子进程通信维护成本太高。Playwright是微软团队开源的Python和Node.js都能直接调用内置了浏览器下载和管理能力不用单独装驱动。最关键的是它支持持久化上下文也就是说它可以指定一个目录保存浏览器状态扫码登录一次之后下次运行同一个脚本时如果Cookie没过期浏览器打开就已经是登录状态了能少点很多事。还有一个很多人忽略的点自动化登录虽然能模拟输入账号密码但我不建议你这么干。首先把密码写进代码或配置文件本身就是个安全隐患万一文件泄露账号信息就全暴露了。其次滑块验证、行为风控一旦出现脚本填密码的成功率会直线下降。最优雅的方案是让脚本打开浏览器后停在登录页面你掏出手机扫个码脚本负责监听登录结果并保存Cookie。3.2 Python脚本监听登录态并自动保存Cookie下面这个脚本我实测过你只需要把Playwright安装好运行后会自动弹出一个浏览器窗口扫码登录后Cookie会自动保存成JSON文件。from playwright.sync_api import sync_playwright import json import time COOKIE_FILE netease_cookies.json def main(): with sync_playwright() as p: context p.chromium.launch_persistent_context( user_data_dir./netease_login_state, headlessFalse, viewport{width: 1280, height: 800} ) page context.new_page() page.goto(https://music.163.com) print(请在打开的浏览器窗口中完成登录检测到MUSIC_U后会自动保存Cookie。) for _ in range(180): cookies context.cookies() if any(c[name] MUSIC_U and c[value] for c in cookies): with open(COOKIE_FILE, w, encodingutf-8) as f: json.dump(cookies, f, ensure_asciiFalse, indent2) print(fCookie已保存到 {COOKIE_FILE}) break time.sleep(1) else: print(等待超时请重新运行脚本再试。) context.close() if __name__ __main__: main()运行之前先执行pip install playwright然后执行playwright install chromium安装内置浏览器。脚本里有两个关键设计。第一个是launch_persistent_context。普通启动方式launch每次运行都是全新浏览器登录态完全不保存。用launch_persistent_context并指定user_data_dir相当于指定了一个固定的浏览器用户数据目录。你扫码登录后浏览器状态会写进这个目录。下次再跑这个脚本如果登录态还没过期打开浏览器直接就是登录状态脚本会在几秒内立刻检测到MUSIC_U并保存Cookie连扫码都省了。第二个是轮询逻辑。脚本每次循环都读取当前浏览器的所有Cookie检查有没有MUSIC_U。因为扫码登录的时间不确定最长等180秒正常流程几十秒就能完成。如果你要管理多个账号可以多跑几次脚本每次把COOKIE_FILE改成不同文件名比如netease_cookies_account1.json、netease_cookies_account2.json。3.3 保存后的Cookie如何在脚本、JMeter等工具里复用保存下来的JSON文件里每个Cookie都有name、value、domain、path、expires这些元数据。你在实际发起HTTP请求的时候最方便的做法是把它拼成一个Cookie字符串。import json with open(netease_cookies.json, encodingutf-8) as f: cookies json.load(f) cookie_str ; .join( f{c[name]}{c[value]} for c in cookies if c.get(name) )拼好之后再发给requests库import requests headers { 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, Cookie: cookie_str, Referer: https://music.163.com/, } resp requests.get( https://music.163.com/api/v1/playlist/detail?id你的歌单ID, headersheaders )我特意在请求头里加了Referer网易云部分接口对这个字段有校验不加可能会返回奇怪的结果。这个细节很多教程不会提但实际调试时很重要。如果你不是写代码而是用JMeter调试接口做法也很简单。在测试计划里添加一个“HTTP Cookie管理器”把Cookie按namevalue的形式添加进去更快的办法是添加一个“HTTP信息头管理器”直接增加一行请求头名字填Cookie值填你刚复制的那一串。这样你在JMeter里调试网易云接口时也能带着登录态不会一请求就403或者跳登录。复用阶段还有一个习惯建议Cookie不要硬编码到代码里。写成配置文件、环境变量或者单独一个JSON文件脚本启动时读进来。我习惯在项目里放一个config/cookies.json的占位文件并且在.gitignore里排除它防止Cookie跟着代码一起提交到仓库里。这个习惯能在关键时候救你一命因为一旦代码仓库是公开的Cookie就相当于公开了。4. 常见问题排查与账号安全清单4.1 今天能用明天就失效常见失效原因速查表Cookie失效是所有使用者遇到最多的问题而且失效原因五花八门。我把自己实际遇到和帮别人排查过的场景整理成了一张表。症状可能原因解决办法前一天能用第二天就401登录态过期或账号在其他设备登录被顶下线重新扫码登录获取Cookie控制同时在线的设备数量代码里填了Cookie但提示未登录抓到的Cookie串里没有MUSIC_U拿的是游客态登录后刷新页面重新抓取检查MUSIC_U字段是否存在手动登录时频繁出滑块验证短时间内多次触发登录或网络环境有变化停半小时再试优先用手机扫码代替短信验证码第三方播放器导入Cookie后无法加载私人歌单工具要网页端Cookie你填的是App端Token从music.163.com网页版抓取不要用手机App抓包数据脚本长时间运行后突然失败服务端登录态到期或账号被风控临时限制把Cookie刷新做成定时任务在过期前主动更新对于长期运行的脚本我的建议很直接不要等到Cookie失效了再处理而是提前建一个定时任务比如每周自动跑一次上面那个Playwright脚本覆盖更新JSON文件。网易云网页版登录态能维持一段时间但账号状态、异地登录提醒、多设备同时在线都会影响它的寿命。定时刷新之后绝大多数“Cookie突然失效”的问题都能在萌芽阶段被处理掉。4.2 Cookie安全须知泄露之后会出哪些事关于Cookie安全我可以把话说重点Cookie就是账号的钥匙它的泄露范围和我把账号密码交给你没有本质区别。拿到你的MUSIC_U之后对方可以请求你账号名下的私人歌单、修改歌单内容、关注、收藏甚至在风控不够严格的场景下替你完成操作。这些动作累积到一定程度账号的信任评分会下降严重的话会被临时限制登录。所以有几个习惯必须养成。第一Cookie字符串不要截图发到任何群里不要贴在Issue里不要随手写进公开博客的示例代码里。第二如果怀疑Cookie已经泄露去网易云手机端或网页端的设置里找到“退出所有设备”之类的选项一次性清掉所有登录态然后重新登录抓一次。第三如果你在给朋友写教程或示例记得用占位符代替真实的Cookie值比如把MUSIC_U的值改成your_music_u_here。这些不是空话社区里因为贴Cookie导致账号被折腾的案例我见过不止一次。4.3 技术边界拿到Cookie不等于可以绕过所有限制最后说一个很多新人容易误解的点。Cookie只是身份凭证它不代表你能无限访问所有资源。网易云网页端接口有权限控制和风控策略比如VIP歌曲的下载权限跟账号会员状态绑定Cookie解决不了“非会员下载高音质”这种问题再比如接口请求频率就算你有合法Cookie短时间内高频请求一样会被临时限制这不是脚本Bug而是服务端正常的防滥用策略。所以我个人在Cookie使用上只做三件事备份自己的歌单和收藏、导出自己的歌词、同步到第三方播放器做本地管理。所有请求都控制频率所有数据都限制在自己账号名下。如果你要做更复杂的自动化先想清楚目标是不是在合理范围内“能拿到Cookie”和“可以随便调接口”之间还隔着很长的合规与底线问题。我个人在实际操作中的体会是网易云Cookie这件事本身五分钟就能讲完难的是后面的使用和维护。手动抓取适合一次性配置自动化脚本适合长期运行两者结合才是完整的方案。如果你只是给第三方播放器配一次Cookie看到这里就可以动手了如果你在维护一个长期任务我建议把脚本、Cookie文件、定时刷新这三件套一起搭好后面能省很多事。最后再提一句Cookie刷新后一定要顺手验证一下用脚本请求一次自己的歌单接口返回正常再投入正式任务别等到跑挂了才发现。