1. 拆解需求小程序短剧下载到底难在哪1.1 为什么短剧内容不能直接右键保存做过小程序相关开发或者逆向分析的人都知道微信小程序的媒体资源加载方式和普通网页有本质区别。普通网页里一个video标签源地址往往直接写在 HTML 里打开开发者工具就能看到.mp4链接。但小程序不一样它的页面渲染层和逻辑层是分离的视频地址通常由 JavaScript 在运行时动态拼接而且很多短剧平台会对资源链接做时效性签名和防盗链校验。具体来说短剧类小程序常见的保护手段有这么几层第一层是接口鉴权请求视频地址时需要携带token或者session_id第二层是 URL 签名链接里带sign、expires这类参数过期就失效第三层是 Referer 校验服务器会检查请求来源是不是自家域名第四层是分片传输视频被切成若干.ts片段通过.m3u8索引文件组织。这四层叠加下来你就算侥幸拿到一个链接复制到浏览器里大概率也是 403 或者播放几秒就断。所以整个任务的核心不是“下载”这个动作本身而是如何完整地还原客户端请求的上下文把鉴权信息、签名参数、请求头都补齐让服务器认为你就是那个正常播放的小程序。这就是为什么需要抓包工具配合 Python 脚本来做——抓包负责“看清楚”Python 负责“复现出来”。1.2 抓包工具选型为什么是 Charles 而不是 Fiddler 或 Wireshark热词里同时出现了 Charles、Fiddler、Wireshark、tcpdump这几个工具我都深度用过这里说下我的选型逻辑。Wireshark 和 tcpdump 属于网络层抓包拿到的是原始 TCP/IP 数据包。对于 HTTPS 流量你需要配置密钥日志才能解密而且解出来的数据是二进制流要自己重组 HTTP 报文分析成本极高。它适合排查底层网络问题不适合做应用层协议分析。Fiddler 是老牌工具Windows 上体验很好但它的证书机制在移动端配置时偶尔会有兼容性问题尤其是 Android 高版本系统对用户证书的限制越来越严。Charles 的优势在于中间人代理模式成熟、证书安装流程清晰、对移动端支持好、能直接看到请求响应明文、支持重写和断点。对于小程序这种走 HTTPS 的场景Charles 基本是首选。热词里提到的“charles 抓包都出现 unknown”和“charles 证书安装过了 windows 抓包还是 unknown”这两个问题后面我会专门讲排查方法这是新手最容易卡住的地方。至于“charles 雷电模拟器”这个组合是因为很多人没有多余的安卓真机用雷电模拟器跑微信再让模拟器走 Charles 代理这样抓包环境更可控。这个方案可行但要注意模拟器的网络模式设置。1.3 整体技术路线图把整个流程拆成阶段来看逻辑会清晰很多阶段目标核心工具关键产出环境搭建让 Charles 能解密 HTTPSCharles 证书可读的请求明文流量捕获定位视频相关接口Charles 微信接口 URL 和参数协议分析搞清鉴权和签名逻辑Charles 浏览器请求头、参数规律脚本复现用 Python 批量下载requests ffmpeg完整视频文件异常处理应对失效和分片Python 重试逻辑稳定下载流程这个路线不是拍脑袋定的是我踩过几次坑之后总结的顺序。很多人一上来就写 Python 脚本结果发现请求一直 403回头再去看抓包发现少了个Referer头。先把流量看明白再动手写代码这个顺序不能反。2. 环境搭建Charles 抓包配置的完整流程2.1 Charles 安装与基础代理设置Charles 的安装本身没什么难度官网下载对应系统版本一路下一步就行。真正需要配置的是代理参数。打开 Charles进入Proxy - Proxy Settings默认端口是 8888这个端口记住后面手机和模拟器都要填。这里有个细节Enable transparent HTTP proxying这个选项建议勾上它能让 Charles 自动处理一些非标准端口的流量。另外在Proxy - SSL Proxying Settings里先添加一条*:443的规则意思是拦截所有 443 端口的 HTTPS 流量。但注意不要一开始就开全局 SSL 代理因为微信的很多流量是加密的全开会导致 Charles 里一堆 unknown 和报错反而干扰你定位目标接口。我的做法是先不开启等确认了目标域名再针对性添加。2.2 证书安装电脑端和移动端的关键差异证书是 Charles 抓 HTTPS 的核心。电脑端安装相对简单Help - SSL Proxying - Install Charles Root Certificate然后导入到系统信任区。Windows 上要手动把证书拖到“受信任的根证书颁发机构”macOS 上要在钥匙串里设置为“始终信任”。移动端就麻烦一些。以 Android 为例步骤是手机连上和电脑同一个 WiFiWiFi 设置里配置手动代理主机名填电脑 IP端口填 8888。然后在手机浏览器访问chls.pro/ssl下载证书。下载完之后关键来了Android 7.0 以上用户安装的证书默认不被应用信任只有系统级证书才行。这就是为什么很多人证书装了抓包还是 unknown。解决办法有两个一是用低版本 Android 或者模拟器雷电模拟器默认是 Android 7可以改二是把证书装到系统分区需要 root。我一般推荐用雷电模拟器因为它可以方便地切换 Android 版本而且 root 权限好拿。热词里“charles 雷电模拟器”能成为搜索词说明这条路是大家验证过的。注意证书安装完成后一定要在 Charles 里确认SSL Proxying已经对目标域名生效。可以在Proxy - SSL Proxying Settings里看到已启用的规则列表。2.3 雷电模拟器的网络配置要点雷电模拟器跑微信抓包有几个设置必须调对。第一模拟器的网络模式建议用“桥接模式”这样它和电脑在同一网段代理设置更稳定。第二在模拟器的 WiFi 设置里长按已连接的网络修改网络高级选项里把代理改成手动填电脑的局域网 IP 和 8888 端口。第三如果模拟器里微信打不开或者网络异常检查电脑防火墙有没有拦截 8888 端口。我实测下来雷电模拟器 Charles 的组合在抓小程序流量时成功率很高因为模拟器环境干净没有真机上那些乱七八糟的后台流量干扰。但要注意模拟器里的微信版本不要太新太新的版本对代理的检测更严格有时候会直接拒绝连接。3. 流量分析从一堆请求里找到视频接口3.1 如何快速定位短剧视频请求打开 Charles 开始录制然后在模拟器里打开目标短剧小程序点开一集开始播放。这时候 Charles 里会刷出大量请求怎么快速找到视频相关的我的经验是看几个特征请求 URL 里带.m3u8、.mp4、.ts的这是最直接的响应体大小特别大的视频分片通常几百 KB 到几 MBContent-Type 是video/mp4或application/vnd.apple.mpegurl的。在 Charles 里可以按大小排序视频请求一般排在前列。如果短剧用的是 m3u8 分片你会先看到一个.m3u8请求返回的是一个文本列表里面列着所有.ts分片的地址。然后播放器会逐个请求这些.ts文件。这时候你要做的是把.m3u8的完整 URL 和请求头记下来因为下载分片时需要同样的鉴权信息。3.2 读懂请求头里的鉴权信息找到视频请求后右键Copy cURL Request把请求完整复制出来。这里面藏着所有你需要的信息。重点看这几个头Authorization或token身份凭证通常是一串 JWT 或者自定义字符串Referer来源页很多服务器会校验这个User-Agent客户端标识有些服务器会检查是不是微信Cookie会话信息可能包含session_idRange分片请求时的字节范围还有一个容易忽略的是 URL 本身的查询参数比如?signxxxtxxxusxxx。这些参数往往是动态生成的有有效期。你需要分析它们的生成规律或者干脆在有效期内快速下载。3.3 判断视频是直链还是分片这一步决定了你后面 Python 脚本的写法。判断方法很简单看响应内容。如果是一个完整的.mp4文件响应体直接就是二进制视频数据那说明是直链下载最简单。如果响应是一个文本里面有很多.ts结尾的行那就是 m3u8 分片需要先下载索引再逐个下载分片最后合并。还有一种情况是.mpd格式这是 DASH 协议的分片处理起来比 m3u8 复杂一些但原理类似。短剧小程序目前主流还是 m3u8因为兼容性好、实现简单。类型索引文件分片格式合并方式直链 MP4无无直接保存HLS.m3u8.tsffmpeg 合并DASH.mpd.m4sffmpeg 合并4. Python 脚本实现从单集下载到批量处理4.1 请求复现把 cURL 翻译成 Python 代码拿到 cURL 之后最省事的办法是用工具自动转换。网上有很多 cURL to Python 的在线工具但我不建议完全依赖它们因为生成的代码往往不够健壮。我的做法是手动提取关键部分用requests库重写。核心代码结构大概是这样import requests headers { User-Agent: Mozilla/5.0 (Linux; Android 10) AppleWebKit/537.36 ..., Referer: https://servicewechat.com/xxxxx, Authorization: Bearer xxxxx, } url https://example.com/video/xxxxx.m3u8 resp requests.get(url, headersheaders, timeout15) print(resp.status_code) print(resp.text[:500])先跑通这一个请求确认能拿到 m3u8 内容再往下做。如果返回 403就逐个检查请求头看看少了哪个。最常见的就是 Referer 和 User-Agent这两个补上基本能解决大部分问题。4.2 m3u8 解析与分片下载逻辑拿到 m3u8 文本后解析出所有.ts分片地址。m3u8 的格式很简单以#开头的行是元信息不以#开头的行就是分片地址。有些 m3u8 里的地址是相对路径需要和 m3u8 的 URL 做拼接。import os from urllib.parse import urljoin base_url https://example.com/video/xxxxx.m3u8 m3u8_text resp.text ts_urls [] for line in m3u8_text.splitlines(): line line.strip() if line and not line.startswith(#): ts_urls.append(urljoin(base_url, line)) print(f共 {len(ts_urls)} 个分片)下载分片时建议加一个重试机制因为网络抖动很常见。每个分片保存为独立的.ts文件文件名按序号命名方便后面合并。os.makedirs(ts_cache, exist_okTrue) for i, ts_url in enumerate(ts_urls): for attempt in range(3): try: r requests.get(ts_url, headersheaders, timeout20) if r.status_code 200: with open(fts_cache/{i:04d}.ts, wb) as f: f.write(r.content) break except Exception as e: print(f分片 {i} 第 {attempt1} 次失败: {e})这里有个细节分片下载最好控制并发数。用ThreadPoolExecutor开 4 到 8 个线程就够了开太多容易被服务器限流反而更慢。我试过开 32 个线程结果一半请求被拒得不偿失。4.3 分片合并与格式转换所有分片下载完后用 ffmpeg 合并。ffmpeg 的 concat 协议可以直接读取一个文件列表来合并# 生成文件列表 for f in ts_cache/*.ts; do echo file $f filelist.txt; done # 合并 ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4-c copy表示不重新编码直接复制流速度极快。合并出来的 mp4 可以直接播放。如果遇到音画不同步或者时间戳问题去掉-c copy让它重新编码但会慢很多。提示ffmpeg 需要提前安装并加入系统 PATH。Windows 上可以去官网下载编译好的版本解压后把 bin 目录加到环境变量里。4.4 批量下载的队列管理如果要下载整部短剧需要把每一集的 m3u8 地址都拿到。这些地址通常在剧集列表接口里返回或者在播放页面的网络请求里能抓到。把地址收集到一个列表里然后循环调用上面的下载函数。批量下载要注意两点一是加延时每集之间 sleep 几秒避免触发风控二是断点续传记录已下载的集数中断后可以从上次的位置继续。我一般用一个简单的 JSON 文件记录进度import json progress_file progress.json def load_progress(): if os.path.exists(progress_file): with open(progress_file, r) as f: return json.load(f) return {completed: []} def save_progress(progress): with open(progress_file, w) as f: json.dump(progress, f)这样即使脚本中途挂了重新跑的时候也不会重复下载已经完成的集数。5. 常见问题与排查技巧实录5.1 Charles 显示 unknown 的几种原因“charles 抓包都出现 unknown”是搜索热词里高频出现的问题。unknown 的意思是 Charles 无法解密这个 HTTPS 请求原因通常有这几个第一SSL Proxying 没有配置对应的域名。Charles 默认只解密你手动添加的域名其他域名显示 unknown 是正常的。解决办法是在SSL Proxying Settings里加上目标域名或者直接加*:443通配。第二证书没有真正被信任。电脑端要检查证书是否在“受信任的根证书颁发机构”里移动端要确认是系统证书还是用户证书。Android 7 以上用户证书不被应用信任这是最常见的坑。第三应用使用了证书固定SSL Pinning。有些小程序会校验服务器证书的指纹这种情况下 Charles 的中间人证书会被拒绝。应对方法需要更高级的手段比如 hook 掉证书校验逻辑但这超出了本文的范围而且不同小程序情况不同。第四代理没有生效。检查手机或模拟器的代理设置是否正确电脑防火墙是否放行了 8888 端口。5.2 请求返回 403 的排查顺序Python 脚本跑起来返回 403按这个顺序排查检查Referer头是否和抓包时一致检查User-Agent是否完整复制检查Authorization或token是否过期检查 URL 里的签名参数是否还在有效期内检查是否有Cookie遗漏检查请求频率是否过高被限流我遇到最多的情况是签名过期。短剧平台的视频链接签名有效期通常只有几分钟到几十分钟如果你抓包后隔了很久才跑脚本链接早就失效了。解决办法是抓包后尽快测试或者分析签名生成算法在脚本里动态生成。5.3 分片下载中断和合并失败的应对分片下载中断的原因一般是网络波动或者服务器限流。应对策略是每个分片独立重试并且记录哪些分片失败了最后统一补下。合并失败最常见的原因是分片文件损坏或者不完整可以用 ffmpeg 的-err_detect参数来忽略一些错误但最好的办法还是确保每个分片都完整下载。还有一个坑是分片顺序。m3u8 里的分片顺序就是播放顺序但如果你用多线程下载保存的文件名一定要按索引编号不能按下载完成顺序。我见过有人用时间戳命名结果合并出来顺序全乱。问题现象可能原因解决方法Charles 显示 unknown证书未信任或域名未配置检查证书信任状态添加 SSL Proxying 规则请求返回 403请求头缺失或签名过期补全 Referer/UA重新抓包获取新链接分片下载失败网络抖动或限流降低并发增加重试次数合并后无法播放分片损坏或顺序错误校验分片完整性按索引顺序合并脚本跑一会就断token 过期加入 token 刷新逻辑或缩短下载间隔5.4 几个我踩过的坑和独家技巧第一个坑微信小程序的 User-Agent 不是固定的。不同版本的微信、不同系统UA 都不一样。如果你直接复制网上的 UA很可能被识别。正确做法是从 Charles 里复制真实的 UA。第二个坑有些短剧平台会对 IP 做限制。同一 IP 短时间内请求太多会被临时封禁。解决办法是控制下载速度或者换网络环境。这个我没有深入测试过换 IP 的方案因为涉及的东西比较敏感建议大家还是控制频率为主。第三个技巧用 Charles 的 Map Local 功能做调试。当你怀疑某个参数的问题时可以把响应映射到本地文件反复测试脚本逻辑不用每次都重新抓包。这个功能在Tools - Map Local里配置。第四个技巧保存 Charles 会话。抓包分析往往不是一次能搞定的把会话保存下来File - Save Session下次直接打开继续分析不用重新操作一遍小程序。6. 合规提醒与技术边界6.1 技术学习的合理范围写到这里必须说清楚这套技术方案的目的是学习网络协议分析、HTTP 请求复现和 Python 自动化脚本编写。抓包分析本身是网络工程和逆向工程中的基础技能广泛应用于接口调试、性能优化、安全测试等正当场景。但把技术用于下载有版权保护的内容或者绕过平台的付费机制这涉及法律风险。短剧内容通常有明确的版权归属付费观看是正常的商业模式。技术能力应该用在正道上比如帮自己的项目做接口调试或者分析自己有权访问的数据。6.2 替代的学习路径如果你想练习抓包和 Python 脚本有很多合法的场景抓取公开的天气 API 数据、分析自己网站的访问日志、调试自己开发的移动应用接口。这些场景同样能锻炼请求分析、参数构造、异常处理的能力而且没有任何合规风险。我在实际工作中抓包用得最多的场景是排查线上接口问题。比如用户反馈某个功能异常但日志里看不出问题这时候抓包看实际请求和响应往往能快速定位。这个技能的价值在这里而不是在下载别人家的付费内容。6.3 关于工具使用的建议Charles、Fiddler、Wireshark 这些工具都是正规的网络分析软件广泛应用于开发、测试、运维领域。学习它们的使用方法是提升技术能力的正当途径。但工具本身中性怎么用取决于人。我的建议是把精力放在理解协议原理和提升工程能力上而不是研究怎么突破别人的防护。Python 的 requests 库、ffmpeg 的音视频处理、多线程下载的并发控制这些都是非常有价值的工程技能。把它们用在正经项目上比如做一个自己的媒体资源管理工具或者给公司做一个接口自动化测试框架这些才是能写进简历、能提升职业竞争力的东西。最后分享一个我在实际项目中的体会抓包分析最大的价值不是拿到某个具体的数据而是培养一种“看透请求本质”的思维方式。当你能从一个 URL 和几个请求头里读出整个鉴权逻辑的时候这种能力在任何后端开发、接口对接、问题排查的场景里都用得上。这才是花时间研究这些东西的真正回报。