做接口调试这几年Fiddler抓包一直是我处理各类前端网络请求的首选工具尤其是碰到微信小程序这种“看似封闭、实则到处都是HTTP请求”的场景时它的价值会一下子被放大。所谓利用fiddler抓包爬取微信小程序数据说白了就是让小程序在运行过程中发出的每一个接口请求都经过Fiddler中转和记录我们再从记录里找到返回数据的那个接口解析JSON、整理入库。这件事能帮我们搞清楚小程序的真实数据来源、接口参数结构、分页逻辑也能顺手把需要的数据批量导出来。适合刚接触小程序逆向分析、想做接口调试、或者单纯想把某个小程序里的公开数据整理成表格的开发者阅读。1. 小程序的数据从哪来先理解抓包的对象1.1 小程序本质上是“黑盒外壳加远程数据”小程序虽然运行在某个超级App内部但它和普通网页应用没有本质区别页面是本地渲染的壳真正的数据几乎全部依赖远程接口拉取。你看到小程序里的商品列表、文章内容、用户动态背后都是一次次网络请求请求返回的JSON再被渲染成界面。这意味着假如你有一个数据需求比如“把某资讯小程序的每日推荐内容汇总成表格”你不需要去逆向它的前端JS也不需要截图OCR只需要抓住它请求数据那一刻发出的HTTP/HTTPS流量找到返回目标内容的那个接口然后照着重放或者批量拉取就行。这里有个关键的认知小程序抓包抓的不是“小程序本身”而是它和服务端之间的通信。只要通信走的是标准HTTP协议栈Fiddler就能拦下来。微信小程序的网络库底层封装了标准的请求能力绝大多数情况下不会自己实现特殊协议所以用Fiddler这套方案是行得通的。1.2 为什么优先选Fiddler而不是其他工具市面上能抓包的工具有不少Chrome DevTools、Charles、Wireshark都有人用但我个人在抓小程序场景下始终优先选Fiddler原因很直接。Chrome DevTools只能抓浏览器里的请求小程序跑在手机App里它完全看不见。Wireshark倒是能抓网卡流量但看到的是加密的TLS报文还要自己拼TCP流效率太低。Charles功能上和Fiddler很像但它收费并且导出会话、写脚本处理数据时不如Fiddler顺手。Fiddler免费、支持Windows和macOS、开箱即用就能解密HTTPS流量导出的HAR文件是标准JSON结构后面想写脚本二次处理非常方便。工具能否抓小程序请求HTTPS解密免费导出数据方便度Fiddler能支持是高支持HAR/CSV/原始会话Charles能支持否中Chrome DevTools不能支持是仅限浏览器Wireshark能但极繁琐需额外配置是低结论就是在“抓微信小程序数据”这个具体任务上Fiddler是门槛最低、数据最规整的选择。2. 动手前的准备让Fiddler有能力解密小程序的通信2.1 安装Fiddler并开启HTTPS解密很多人装上Fiddler直接开抓发现小程序里显示的是乱码或者一条条灰色隧道原因就是没开启HTTPS解密。小程序的正式环境几乎全走HTTPS不解密的话Fiddler只能看到主机名和端口看不到具体URL和响应内容。操作步骤是打开Fiddler进入Tools - Options - HTTPS勾选Decrypt HTTPS traffic同时确保下面的Ignore server certificate errors选项也勾上。第一次勾选时Fiddler会生成一个根证书并提示“是否信任这个证书”选是。这个证书是整个解密过程的钥匙后续手机上能不能看到明文请求全看它有没有装好、有没有被信任。还需要检查Connections选项卡里的端口默认是8888记住这个数字后面手机配置指向时要用。如果你电脑上端口被占用就换成8889或者其他不冲突的端口改完重启Fiddler。2.2 把手机流量引到FiddlerFiddler现在相当于一个中转站手机上的流量只有经过它它才能看到内容。为此需要让手机和电脑处于同一个局域网然后在手机的WiFi设置里找到“网络配置”把原来的自动获取改成手动在服务器地址栏填上电脑的局域网IP端口填Fiddler监听的8888。这里有个容易搞混的点这一步不是要你装任何额外客户端完全是利用系统自带的网络指向功能让手机把HTTP和HTTPS请求转交给Fiddler处理。电脑IP怎么查在命令行里敲ipconfig找到无线网卡对应的IPv4地址即可。配置完成后手机浏览器随便打开一个HTTP页面测试能打开就说明流量已经通了Fiddler里会刷出一排新会话。2.3 手机安装并信任Fiddler证书流量通了但HTTPS请求还是解不开因为手机还没信任Fiddler生成的那个根证书。接下来用手机浏览器访问电脑IP加上端口号比如http://192.168.1.100:8888页面上会有一个Fiddler Root Certificate的下载链接点它下载证书。iOS设备下载后需要去“设置 - 已下载描述文件”里安装然后还要去“关于本机 - 证书信任设置”里把Fiddler证书的开关打开。这一步经常被忽略很多人证书装了但依然解密失败基本就是漏了最后的信任开关。安卓设备的情况稍微复杂一点不同版本对用户证书的限制不一样。Android 7及以上版本默认App不再信任用户安装的证书所以会出现“Fiddler能看到请求但响应解密不了”的情况。如果你的测试机正好是这样优先选择Android 6及以下的设备或者使用支持把证书装进系统证书目录的调试环境。实际操作中我通常准备一台旧安卓手机专门干这个省心很多。3. 正式开抓从一堆请求里捞出目标数据接口3.1 启动小程序前的过滤设置不设过滤直接抓Fiddler很快就会被淹没在几十上百条请求里里面混杂着图片、静态资源、统计上报、日志上报等各种噪音。所以在开始之前先把过滤器配置好能省一半时间。在Fiddler右侧面板找到Filters选项卡勾选Use Filters然后在Host栏里写上目标小程序的接口域名。问题是怎么知道接口域名如果你完全没头绪可以先用“不过滤”抓一轮看哪些请求返回的是JSON数据域名往往就藏在里面。一个更实用的办法是先不启动小程序打开Fiddler清空会话再去微信里打开目标小程序操作两三步就关掉。这样能保证Fiddler里留下的基本都是这个小程序自己发出的请求噪音少了很多。3.2 用关键字搜索直接定位接口会话抓下来之后如果目标数据是“文章列表”那接口URL里大概率包含“list”“article”“feed”“recommend”之类的词。在Fiddler左下角的搜索框里直接搜“list”或者“article”能快速锁定候选接口。更直接的方式是看响应内容。选中一个请求在右侧的Inspectors选项卡里点开Response区域如果显示的是JSON内容里有你正在找的那批数据字段那这个请求就是目标接口。比如你正在浏览小程序里的一篇文章然后看到某条请求的响应体里包含了这篇文章的标题和正文那它就是正文接口。再说一个定位技巧如果小程序页面是分页加载的往下滑动列表时出现的新请求往往就是下一页数据的接口。你连续滑几次看哪个请求反复出现且参数里带page、pageSize、offset、lastId之类的字段基本锁定分页数据源了。3.3 分析请求头和参数结构找到目标接口后先别急着导出数据把结构看清才是关键。看请求头里的User-Agent、Referer、token、sign等字段这些决定了你后续做数据提取时需不需要带上特定的身份信息。有的接口直接匿名访问就能返回数据有的则需要登录态这时请求头里会有一个token或者cookie后续如果要做批量拉取必须带上这个值。看响应体也很重要。多数情况下接口返回的JSON是下面这种结构{ code: 0, data: { list: [ {id: 1, title: 文章标题一, publish_time: 2025-01-10 09:00:00}, {id: 2, title: 文章标题二, publish_time: 2025-01-10 10:30:00} ], has_more: true, next_cursor: eyJvZmZzZXQiOjIwfQ } }这里面的next_cursor或者page参数就是翻页的关键。你要理解这个接口是怎么翻页的有的用page加1有的用lastId传最后一条记录的ID有的用cursor游标。只有搞懂了分页规则才能真正做到“把全部数据拉下来”而不仅仅是第一页。4. 把抓到的接口数据变成可复用的资源4.1 导出HAR文件保留现场证据抓包本身是一个实时过程小程序关闭、Fiddler停止之后这些会话如果不保存就没了。我在实际操作中习惯先导出HAR文件再写脚本处理这相当于给整个抓包过程拍了一张快照。导出方法在Fiddler里选中需要保存的会话可以全选也可以只选目标的几个请求然后File - Export Sessions - Selected Sessions格式选HTTP Archive v2.0就是HAR文件。导出的文件本质是个JSON里面按请求发生的顺序记录了每个请求的URL、方法、请求头、请求体、响应头、响应体、耗时等完整信息。这个文件放在本地你想什么时候解析都行不需要手机再连着电脑。4.2 用Python脚本解析HAR提取目标数据拿到HAR文件之后下一步就是写脚本把里面的文章标题、发布时间、阅读数之类字段整理出来。我习惯用Python标准库里的json模块就够用不需要额外装第三方包。核心逻辑是这样的读取HAR文件遍历其中的entries每个entry对应一次请求筛选出符合我们目标URL条件的条目从entry的response.content.text里取出响应字符串再解析成JSON提取需要的字段最后写入CSV或数据库。下面是一个可以直接改着用的示例脚本import json import csv from urllib.parse import urlparse # 1. 读取HAR文件 with open(target.har, r, encodingutf-8) as f: har json.load(f) entries har[log][entries] target_keyword api/article/list # 改成你抓到的目标URL片段 results [] for entry in entries: url entry[request][url] if target_keyword not in url: continue # 取出响应体文本 response_text entry[response][content].get(text, ) if not response_text: continue # 解析JSON提取字段 try: data json.loads(response_text) except Exception: continue items data.get(data, {}).get(list, []) for item in items: results.append({ id: item.get(id), title: item.get(title), publish_time: item.get(publish_time), url: url }) # 2. 写入CSV with open(output.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[id, title, publish_time, url]) writer.writeheader() writer.writerows(results) print(f共提取 {len(results)} 条记录)这个小脚本就是把“识别目标接口、解析返回JSON、落盘保存”这三个动作给固化下来。以后再抓到新的HAR文件直接跑一遍就行。如果你还想把每个接口的完整请求头都导出来研究也可以在循环里把entry[request][headers]一起写进结果。4.3 注意拿到的接口不要滥用能抓到数据接口并不代表就能随便大规模调用。我在文章开头也提过抓包更大的价值是搞清楚数据流转逻辑、辅助接口调试、做小范围的自用数据备份。如果要把某个小程序的数据做商业化用途一定要确认数据来源是否有授权、平台规则是否允许避免惹上不必要的麻烦。5. 常见问题与排查技巧实录5.1 证书装好了HTTPS请求还是解密不了这个问题出现频率最高。先检查手机是否真的信任了Fiddler根证书iOS要确认“证书信任设置”里的开关是打开状态安卓要确认证书装进了“用户证书”或“系统证书”对应的位置。再看Fiddler的Connections设置确认端口没有被占用以及Allow remote computers to connect这个选项有没有勾上不勾的话手机根本连不过来找不到信息。还有一种情况部分小程序对安全比较敏感会在客户端做证书校验也就是常说的SSL Pinning。遇到这种情况Fiddler默认配置是抓不到明文的你会看到请求是失败的或者连接被重置。这并不是Fiddler坏了而是服务端和客户端之间额外约定了一层证书锁定。你要是只想快速拿到数据换个更老版本的测试机或者用小程序自带的调试模式往往是更省力的路子。5.2 会话太多找不到哪个才是目标接口除了用Host过滤和关键字搜索还有一个技巧是看Content-Type。在Fiddler的QuickExec命令行里输入?json可以筛选出响应类型为JSON的请求目标数据接口基本都在里面。再配合时间顺序你刚点击小程序里的某个功能立刻出现的JSON请求就是那个功能对应的接口。我自己的经验是一次只专注找一个数据不要贪多。比如这次就找“文章列表”其他一概忽略。等把列表接口的规律摸清了再去找详情接口。一次抓太多注意力全被分散反而容易什么都找不到。5.3 分页数据重复或漏数据如果你是通过重放接口来拉全量数据分页参数必须核对清楚。有的接口第一页返回20条第二页的page参数是2有的接口则要求把上一页最后一条记录的id传进去。这两种写法的翻页规则完全不同搞混了要么一直拿到第一页要么跳过了中间几页。还有一个容易踩的坑数据是实时更新的你分页拉数据时如果中间正好有新的内容插入会导致某几页出现重复或缺失。解决办法是每次拉完一页记录下当前页最后一条的id或时间作为下一页的起点最后再对全局做一次去重看看有没有重复的id。5.4 模拟请求时提示签名错误不少小程序的接口都有一个sign参数这个值通常是根据请求参数、时间戳、密钥算出来的。你在Fiddler里看到它是明文但自己重放时如果改动了一个参数sign就和参数不匹配服务端就会拒绝。遇到这种情况不要硬刚先看看是不是有不需要签名的同类接口或者抓包时能不能直接拿到带正确sign的完整URL直接用原始请求来访问。如果非要从零构造签名就需要去看小程序前端的加密逻辑了那是另一个层面的工作难度会高不少。写在最后我个人在实际抓包中最大的体会是Fiddler只是一个入口真正有价值的是你拿到接口之后对数据结构的理解和对业务逻辑的梳理。把一次抓包做透胜过盲目抓十几轮。刚开始不顺手很正常多抓几次把过滤器、HAR导出、脚本解析这一整套流程走顺后面处理任何小程序的数据需求都会快很多。