最近团队里来了个做客户端的新同事一天之内往电脑上装了 Charles、Wireshark、Fiddler、Proxyman还跑来问我有没有“更强”的抓包工具。我第一反应不是推荐哪款而是反问他你这次要看的是 HTTP 请求还是 TCP 重传他愣了一下说就是想看 App 调后端接口返回了什么。我说那好Wireshark 可以先卸了等要排查网络层再装回来。后来我把那天的对话整理成这篇文章。五款工具放在同一张标题下看起来像是五个竞品实际上一半以上的困惑都来自“拿错工具干错活”。这篇文章不打算做那种挨个贴官网功能的罗列而是把这几款工具按工作层级、适用平台、抓 HTTPS 的难易度、以及真实项目里容易踩的坑说清楚。看完你基本能自己判断我到底该装哪个。1. 先把门派分清楚两派抓包工具解决的是完全不同的两类问题1.1 五分钟看懂抓包工具的分层逻辑抓包这个词实际上覆盖了好几层网络位置。大多数人平时说的“抓包”是抓 App 或浏览器发出去的网络请求看 URL、Header、Body 和返回结果这叫应用层报文查看。Charles、Fiddler、Proxyman 干的就是这个活它们本质是HTTP 代理Proxy。还有一类抓包是把电脑网卡上流经的每一个数据包原样捕获下来看 TCP 握手有没有问题、有没有重传、哪个 IP 在跟谁通信这叫链路层/网络层嗅探。Wireshark 是这类工具里的标杆。而 TraceEagle 这类名字带着“Eagle”的移动端专项工具更像是冲着移动场景的痛点去的App 和小程序的代理配置、证书信任、Android 高版本限制这些问题它试图在工具内部直接解决掉降低使用门槛。把类型说清楚之后选型逻辑就清晰了一大半你要调试 HTTP/HTTPS 接口、做 mock、模拟弱网 →代理型选 Charles / Fiddler / Proxyman你要排 TCP 连接异常、看 TLS 握手细节、分析协议交互 →嗅探型用 Wireshark你是测试或移动端开发天天跟真机抓包打交道 → 在代理型基础上再评估是否引入 TraceEagle 这类移动专项工具1.2 中间人代理是怎么“解密”HTTPS 的很多人第一次用 Charles 抓 HTTPS 时有个困惑为什么装完证书就能看到明文了这不算破解而是**中间人代理MITM**的标准机制。流程是这样的客户端把 HTTPS 请求发给代理工具代理工具用自己的 CA 根证书临时签发一张目标域名的证书向客户端伪装成“服务器”与此同时它再以客户端身份向真正的服务器发起请求。两边各建立一条 TLS 连接代理工具在中间做明文转发。前提是客户端必须信任代理工具签发的那个 CA 根证书否则客户端会提示证书无效、直接掐断连接。理解了这个机制你就明白两件事第一凡是抓 HTTPS 的代理型工具第一步永远是“安装并信任它的根证书”这一步错了后面全白搭第二如果 App 里做了证书固定SSL Pinning只信任服务器预埋的那张证书那即便是 Charles 也照样抓不到这个问题我们后面细说。1.3 一张表先看五款工具的门派和平台工具类型核心原理默认端口平台HTTPS 明文Charles应用层代理MITM 代理8888Win / macOS / Linux需安装并信任根证书Fiddler Classic / Everywhere应用层代理MITM 代理8888WinEverywhere 跨平台需安装并信任根证书Proxyman应用层代理MITM 代理默认自动分配macOS / iOS需安装并信任根证书Wireshark网络层嗅探网卡混杂模式捕获不涉及Win / macOS / Linux默认看不到需额外配置会话密钥TraceEagle移动端专项代理 证书/配置自动化视工具而定通常配合真机使用需要按工具引导配置信任这张表先说结论Charles、Fiddler、Proxyman其实是同一类工具的三款代表Wireshark 是另一个物种TraceEagle 是移动场景下的专项方案。很多人纠结“选哪款”其实纠结错了方向。2. Charles 与 Proxyman移动端 HTTPS 调试的主战场2.1 Charles 抓 HTTPS 的标准链路Charles 在移动端调试界的地位相当于老黄历里的“装机必备”。Java 写的老牌工具跨平台支持做得好公司内网文档、网上教程几乎一半都是拿它演示的。它的抓包链路看起来很简单但每一步都有坑电脑与手机连到同一个局域网。手机上设置手动代理IP 填电脑局域网 IP端口 8888。这里注意电脑 IP 要查ipconfig或ifconfig看真实局域网地址别填成 127.0.0.1手机访问不到。手机浏览器访问chls.pro/ssl下载证书安装并信任。iOS 用户安装完描述文件后还要去“设置 → 通用 → 关于本机 → 证书信任设置”里把开关打开这一步经常被人漏掉。Charles 菜单里打开Proxy → SSL Proxying Settings勾选启用并添加要解密的域名。填*代表全部但生产环境最好按需开否则流量大时性能会比较吃力。我个人习惯是第 4 步放在最先做因为很多人抓不到包其实就是因为 SSL Proxying 没开证书倒是一路点“信任”了。2.2 “手机代理挂上了却抓不到包”的排查清单这个热搜词出现频率极高我几乎每周都能遇到一次。按下面的顺序排查通常几分钟内能定位现象一手机访问网页都打不开。说明代理本身没通先看电脑端 Charles 有没有弹窗提醒“Connection from ...”。没弹窗就检查手机代理 IP 和端口弹窗但打不开多半是没安装根证书。现象二网页能开但 App 的请求不出现。App 没走系统代理或者用了你代理 IP 之外的白名单。Android 上部分 App 走 TCP/UDP 直连或内嵌 WebView 不走代理这个问题 Charles 本身没办法。现象三HTTPS 请求一堆乱码看不到明文。SSL Proxying 没启用、证书没装、或者 App 做了证书校验。乱码说明流量确实经过了 Charles只是没被解包。现象四Android 手机上装了证书但 HTTPS 依然抓不到。优先考虑 Android 7.0 及以上版本的默认网络安全配置targetSdkVersion 大于等于 24 的 App 默认不信任用户 CA 证书。要么改 App 的network_security_config.xml临时信任用户证书要么把证书装进系统证书目录。这条是 Android 抓包头号杀手。现象五iOS 证书装了三遍还是不行。去“证书信任设置”里打开完全信任开关同时确认证书 Profile 在“已下载描述文件”里显示为“已验证”。2.3 Proxyman 在苹果生态里的优势如果团队主力是 iOS/macOS我建议认真看看 Proxyman。它原生支持 macOS 的 System Proxy一键开关不像 Charles 那样配置完老是忘记关代理导致电脑上不了网。UI 是 SwiftUI 重写的信息密度高且不杂乱尤其是请求列表里直接展示耗时、状态码、SSL 握手时间对排查接口性能很有用。Proxyman 对 iPhone 的抓包做了不少减法同一 Wi-Fi 下用手机扫码自动配置代理下载证书后它会一步步引导你在 iOS 上完成“安装描述文件 → 设置里信任证书”全过程避免掉进 iOS 的证书信任连环坑里。还内置了 DNS 域名映射、脚本注入 JS、请求重放等工具日常调试足够。2.4 两款怎么选维度CharlesProxyman跨平台Win / macOS / Linux主要是 macOS 生态界面风格经典稍显陈旧原生现代化信息密集iOS 引导手动步骤多内置引导更友好脚本定制较少主要靠外部工具内置 Script 面板性能大流量时偶发卡顿整体更轻快许可证付费付费两者的核心能力高度重合。如果你是 Windows 为主选 Charles 更稳如果主力机是 MacBook 且天天跟 iPhone 打交道Proxyman 的体验会比 Charles 舒服一个档位。至于 Charles 那些网上流传的注册码就算能用也属于灰色操作正规用建议直接买 License几十刀的价格摊到日常研发成本里其实是最划算的一笔账。3. FiddlerWindows 老兵的特性从 FiddlerScript 到弱网模拟3.1 先分清 Fiddler Classic 和 Fiddler EverywhereFiddler 也是代理型工具早期专为 Windows 设计。市面上教程里那个界面古老、开箱即用的版本叫Fiddler Classic免费但微软已经不太维护仅限 Windows。后来又出了Fiddler Everywhere基于 Electron跨平台界面现代化但是要订阅。很多教程把两者混着讲导致新人在 macOS 上下载了 Everywhere却对着 Windows 版截图找菜单自然对不上号。3.2 FiddlerScript一个被低估的生产力开关Fiddler 和 Charles 最大的差异在于FiddlerScript。它允许你用类似 C# 的脚本直接干预请求和响应。比如给特定接口的请求统一加签名头static function OnBeforeRequest(oSession: Session) { if (oSession.HostnameIs(api.example.com)) { oSession.RequestHeaders.Add(X-Debug-Token, dev-token-1234); } }再比如把某个接口的响应直接改成本地 JSON 文件前端不用等后端联调就能开发if (oSession.HostnameIs(api.example.com) oSession.PathAndQuery.StartsWith(/user/info)) { oSession.utilCreateResponseAndLoadFromFile(C:\\mock\\user_info.json); oSession.oRequest.FailSession(200, OK); }这些逻辑在 Charles 里也能做但大部分需要依赖 Map Local 和 Rewrite 的组合灵活度和可维护性都不如直接写段脚本。如果你的日常工作是接口联调、数据 mock、自动化构造异常场景FiddlerScript 值得你投入一小时去学。3.3 弱网测试的两种做法Fiddler 做弱网测试之所以被提到最多是因为它把“不好复现的弱网环境”变成了开关。最简单的做法Rules → Performance → Simulate Modem Speeds勾上就能模拟拨号上网级别的慢速。但这种方式对现在的 App 来说太粗糙我一般建议手动微调。打开FiddlerScript在OnBeforeRequest和OnBeforeResponse里加延迟if (m_SimulateModem) { // 每个请求延迟 300ms oSession[request-trickle-delay] 300; // 每个响应每 KB 数据额外延迟 150ms oSession[response-trickle-delay] 150; }这种做法的原理是让代理守住每一层收发数据时“挤牙膏”模拟高延迟、低带宽的效果。但要注意这只是 HTTP 层的延迟模拟模拟不了信号弱导致的丢包和断连。真正要模拟网络层丢包还得靠网络损伤仪或者 Linux 上tc命令Fiddler 只解决“够用”的问题。3.4 Fiddler 卸载后上不了网是怎么回事这个热搜词特别典型我见过的次数不比“Charles 抓不到包”少。原因不复杂Fiddler 在正常退出时会把系统代理设置还原但如果进程被杀掉、崩溃、或者卸载时没有用正规渠道退出系统代理就可能被留在127.0.0.1:8888指向一个已经不存在或已停止监听的 Fiddler。于是浏览器所有流量都被发到 8888 端口端口没人监听网络自然全断。解决办法分 Windows 和 macOSWindows设置 → 网络和 Internet → 代理把“使用代理服务器”关掉或者检查注册表里HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings的ProxyEnable是否为 0。也可以命令行执行netsh winhttp reset proxy重置。macOS系统设置 → 网络 → 详细信息 → 代理把“网页代理”和“安全网页代理”都关掉。这个坑的本质是代理工具接管了系统代理却没有在退出时还原。用任何代理型工具包括 Charles、Proxyman时都要养成习惯下班前先关掉抓包再退出程序而不是直接 CmdQ 强杀进程。4. Wireshark看得见每个字节但代价不低4.1 从“看请求”到“看网络”的思维切换很多人把 Wireshark 装完之后第一次抓包看到的是一屏密密麻麻的 TCP 包然后整个人就懵了。因为它和 Charles 的工作方式完全不同Wireshark 依赖 Npcap/WinPcap 驱动让网卡进入混杂模式把所有流经网卡的帧都复制一份不做任何“替客户端访问服务器”的中间人转发。这意味着它的能力范围远超 HTTPTCP 三次握手延迟、TLS 握手过程中用了什么版本和密码套件、某个连接是不是在疯狂重传、哪个 IP 的流量占满了网卡——这些都是代理型工具看不到的视角。使用它的基本路径选择要监听的网卡 → 应用显示过滤器 → 定位到目标连接 → 右键“Follow TCP Stream”重建完整会话。4.2 TLS 解密实操别再以为有证书私钥就能解Wireshark 默认看不到 HTTPS 明文因为它不是 MITM拿不到会话密钥。解密 TLS 的常用方法是通过环境变量让浏览器或其他客户端导出会话密钥再用密钥日志去还原Linux/macOS 在启动浏览器前执行export SSLKEYLOGFILE$HOME/sslkeylog.logWindows 上通过用户环境变量新建SSLKEYLOGFILE值为一个可写文件路径。打开 Wireshark进入Preferences → Protocols → TLS在(Pre)-Master-Secret log filename里填上同一个文件路径。重新抓包HTTPS 流量就能以明文呈现。注意一个细节这可能只对支持密钥导出的客户端有效部分 App 和静态链接的库不会写这个日志文件。另外TLS 1.3 普遍使用前向保密即使你拿到服务器的私钥也无法解密已经记录的流量会话密钥日志是唯一可行的还原路径。这个区别一定要弄清楚否则方向就错了。4.3 “为什么只显示 520 字节别人却能看到 2090 字节”这个热搜词一看就是新手在对比网络包时产生的困惑。实际原因通常是两个Wireshark 默认把每个 HTTP 消息拆成多个 TCP 段显示。列表里那一行只显示单个 TCP 段携带的 520 字节而完整的 HTTP 响应是 2090 字节被分成了 4 个段。想看全量数据要在 HTTP 消息上右键 → Follow → HTTP Stream这时 Wireshark 会把属于同一会话的所有 TCP 段按序列号重组显示完整内容。抓包时的 snaplen快照长度限制了每帧捕获的最大字节数。如果接口驱动的快照长度比较小长包会被截断只保留前 520 字节。修改方式是在抓包选项里把 Limit each packet to N bytes 改为 65535否则抓下来的包本身就不完整。顺便说一句改完 snaplen 也别忽略 Wireshark 的 TCP 重组开关里Allow subdissector to reassemble TCP streams默认是开启的如果你或者同事把它关掉了会出现“明明抓到了但 Follow HTTP Stream 却能折叠出一堆 HEX 乱码”的现象。4.4 Wireshark 的图表化分析到底有什么用Wireshark 自带的可视化能力在排查线上问题时报错率比“肉眼看日志”高很多。Statistics → Flow Graph能把 TCP 连接的建立、数据交互、断开过程按时间轴画出来一眼看出哪个阶段耗时最长Statistics → IO Graph可以叠加过滤条件比如对比某个服务端口的请求量和重传包数量判断是不是流量一高就开始疯狂丢包。我实际用过的一个案例排查某接口偶发超时后端日志什么都看不出来。用 Wireshark 抓包后发现客户端发出握手包后服务器回包在 3 秒后才到达确认是负载均衡层面或机房网络的丢包重传导致跟代码完全无关。这种结论没有 Wireshark 根本给不出来。5. TraceEagle移动端专项工具的差异化定位5.1 移动端抓包为什么这么难前面几款工具解释了这么多但真正到了移动端尤其是业务化程度高的 App 和小程序你会发现还是会遇到坎。我把这几年给团队做抓包培训时反复讲的三座大山再说一遍Android 7 的默认证书策略。targetSdkVersion 大于等于 24 的应用如果没在network_security_config.xml里显式允许用户安装的 CA 证书是无效的。想在用户设备上直接抓都是抓不到的。iOS 证书信任分两步。安装描述文件不算完还要到“证书信任设置”里手动打开完全信任。每台新设备都要走一遍测试同学经常在这里卡住。很多 App 和小程序不走系统代理。代理型工具依赖“客户端把流量发到代理端口”如果应用开发者直接在代码里发起 TCP/UDP 直连或者用系统级 HTTP/3 库绕过了传统代理Charles 这种普通代理就对它视而不见。小程序又是另一个世界微信自己带网络栈、整包加密是常态要用专用通道去调试。这就是移动端专项抓包工具的生存空间。5.2 TraceEagle 这类工具通常怎么解决问题TraceEagle 从搜索引擎关键词看主要面向的就是移动端抓包场景。这类工具的一般做法是把上述三座大山在工具里尽量自动化提供一键配置向导把代理 IP、端口、证书下载地址直接生成二维码手机扫码即可完成代理配置省去手工填 IP 的步骤。针对 Android 的证书问题给出可操作指引甚至内置检测脚本提示当前 App 是否因为网络安全配置拒绝信任用户证书。对小程序、H5、App 内嵌 WebView 提供分场景引导方便测试人员在不同入口下切换抓包会话。因为公开资料有限我不在这里编造它的具体菜单和版本功能但我可以负责任地说这类工具的核心理念就是让“不懂网络协议的测试人员”也能顺利抓到移动端 HTTPS 包把原本需要在 Charles 文档 运维知识三者之间来回切换的成本降下来。5.3 什么团队值得引入移动专项工具如果你是独立开发、偶尔抓一次包Charles 两篇教程足够应付但如果你是测试团队、需要每周给几十台真机配证书、天天处理小程序弱网问题那花点时间评估 TraceEagle 这类工具是值得的。评估时不要只看“能抓到包吗”重点看三件事证书信任流程有没有自动化引导能不能减少测试人员的重复操作对 Android 7 和小程序这两个老大难有没有针对性方案抓包结果能不能方便导出、共享、回放这一点在多人协作时非常关键。6. 实用的选型对照按你的日常场景直接选6.1 五款工具选型汇总表需求首选次选理由Windows 上调试 HTTP/HTTPS 接口Fiddler ClassicCharlesClassic 免费脚本能力强macOS 上调试接口 前端 mockProxymanCharles原生体验好iOS 引导完善跨平台统一团队协作CharlesProxyman教程多生态成熟抓移动端真机包且愿意折腾CharlesProxyman配置能力强社区问答多测试团队大批量真机抓包TraceEagle 这类专项工具Charles证书和场景引导更自动化排查 TCP/TLS/网络层问题Wireshark没有替代唯一的正解6.2 我现在的组合与日常使用姿势我的主力配置其实很固定日常联调用 Proxyman因为主力机是 MacBook天天面对 iOS 模拟器需要 mock 数据和做复杂规则时切到 Fiddler Everywhere遇到“连接就是不通”这类问题立刻开 Wireshark 看 TCP 层。Charles 反而用得少了但它依然是团队培训时最常用的教学工具因为资料最多、问题搜起来最方便。最后再分享一个实际操作里的小技巧不管用哪款代理型工具抓包结束后第一件事是关闭系统代理第二件事才是退出程序。这个顺序我吃了好几次亏才记住尤其是 Charles 强杀之后系统代理残留导致电脑“断网”的问题几乎每个人都经历过。把这一步变成肌肉记忆省掉的是大量查资料的时间。