简介：这份压缩包面向希望研究英语词汇学习工具“词达人”客户端运行机制与网络通信过程的学习者，围绕抓包调试场景整理，适合具备一定HTTP/HTTPS基础、想观察请求响应与学习进度同步等数据流的人群。包内共92个文件，以36个dll动态库、13个exe可执行程序、13个pdb调试符号为主，辅以dat数据、wav提示音频、config配置和少量脚本说明，压缩包约7.4MB，既有词达人工具主程序，也包含Fiddler代理、证书信任、回环启用、脚本插件等配套组件。已有8938人学习下载。读者可借助这套材料了解客户端与服务器之间的数据交换方式，结合调试符号和配置观察程序模块划分，并通过脚本、插件与代理组件理解HTTP/HTTPS流量的捕获、分析与重放思路；音频和界面资源也有助于还原工具交互细节。使用时需注意个人信息保护，并在合法授权范围内进行网络调试。

1. 抓包不是装个软件就行：一次词汇小程序的请求分析，我踩了工具的坑

最近搜“词达人 抓包”的人不少，大多是学生或者做学习工具的同学，想看看这类词汇学习小程序在登录、拉取词书、提交答题进度时到底发了哪些请求。我第一次上手时图省事，手机连上电脑代理就以为完事了，结果 HTTPS 请求一片红，小程序里的包一个都抓不到，折腾了一下午才发现是根证书没装对、信任开关没打开。后来换工具、改配置、写脚本，才把这条路走顺。这篇就按我真实的判断顺序讲：选工具的四个维度、三款主流工具逐项对比、真机复现的完整步骤，以及五个把我坑过的现场。新手能照着做，熟手可以拿我的标准去校准自己的经验。

2. 抓包工具怎么选：四个维度先立判断标准

动手下载之前，先想清楚你要抓的是什么。词汇类小程序的请求有它的特点：域名集中、接口以 JSON 为主、大量依赖登录态和加密签名，而且跑在手机上、经常藏在微信或小程序的沙箱里。这几个特点决定了工具不能随便挑。我一般不会一上来就比界面好不好看，而是按协议覆盖、移动端易用性、重放与脚本化、协作成本四个维度过一遍，谁的短板正好戳中我的场景，就先排除谁。

2.1 协议覆盖面与 HTTPS 解密能力

这是硬门槛，没有之一。现在几乎没有哪个小程序接口还走明文 HTTP，全是 HTTPS，甚至 HTTP/2。工具能不能作为中间人解密 HTTPS，取决于它能不能生成一张自己的根证书、让你在设备上信任。凡是不能做证书中间人的工具，界面再漂亮也只能看到一串 CONNECT 隧道，等于黑匣子。

判断方法很直接：装上工具后，看它默认是否开启 SSL 代理、能否导出一份可安装的 CA 证书、是否支持按域名白名单解密（有些工具的 SSL 代理是全局开关，配错了会把系统更新、推送这些无关流量也拦下来，反而制造麻烦）。mitmproxy 这类命令行工具在协议覆盖上最激进，HTTP/2、WebSocket 都能处理；Charles 和 Fiddler 对常规 HTTP/HTTPS 足够，但遇到一些新的传输形态时需要额外配置。如果你抓的目标只涉及普通 REST 接口，三者都够；如果你要盯 WebSocket 长连接或者服务端推送，就得优先考虑协议支持更全的那个。

还有一个容易忽略的点：证书算法和系统版本。新版本移动系统对证书有效期、密钥长度、信任链有更严的要求，老版本工具生成的证书可能装上去也不被信任。我一般会先去工具的更新日志里确认它最近一年有没有跟进这些系统变化，长期不更新的工具，协议覆盖再好也要打个问号。

2.2 移动端与小程序场景的易用性

抓手机上的包，比抓电脑上的包多一层麻烦：设备要连代理、证书要装到手机上、有的系统还要单独进设置里手动信任。工具的“移动端友好度”就体现在这些细节上。

Charles 的做法是给你一个局域网地址和端口，手机 Wi-Fi 代理填进去，然后浏览器访问一个固定地址下载证书，流程清晰，新手照着点就行。Fiddler 在 Windows 上体验类似，但跨到手机端时配置项藏得比较深，第一次用容易找不到证书下载入口。mitmproxy 最“素”，它给你的是命令行和端口，证书要你自己想办法弄到手机上，对熟悉命令行的人是优点，对新手就是门槛。

小程序还有一层特殊性：它跑在宿主 App 的沙箱里，有些请求不走系统代理，或者对证书做校验。这时候光靠“能装证书”还不够，得看工具能不能配合做 DNS 重定向、能不能改成透明代理模式、能不能导出请求给别的工具做二次处理。我踩过的坑是：手机代理明明配好了，浏览器能上网，小程序却提示网络异常——后来发现是目标请求做了证书固定，普通中间人证书直接被拒。这类问题不是工具本身的错，但选工具时最好挑一个日志足够详细、能让你一眼看出“是证书被拒还是根本没连上”的，排查效率差很多。

2.3 请求重放与脚本化扩展

抓包只是第一步，真正花时间的是“看懂请求、改参数、验证假设”。这就要求工具有重放能力和脚本扩展。

重放：抓到一条请求后，能不能一键改几个字段再发一次？Charles 有 Repeat 和 Compose，Fiddler 有 Composer，mitmproxy 靠命令行或脚本。对于要反复试参数含义的人来说，能可视化编辑再重发，比每次手写 curl 省太多时间。

脚本化：当你要处理几十上百条请求、要自动提取某个签名字段、要按规则过滤噪音时，图形界面的点选就不够了。mitmproxy 的 Python 脚本是这一维度的天花板，一个钩子函数就能拦截、改写、落盘；Charles 支持 Map Local、Rewrite、Breakpoints，能覆盖大部分改写需求，但逻辑一复杂就难维护；Fiddler 有 FiddlerScript（JScript/.NET），能力也不弱，只是学习曲线陡。

我的判断标准是：如果你只是临时看几条请求，图形工具的重放够用；如果你要做系统性的接口梳理、要写脚本批量跑，直接上能编程的那个，别在图形界面里硬凑。

2.4 跨平台与团队协作成本

最后一个维度经常被个人用户忽略，但在团队里很致命。Charles 是 Java 写的，Windows/Mac/Linux 都能跑，一份许可证跨平台用；Fiddler 传统版偏 Windows，跨平台要靠新版；mitmproxy 天生跨平台，命令行在哪都一样。

团队协作看两点：配置能不能共享、抓到的数据能不能沉淀。mitmproxy 的脚本和命令行参数天然可以进版本库，别人 clone 下来就能复现你的抓包环境；图形工具的配置导出没那么顺，经常是“我这边能抓、你那边抓不到”，最后靠截图沟通。如果你是要把抓包分析做成一个可复用的流程，而不是一次性调试，脚本化工具的协作优势会随着人越来越多而放大。

3. 三款抓包工具逐项对比：Charles、Fiddler、mitmproxy 谁更顺手

标准立完了，落到具体工具上。这三款是我这些年反复用的，各有各的脾气。下面按安装配置、界面过滤、脚本自动化三块逐项比，最后给一张取舍表。需要说明的是，工具版本一直在变，我给的是使用体验层面的判断，具体版本号以你装到的为准。

3.1 安装与证书配置难度对比

Charles 的安装最“傻瓜”，装完打开，默认就监听 8888 端口，界面上直接告诉你代理地址。证书这块，手机浏览器访问它提示的地址就能下载，装完在系统设置里信任一下即可，整个过程十分钟内能搞定。缺点是它默认全局解密，第一次用如果不配 SSL 白名单，会看到一堆无关请求，噪音大。

Fiddler 的安装在 Windows 上很顺，打开就抓本机流量。切到手机抓包时，需要先在设置里勾选“允许远程连接”，再重启生效，证书入口在工具栏里，不如 Charles 直观。我见过不少人卡在“手机连上了但没流量”，最后发现是防火墙没放行端口。

mitmproxy 的安装是命令行一条命令的事，但它不给你图形界面，证书要通过mitm.it这个地址在设备上下载，或者自己从配置目录里把 CA 证书导出来装。对习惯终端的人这叫干净，对新手这叫劝退。它的优势是一旦配好，启动就是一行命令，非常适合写进脚本。

3.2 界面操作与过滤能力对比

Charles 的界面是树状结构，按域名分组，左侧点开就能看请求和响应，过滤靠顶部的 Filter 框，支持按域名、按关键字。它对 JSON 的格式化展示做得不错，长响应也能折叠着看。缺点是请求一多，树会很长，得靠过滤缩小范围。

Fiddler 的会话列表更像一个表格，列可以自定义，排序和筛选灵活，适合快速扫大量请求。它的 Inspectors 面板分上下两栏看请求和响应，习惯之后效率很高。短板是界面偏“工程化”，第一次看会觉得信息密度太大。

mitmproxy 的界面是终端里的一个可交互列表，用键盘上下选择、回车看详情，支持/搜索过滤。它没有图形界面那种“一眼看全”的爽感，但胜在轻量和可脚本化——你甚至可以让脚本先把无关请求过滤掉，终端里只剩你要的那几条。

3.3 脚本扩展与自动化对比

这一项 mitmproxy 明显领先。它的 Python API 设计得比较顺手，拦截请求、改响应、落盘、做统计，几十行就能写出来，而且脚本能直接复用。Charles 的 Rewrite 和 Map Local 能覆盖“改某个字段”“把响应指向本地文件”这类需求，但要做条件判断、批量处理就吃力。Fiddler 的脚本能力不弱，但语言和生态偏旧，写起来没有 Python 那么顺。

如果你的目标只是“看懂一个接口”，图形工具的改写功能足够；如果你要“把一类接口的规律摸清楚”，脚本化工具省下的时间是以小时计的。

3.4 一张表看清三者取舍

结论不用一刀切：临时排查、要给不熟命令行的人用，选 Charles；Windows 环境、要快速扫大量会话，Fiddler 顺手；要把抓包做成可复现流程、要写脚本批量处理，mitmproxy 是首选。我自己的组合是日常用 Charles 看，遇到要批量分析就切 mitmproxy 写脚本，两套并存不冲突。

4. 真机抓包复现：从装证书到读懂一个完整请求

标准比完了，落到操作。下面以抓一个词汇小程序的接口为例，把从环境准备到读懂请求的完整路径走一遍。工具我用 mitmproxy 演示，因为它跨平台、步骤最透明，换成 Charles 或 Fiddler 逻辑一样，只是入口不同。

4.1 代理环境怎么搭

先把电脑和手机放到同一个局域网，电脑上启动抓包工具，记下它监听的端口（默认 8080）。然后手机 Wi-Fi 设置里，把代理改成手动，填电脑的局域网 IP 和这个端口。这一步的关键是 IP 别填错——很多人填了127.0.0.1，那是手机自己，当然连不上。

启动 mitmproxy 的命令很简单：

# 默认监听 8080，允许局域网设备连接 mitmproxy --listen-host 0.0.0.0 --listen-port 8080 # 如果只想用命令行落盘、不要交互界面，用 mitmdump mitmdump --listen-host 0.0.0.0 --listen-port 8080 -w capture.mitm

--listen-host 0.0.0.0表示监听所有网卡，手机才能连进来；只写默认值可能只绑本地回环。-w把原始流量写成文件，方便事后回放。启动后先在手机浏览器随便开个网页，能正常上网说明代理通了，再去开小程序，避免把“代理没通”误判成“小程序抓不到”。

4.2 证书安装与信任的差异

代理通了只是第一步，HTTPS 还看不到内容，因为没装根证书。mitmproxy 启动后，手机浏览器访问mitm.it，按系统类型下载对应证书。iOS 装完还要去“设置-通用-关于本机-证书信任设置”里手动打开完全信任，这一步不做，抓到的全是加密隧道；Android 高版本则要把证书装到系统证书区，普通安装到用户区可能不被某些 App 信任。

# 如果设备不方便访问 mitm.it，可以从配置目录直接导出 CA 证书 # 默认路径因系统而异，先找到 mitmproxy 的配置目录 ls ~/.mitmproxy/ # 里面通常有 mitmproxy-ca-cert.pem，把这个文件传到手机上安装

.pem是通用格式，iOS 和 Android 一般都能识别；如果设备只认.crt，改个后缀或转换一下即可。装完务必确认信任状态，这是后面所有步骤的前提。我在这一关卡过一次，证书装了但没在信任设置里打开，结果所有 HTTPS 请求都显示连接失败，排查了半天才回到这个开关。

4.3 抓到请求后重点看什么

证书生效后，终端里就能看到一条条请求。别急着翻响应体，先看三样东西：请求方法、完整 URL、请求头里的鉴权字段。词汇类接口的登录态通常藏在 Cookie 或 Authorization 头里，请求体则多是 JSON。

抓到一个“提交学习进度”的请求后，我从这几处判断它的结构：URL 路径能看出资源划分（比如/v1/study/progress），请求体的字段名能猜出业务含义（词 id、动作类型、时间戳），响应体则告诉你服务端返回了什么（成功标志、下一批词、积分变化）。把这些字段和你在界面上的操作对应起来，一个接口的语义就基本清楚了。

4.4 用脚本把重复分析自动化

手工看几条还行，接口一多就得靠脚本。mitmproxy 的脚本挂在启动命令上，可以在请求发出前、响应回来后各做一次处理。下面这个脚本做两件事：只保留目标域名的流量，把请求和响应落到 JSONL 文件里，方便事后用jq过滤。

# capture.py：按域名过滤并把请求/响应落盘 from mitmproxy import http import json TARGET_HOST = "api.example-words.com" # 换成你实际抓到的目标域名，此处仅作示例 def response(flow: http.HTTPFlow) -> None: # 只处理目标域名，过滤掉系统更新、推送等噪音 if TARGET_HOST not in flow.request.pretty_host: return record = { "method": flow.request.method, "url": flow.request.pretty_url, "status": flow.response.status_code, "req_headers": dict(flow.request.headers), "req_body": flow.request.get_text(strict=False), "resp_body": flow.response.get_text(strict=False), } # JSONL：一行一条，方便 grep / jq 增量处理 with open("words_capture.jsonl", "a", encoding="utf-8") as f: f.write(json.dumps(record, ensure_ascii=False) + "\n") def request(flow: http.HTTPFlow) -> None: # 给请求统一加个标记头，便于在列表里识别是不是自己触发的 flow.request.headers["X-Debug-By"] = "local-capture"

response钩子在收到响应后触发，request钩子在请求发出前触发，两者顺序是 request 先、response 后。TARGET_HOST一定要换成你实际抓到的域名，否则脚本什么都不记。get_text(strict=False)里的strict=False是为了避免二进制响应解码时报错，宁可拿到乱码也别让脚本崩。启动时把这个脚本带上：mitmdump -s capture.py，之后所有目标流量都会自动落盘，你只需要在最后用jq按字段筛，比在界面里一条条翻快得多。

5. 抓包分析常见问题排查：五个翻车现场逐个拆

抓包这件事，配环境只占三成，七成时间花在“为什么抓不到、为什么抓到了看不懂”。下面五条是我踩得最狠的，每条按现象、原因、解决写，遇到同类问题时可以对着排查。

5.1 手机连上代理但所有请求都失败

现象：手机 Wi-Fi 代理填好了，浏览器打不开网页，小程序直接提示网络异常。

原因：多半是代理地址或端口填错，或者电脑防火墙拦了入站连接。还有一种情况是电脑和手机不在同一网段，比如手机走了蜂窝数据、电脑连的是另一个 Wi-Fi。

解决：先确认手机和电脑在同一个局域网，用ping互相 ping 一下；再检查工具是否监听在0.0.0.0而不是回环地址；Windows 上记得放行工具端口的入站规则。这三步走完还不行，就把手机代理关掉试一次，确认问题确实出在代理上，而不是目标 App 本身没网。

5.2 HTTPS 请求全是 CONNECT 看不到内容

现象：请求列表里全是CONNECT开头的隧道，点进去只有加密数据，看不到 URL 和响应体。

原因：根证书没装、装了没信任、或者工具没对该域名开启 SSL 解密。三者占其一。

解决：先回到证书环节，确认设备上确实装了 CA 证书并且信任；再检查工具的 SSL 代理设置，看目标域名是否在解密范围内。很多工具默认只解密部分域名，需要手动把目标加进去。确认后重启工具、重连代理，再抓一次。

5.3 小程序抓不到包

现象：浏览器能抓，其他 App 能抓，唯独小程序一条请求都没有。

原因：小程序跑在宿主沙箱里，部分实现不走系统代理，或者对证书做了固定校验，普通中间人证书会被直接拒绝，表现就是“没请求”或“连接被重置”。

解决：先确认是不是证书固定——如果是，普通抓包手段基本无效，不要在这上面死磕，转而从接口文档、公开的调试工具或本地日志入手。如果只是不走系统代理，可以尝试透明代理模式或 DNS 重定向把流量引到工具上。这一步要清楚边界：抓包是为了理解协议，不是绕过安全机制，遇到硬性校验就换思路。

5.4 请求能抓但重放报错

现象：抓到一条请求，原样重发却返回鉴权失败或参数错误。

原因：请求头里的时间戳、签名、一次性 token 过期了，或者重放时少了某个隐式头。

解决：重放前先对比原始请求和你的重放请求，逐个头看差异；带时间戳或签名的字段通常有有效期，需要在有效窗口内重放，或者按规则重新生成。用 curl 重放时把关键头都带上：

# 原样重放一条抓到的请求，验证参数含义 # -X 指定方法，-H 带请求头（鉴权字段必带），--data-raw 带原始 body curl -X POST 'https://api.example-words.com/v1/study/progress' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <你的token>' \ --data-raw '{"wordId":1024,"action":"review","ts":1700000000}' \ -i

-i让响应头也打印出来，方便看状态码和返回类型。如果服务端对ts有时间窗校验，就把时间戳换成当前时间再试。重放报错九成是头和字段的问题，不是工具的问题。

5.5 脚本改包后响应乱码

现象：用脚本改写请求或响应后，返回内容是乱码，或者直接解析失败。

原因：改了 Content-Length 却没同步改 body，或者对压缩过的响应（gzip/br）直接做了文本处理。

解决：改 body 后要么同步更新 Content-Length，要么让工具自动重算；处理响应前先判断编码，压缩内容先解压再改。脚本里尽量用工具提供的文本接口，它会帮你处理编码，别自己手动切字节。改完先在一条请求上验证，确认没问题再批量跑。

6. 不同角色怎么配工具：我的最终结论和一套固定流程

绕了一圈，回到最实际的问题：你该用哪个。我的结论不是选一个“最强”的，而是按角色配一套组合。

具体到“词汇小程序抓包”这件事，我现在的固定流程是：先用 Charles 快速连一次，确认代理和证书没问题、能看到请求；一旦要深入分析多个接口，就切到 mitmproxy 挂脚本落盘，用jq按 URL 和状态码筛，把感兴趣的几条拎出来逐字段对照。这套流程的好处是轻量试错在前、批量处理在后，不会一上来就陷进脚本配置里。

回过头看，我最大的教训是太早纠结工具、太晚确认证书。抓包这件事，八成的“抓不到”都出在信任链没打通，而不是工具不行。从那以后我每次换设备、换系统版本，都强制先把“代理通不通、证书信不信”这两步单独验一遍，再谈抓什么包。这个习惯帮我省掉了大量“以为是工具问题、其实是环境问题”的来回折腾。工具会换、版本会变，这套先验环境的顺序我一直没改过。希望帮到你。

本文还有配套的精品资源，点击获取