干这行做开发这么多年抓包工具换来换去最后还是Charles、TraceEagle、Wireshark、Fiddler、Proxyman这几款在反复横跳。每次带新人或者帮同事排查问题总有人问到底用哪个好甚至有朋友因为手里工具太多反而不知道怎么下手。这篇文章就把这几款主流的抓包工具拉出来做一次横向对比说说它们的核心区别、适用场景以及我在实际项目里踩过的坑希望能帮你少走点弯路。先说个最重要的认知选抓包工具之前得先搞清楚你是在看请求还是在看网络报文。这是两条完全不同的技术路线很多人搞混了才导致抓包抓不到、解密解不开、过滤越搞越乱。下面我直接从最本质的差异说起。1. 抓包工具对比之前先分清楚两条技术路线1.1 代理型抓包工具面向应用层的调试利器Charles、Fiddler、Proxyman、TraceEagle 这四款本质上都属于代理型抓包工具。它们的核心原理是在你的设备和目标服务器之间充当一个中间人把原本直连的请求改为先经过本地代理转发于是代理就能看到甚至修改应用层的 HTTP/HTTPS 数据。这种方式有个巨大的好处就是非常贴近开发者的日常视角。你看到的就是某个URL发起了某个POST请求带了哪些参数响应回来什么 JSON 数据可以直接评价接口对不对、字段有没有拼写错误、响应结果是否符合预期因此特别适合做接口联调、Mock 数据、断点修改返回结果、弱网模拟这些日常工作。但代理型工具的短板也非常明确它只能处理应用层协议尤其是 HTTP/HTTPS。如果你要排查 TCP 握手、端到端延迟、DNS 解析异常、数据包乱序、VLAN 标签等底层网络问题代理型工具基本无能为力因为这些信息在它这一层已经包装掉了你根本看不到底层细节。1.2 嗅探型抓包工具面向全链路的协议分析显微镜Wireshark 是另一条路线的代表——嗅探型抓包工具。它不依赖代理而是直接通过操作系统提供的抓包接口从网卡层面把经过这台设备的所有数据包原样复制一份出来再在软件里做协议解析。这就意味着 Wireshark 能看到最底层的以太网帧、IP 报文、TCP 段的序号和标志位、TLS 握手的 ClientHello、DNS 查询报文等等。不管是分析一次网络请求慢在哪还是排查数据包是否被分片、某个 TCP 重传是否异常Wireshark 都是首选。不过Wireshark 的缺点也很明显它默认不给你高层级的请求/响应视角抓下来的数据是一堆报文需要自己用过滤器、Follow TCP Stream、统计工具去还原完整的请求链路学习成本明显高于代理型工具。很多新手第一次打开 Wireshark看到满屏的十六进制和协议栈直接就懵了。1.3 五款工具的核心定位速查表工具技术路线核心定位跨平台上手成本主要应用场景Charles代理型移动端/接口调试macOS/Windows/Linux中等HTTP/HTTPS抓包、Mock、弱网、断点Fiddler代理型Windows平台接口调试Windows为主中等HTTP/HTTPS抓包、AutoResponder、脚本扩展Proxyman代理型macOS/iOS生态体验优先macOS/Windows较低移动端抓包、多Tab调试、协议细节查看TraceEagle代理型国内团队轻量调试跨平台低日常接口联调、轻量Mock、团队分享Wireshark嗅探型全链路协议分析跨平台高TCP/IP分析、TLS握手、排障、协议学习所以你在选工具之前先问自己两个问题我是要调接口还是要查网络问题如果答案是前者从 Charles、Fiddler、Proxyman、TraceEagle 里选如果答案是后者Wireshark 几乎不可替代。当然最理想的状态是两类工具各留一个互补使用。下面我逐个展开说说选型和注意事项。2. 五款工具逐一点评定位、强项和硬伤2.1 Charles移动端接口调试的事实标准Charles 在移动开发圈子里的地位有点像青花瓷这个外号一样深入人心。它基于 Java 开发跨平台但实际使用体验在 macOS 上最顺滑。它的核心优势有三个第一SSL Proxying 的配置非常灵活。你可以针对某一个域名单独开启 HTTPS 解密也可以配置通配符这在业务复杂、域名繁多的项目里很实用。我一般会把*.example.com这类业务域名放进去然后让其他外部域名的流量保持原样减少证书解密的干扰。第二Map Local / Map Remote 功能做得非常顺手。右键一个请求可以直接 Save Response 存成文件然后通过 Map Local 映射回来再配合 Rewrite 功能就能实现比较完整的 Mock 流程。前端界面还没开发好的时候我用这套方案先给 App 喂数据完全不影响联调进度。第三Breakpoints 断点功能比较稳定。在请求发出前拦截、在响应返回前拦截都能直接修改报文内容再放行。这比改完代码重新跑一遍要快太多了。不过要注意断点开启后如果忘了关会导致接口像是卡死了一样实际上是被断点挂住了排障时容易吓自己一跳。Charles 的硬伤在于手机端抓 HTTPS 包需要安装并信任证书而且 Android 7.0 之后很多 App 默认不信任用户证书这时候要么用「安卓系统证书」方案需要 root 或刷机要么依赖 App 内部配置的调试包。这个问题是代理型工具的共性但 Charles 的文档对这部分写得不太直白新手很容易卡在证书安装了还是解密失败这一步。2.2 FiddlerWindows 平台的免费老将Fiddler 是老牌的 Windows 抓包神器。Fiddler Classic 版本完全免费功能也足够强大。因为我早期主要用 Windows 做开发Fiddler 是我接触最早的一款抓包工具印象最深的是它的 AutoResponder 和 FiddlerScript 脚本扩展能力。AutoResponder 可以理解为可视化的 Mock 规则。你可以把某些 URL 请求直接指向本地文件或者另一个 URL也可以自定义响应状态码和响应头。实际项目中我经常用它来模拟 404、500 这类异常响应测试前端对错误分支的处理是否全面。这点和 Charles 的 Map Local 异曲同工但 Fiddler 的规则匹配方式更直观一些还支持正则。FiddlerScript 是它区别于其他工具的大杀器。这个东西本质上是让用户用 C# 脚本去控制整个代理的行为你可以重写请求头、篡改响应体、自定义延迟、统计某个接口的耗时曲线。很多公司内部自研的弱网测试工具其实就是 FiddlerScript 的功能封装出来的。如果你愿意折腾脚本Fiddler 的扩展深度是目前几款工具里最高的。需要留意的是Fiddler 的默认界面比较陈旧第一次打开会看到一堆工具栏和监控面板新手容易觉得乱。而且 Fiddler Classic 的跨平台能力很弱在 macOS 上体验一般。同时它默认会修改系统代理设置如果卸载的时候没有正常还原就可能导致电脑上不了网。这个问题我在下面第4节会专门讲因为它太常见了。2.3 ProxymanmacOS 生态里的体验派Proxyman 是我近两年在 Mac 上切换频率较高的工具主要是因为它确实把抓包体验做得很现代。如果你经常在 macOS 和 iOS 模拟器上调试Proxyman 的流畅度会让你觉得 Charles 像是上一代产品。它的多 Tab 设计我很喜欢。一个 Tab 抓 API 请求另一个 Tab 看 WebSocket再开一个 Tab 抓 GraphQL互不干扰。相比 Charles 把所有请求堆在同一列里Proxyman 对复杂场景的管理更清爽。另一个亮点是它对 iOS 模拟器的支持很友好可以做到一键配置代理、自动信任证书省掉很多手动设置步骤。Proxyman 还内置了一些方便的小工具比如请求编辑重放、响应改写、限速模拟基本覆盖了 Charles 的常见功能。界面颜值高、交互顺畅对新手尤其友好配置证书的引导也做得很清楚不像 Charles 那样需要你自己去网上翻教程。不过 Proxyman 目前在国内的讨论度和团队普及率不如 Charles如果你习惯 Windows 或团队同事都在用 Charles那和同事对齐工具还是需要考虑的。2.4 Wireshark网络协议分析的显微镜前面说过Wireshark 是嗅探型工具和前面三款完全不是一个维度。它的强项在于全量抓包和协议分析。我举一个真实场景有一次线上反馈某个接口偶尔超时代理型工具只能看到请求发出后等了很久才返回但定位不了原因。这时候打开 Wireshark抓同一周期的流量立刻就能看到 TCP 重传次数明显偏高而且部分数据包到达顺序是乱的有的包还发生了重复 ACK。顺着这个线索最后定位到是某台负载均衡设备的 TCP 参数配置不当导致的。这种问题用 Charles 或 Fiddler 是根本看不到的。Wireshark 的过滤表达式是它最核心的技能之一。举几个常用的http // 只看HTTP请求 tcp.port 443 // 只看443端口 ip.addr 192.168.1.10 // 只看某个IP的流量 tls.handshake.type 1 // 过滤TLS ClientHello tcp.analysis.retransmission // 过滤TCP重传实际调试时我通常先用http || tls粗筛一轮再配合 Follow TCP Stream 查看完整的请求-响应内容。需要提醒的是Wireshark 抓包时默认会把当前机器的网卡设置为混杂模式在共享网络或者公司交换机下你可能会看到很多其他设备的广播包这时候过滤器的价值就体现出来了。另外Wireshark 默认并不自动解密 HTTPS需要你通过配置 TLS 密钥日志文件才能读取加密内容。这块操作略微有点门槛但用好了就是排障利器我下面会详细讲。2.5 TraceEagle国产轻量级工具的务实之选TraceEagle 可能相对小众很多人第一次听。它本质上也是一款代理型抓包工具走的路线是轻量、快捷、少配置。在实际使用中既不需要像 Wireshark 那样理解协议栈也没有 Fiddler 那么重的规则体系它更强调图形化操作和项目内共享数据。对国内团队来说TraceEagle 对中文环境比较友好界面和文档的门槛低处理 HTTPS 解密的手续也简化了很多。调试日常接口时它完全能满足查看请求、修改参数、模拟响应这些核心需求。如果你所在团队对工具选型没有强制要求只是希望新人能快速上手TraceEagle 可以作为一个降低沟通成本的选项。但也要客观地讲TraceEagle 在功能深度上确实不如 FiddlerScript 和 Charles 那么复杂社区资料和第三方教程也少遇到刁钻问题往往只能靠自己琢磨。我的建议是把它当作快速验证和入门教学的辅助工具真正做复杂调试和深度协议分析时还是得回到前面那几款专业工具上。3. 核心场景实战同一个需求五款工具怎么选工具选型不能只看参数关键要看具体场景。下面我按高频场景拆解一下方便你直接对号入座。3.1 HTTPS 解密抓包信任证书与密钥日志如果你要抓取的是 HTTPS 流量代理型工具和 Wireshark 的解密思路完全不同。代理型工具Charles、Fiddler、Proxyman、TraceEagle采用中间人的方式先安装代理工具自己生成的根证书然后代理在客户端和服务端之间分别建立 TLS 连接这样代理就能读到明文。操作上基本是三步走在电脑端安装并信任代理工具的根证书。在手机端或者浏览器端配置代理并下载、安装同一根证书。如果是手机端还要在系统的证书信任设置里主动信任这个证书iOS 往往比 Android 多一步。这一步最常见的坑是 iOS 上证书装了但提示未受信任。正确做法是安装描述文件后去「设置-通用-关于本机-证书信任设置」里把开关打开。这一步漏掉Charles/Proxyman 里的 HTTPS 请求会全部显示为乱码或者握手失败的密文。Wireshark 的解密思路不一样。它不是中间人不改变流量路径只是把浏览器或客户端生成的 TLS 会话密钥文件喂给 Wireshark让它逆向解密已经捕获的加密报文。具体配置路径是编辑 → 首选项 → Protocols → TLS → 在 (Pre)-Master-Secret log filename 里填入 SSLKEYLOGFILE 文件路径。要生成这个密钥日志文件可以在本机设置环境变量SSLKEYLOGFILE/path/to/sslkeylog.log配套使用 Firefox 或者 Chrome 时浏览器会自动把会话密钥写到这个文件里。之后在 Wireshark 里同时开着抓包和密钥文件就能看到 HTTPS 明文内容。这个功能对排查证书链异常、TLS 版本协商失败这类问题特别有效。3.2 手机 App 抓包同一网络、代理设置、证书信任三件套手机抓包是最多朋友问我的场景不管用 Charles、Proxyman 还是 Fiddler原理都是一样的。最常见的失败原因不外乎三个电脑和手机不在同一个局域网。手机代理的 IP 或端口填错。HTTPS 证书没有安装信任尤其是 iOS。先说第一项电脑和手机必须在同一个网段手机代理的 IP 填写的是电脑的局域网 IP而不是 127.0.0.1。端口方面Charles 默认 8888Fiddler 默认 8888Proxyman 默认 9090如果你改过端口手机上要同步修改。第二项代理设置完成后先在电脑端浏览器里随便访问一个 HTTP 网站确认代理能正常转发再去测手机这样可以降低排查难度。如果电脑端浏览器走代理没问题但手机端还是抓不到再回到证书和网络隔离的问题上。第三项Android 7.0 之后的问题比较麻烦。很多 App 在代码里设置了默认不信任用户证书就算你安装了用户证书App 发起的 HTTPS 请求仍然会失败。这时候可选的方案是在 App 的networkSecurityConfig里增加对用户证书的信任重新打包调试包。使用代理工具配合修改 App 代码在测试环境禁用证书校验。使用支持系统证书导入的设备通常是 root 后的设备。iOS 这边相对简单一点普通开发模式下安装描述文件并信任就能抓。但如果有 App 做了证书固定Certificate PinningCharles 和 Proxyman 也会失效基本上只能靠注入脚本或者 Hook 绕过作为日常调试手段要做好心理准备。3.3 弱网测试与 Mock 数据Charles、Fiddler、Proxyman 的正面交锋弱网测试是移动端开发绕不开的环节。Charles 的 Throttle Settings 可以直接模拟 3G、4G 网络也能自定义带宽、延迟、丢包率。Fiddler 自带 Simulate Modem Speeds 规则更精细的延迟可以通过 FiddlerScript 里的OnBeforeRequest加上一段延时来实现。Proxyman 的 Network Condition 面板做得更直观拖动滑块就能改网络参数。Mock 数据这块前面提到过 Charles 的 Map Local / Map Remote、Fiddler 的 AutoResponder、Proxyman 的 Map Local / Remote 大同小异。我分享一下日常工作中比较顺手的 Mock 流程先用抓包工具录制一条真实请求。右键保存 Response存为本地 JSON 文件。开启 Map Local / AutoResponder把请求 URL 映射到本地文件。修改本地 JSON 后刷新页面前端就能看到新的 Mock 数据。这个流程避免了反复让后端改数据也能模拟各种极端返回。但有个细节要注意映射成功后抓包工具的缓存可能会让你误以为还在请求服务器实际上流量已经指向本地文件了排查问题的时候记得先看请求的 Source 是 Remote 还是 Local。3.4 底层协议分析Wireshark 的专属主场如果你要做 TCP/UDP 层面的分析、Packet Loss 检测、VLAN 标签查看、TLS 握手细节那没得商量直接上 Wireshark。它不仅可以看单包结构还能用统计功能做传输耗时分析。我举个例子。当你想看一个 HTTPS 请求在 TCP 三次握手上花了多久可以设置过滤器tcp.port 443然后找到建立连接的第一个 SYN 包。Wireshark 的 Time 列会显示每个包的相对时间戳从 SYN 到 SYN-ACK 再到 ACK 的间隔基本就是一次连接的握手耗时。如果这个延迟明显偏高再往下看是不是有重传基本上问题就明朗了。再比如排查某些报文为什么显示不了完整内容其实很多情况下是 TCP 的分段重组问题。你在 Wireshark 里看到每个包最多 1514 字节左右以太网帧的限制如果应用层一次发了 2090 字节TCP 会按 MSS 把它切分成多个段Wireshark 默认会尝试重组只要你在 Preferences 里开启 TCP 的 Allow sub dissector to reassemble TCP streams 就好。关于这个我在第4节会专门展开讲。4. 真实踩坑与问题排查记录4.1 抓不到包的通用排查顺序不管是你第一次用 Charles 抓手机包还是 Fiddler 突然失灵按照下面这套顺序排查能解决九成问题确认电脑和手机/设备在同一局域网。确认代理 IP 是电脑的局域网 IP不是localhost。确认代理端口没被其他进程占用也没有被防火墙拦截。关闭手机上的其他的代理或加速类 App避免数据被二次转发。在电脑浏览器里先验证代理抓包是否正常再跳到手机端。HTTPS 请求解密失败的话检查证书是否安装、是否信任。如果以上都正常但有些 App 请求还是抓不到考虑是不是做了证书固定。我在实际工作中发现有相当一部分抓不到包的案例最后都卡在代理端口或网络环境问题上。比如某些企业办公网络开启了 AP 隔离手机和电脑虽然连着同一个 WiFi但彼此之间根本不通这时候代理自然就无效了。这种情况下可以尝试用手机开热点让电脑连手机热点重新组网来调试。4.2 Wireshark 为什么只显示 520 字节怎么看到 2090 字节这个问题被搜索得非常多说明很多人第一次用 Wireshark 都会遇到同样的困惑。我先说结论Wireshark 并不会只显示 520 字节所谓只显示 520 字节通常指向两个层面的原因。第一种情况你看到的单个数据包本来就只有 520 字节。以太网的 MTU 通常是 1500 字节扣掉 IP 头 20 字节和 TCP 头 20 字节MSS 一般是 1460 字节但实际应用层发送的数据量不一定能填满 MSS。如果发送方一次只写了 500 字节数据TCP 段总长度就大约是 500 20(TCP) 20(IP) 540 字节加上以太网头 14 字节和帧校验 4 字节就接近 560 字节。520 字节出现要么是应用层发送量小要么是某些控制报文只有几十字节。这并不代表 Wireshark 抓包不全。第二种情况更常见你抓到了一个大的应用层数据但 Wireshark 没进行重组只看到一个个分段。当应用层一次要发送 2090 字节的数据TCP 会把它拆成两个或更多个段。Wireshark 默认会根据配置对 TCP 流进行重组但重组的开关有时候会被误关。你可以在「编辑-首选项-Protocols-TCP」里确认以下选项是开启的Allow subdissector to reassemble TCP streamsReassemble out-of-order segments开启之后Wireshark 会在报文列表里显示TCP segment of a reassembled PDU并通过 Follow TCP Stream 把完整的数据还原出来。你看到的 2090 字节就不再是分散的多个包而是合并后的整体了。如果你关心的只是某列显示的数据大小还可以在列头自定义一个frame.len列这样每个包的总长度一目了然不用靠眼睛去数十六进制内容。顺便提一句有些网卡开启了巨型帧Jumbo Frame单包能承载 9000 字节以上不过那是在特定网络环境里才有的情况日常看 1500 左右才是正常现象。4.3 卸载 Fiddler 后上不了网这个问题很经典很多朋友卸载 Fiddler 之后发现浏览器打不开网页了其实就是 Fiddler 卸载时没有把系统代理设置还原。Fiddler 在运行期间会把系统代理指向 127.0.0.1:8888正常退出的时候会还原但如果强杀进程、崩溃退出或者卸载流程不正常代理就会一直残留。解决办法很简单。按 Win R 打开运行输入inetcpl.cpl回车打开 Internet 选项在「连接」选项卡里点「局域网设置」取消勾选为 LAN 使用代理服务器确定保存。如果是命令行环境也可以用netsh winhttp reset proxy把 WinHTTP 代理清掉。再不行就检查一下环境变量里有没有 HTTP_PROXY 或 HTTPS_PROXY有些软件会写这个变量也会导致请求全部走到无效代理上。这类问题排查思路就是先把所有层级的代理设置恢复默认再逐步确认。4.4 证书相关的疑难杂症代理型抓包工具用久了多多少少都会遇到证书问题。我把常见的几个整理了一下现象常见原因处理方式手机装了证书但 HTTPS 显示错误iOS 没在证书信任设置里手动信任到「设置-通用-关于本机-证书信任设置」打开开关Android 装了证书但 App 请求失败Android 7.0 默认不信任用户证书修改 networkSecurityConfig 或使用系统证书方案电脑浏览器提示证书无效证书链不完整或过期重新导入根证书并确认始终信任抓包工具导出证书后手机无法安装描述文件文件类型或日期格式问题用代理工具自带的导出按钮不要手动改后缀某个域名 HTTPS 解密失败其他域名正常SSL Proxying 没勾选该域名在 SSL Proxying 设置里添加该域名有个容易被忽略的点Charles 和 Fiddler 这类工具的根证书一般默认有效期为几年甚至十年但实际用起来还是会遇到证书过期的问题。尤其 Charles很多人安装后一直不更新某天突然发现所有 HTTPS 请求都失败了一查发现是根证书过期。这时候去工具里重装一次证书并把系统里的旧证书删掉就能恢复正常。5. 选型落地建议别再纠结哪个最好5.1 按岗位职责选型如果你是前端开发、移动端开发、测试工程师日常工作就是调接口、看请求参数、做 Mock、模拟弱网那《Charles Fiddler / Proxyman TraceEagle》这一类代理型工具足够用了。不同平台的推荐组合可以这样排macOS iOS 生态优先选 Proxyman其次是 Charles。Proxyman 体验更现代Charles 兼容性和社区资料更成熟。Windows 生态优先选 Fiddler它的系统集成和脚本能力无可替代如果团队统一用 Charles那 Charles 跨平台也可以。对中文文档和低上手成本有要求TraceEagle 值得一试作为团队辅助工具没问题。如果你负责网络运维、后端性能排查、系统排障、或者是做协议方向的技术研究Wireshark 是必须掌握的核心工具。它给你的不是接口长什么样而是网络本身发生了什么。这类工作里代理型工具再花哨也只是辅助手段。5.2 按目标协议选型抓 HTTP/HTTPSCharles、Fiddler、Proxyman、TraceEagle 都行。看平台偏好看团队习惯。抓 WebSocket、GraphQLProxyman 体验不错Charles 也支持Fiddler 需要额外配置脚本。抓 TCP/UDP、DNS、TLS、QUIC 基础细节只有 Wireshark 合适。抓本地回环流量LoopbackWireshark 在 Windows 上需要安装 Npcap 并注意回环抓包的限制Fiddler 在代理层面就能看到 localhostCharles 也可以。5.3 组合拳打法两台工具互补使用最后分享一套我自己的组合打法也是我认为最省心的工作流。日常接口调试我用 Charles 或 Proxyman 解决因为它们抓包、Mock、弱网一条龙效率很高。遇到线上问题排查我会开 Wireshark 全量抓包再配合代理型工具做业务请求的定位一边看业务语义一边看协议细节。TraceEagle 更多是在团队新同事入门培训时用它简单直观最快让对方建立抓包的概念等到上手之后再切到更高级的工具。一个具体的排障过程可以这样描述先用 Wireshark 抓了 30 秒流量发现某个请求存在大量 TCP 快速重传然后切换到 Charles 看这个接口是否触发了重试逻辑最后定位到是客户端在重传超时后发起了二次请求导致重复提交。如果只依赖任何一款单一工具这个问题的定位就会很绕。跨工具对照查看数据往往是最快的路径。根据我个人的实际体验抓包工具这件事真的不是越多越好也不是越贵越好。把一款代理型工具用熟再来学 Wireshark 的过滤和重组就已经能覆盖绝大多数开发调试场景。那些花哨的脚本和扩展等你真正遇到重复性高、手工处理效率低的场景时再回过头来研究学习动力会强很多。希望这篇对比能帮你少踩几个坑快速找到顺手的那款工具。 
长河君 · 2026/9/12 8:27:01 · 阅读 1.2k 抓包工具横向对比：五大主流抓包工具选型与实战踩坑
干这行做开发这么多年抓包工具换来换去最后还是Charles、TraceEagle、Wireshark、Fiddler、Proxyman这几款在反复横跳。每次带新人或者帮同事排查问题总有人问到底用哪个好甚至有朋友因为手里工具太多反而不知道怎么下手。这篇文章就把这几款主流的抓包工具拉出来做一次横向对比说说它们的核心区别、适用场景以及我在实际项目里踩过的坑希望能帮你少走点弯路。先说个最重要的认知选抓包工具之前得先搞清楚你是在看请求还是在看网络报文。这是两条完全不同的技术路线很多人搞混了才导致抓包抓不到、解密解不开、过滤越搞越乱。下面我直接从最本质的差异说起。1. 抓包工具对比之前先分清楚两条技术路线1.1 代理型抓包工具面向应用层的调试利器Charles、Fiddler、Proxyman、TraceEagle 这四款本质上都属于代理型抓包工具。它们的核心原理是在你的设备和目标服务器之间充当一个中间人把原本直连的请求改为先经过本地代理转发于是代理就能看到甚至修改应用层的 HTTP/HTTPS 数据。这种方式有个巨大的好处就是非常贴近开发者的日常视角。你看到的就是某个URL发起了某个POST请求带了哪些参数响应回来什么 JSON 数据可以直接评价接口对不对、字段有没有拼写错误、响应结果是否符合预期因此特别适合做接口联调、Mock 数据、断点修改返回结果、弱网模拟这些日常工作。但代理型工具的短板也非常明确它只能处理应用层协议尤其是 HTTP/HTTPS。如果你要排查 TCP 握手、端到端延迟、DNS 解析异常、数据包乱序、VLAN 标签等底层网络问题代理型工具基本无能为力因为这些信息在它这一层已经包装掉了你根本看不到底层细节。1.2 嗅探型抓包工具面向全链路的协议分析显微镜Wireshark 是另一条路线的代表——嗅探型抓包工具。它不依赖代理而是直接通过操作系统提供的抓包接口从网卡层面把经过这台设备的所有数据包原样复制一份出来再在软件里做协议解析。这就意味着 Wireshark 能看到最底层的以太网帧、IP 报文、TCP 段的序号和标志位、TLS 握手的 ClientHello、DNS 查询报文等等。不管是分析一次网络请求慢在哪还是排查数据包是否被分片、某个 TCP 重传是否异常Wireshark 都是首选。不过Wireshark 的缺点也很明显它默认不给你高层级的请求/响应视角抓下来的数据是一堆报文需要自己用过滤器、Follow TCP Stream、统计工具去还原完整的请求链路学习成本明显高于代理型工具。很多新手第一次打开 Wireshark看到满屏的十六进制和协议栈直接就懵了。1.3 五款工具的核心定位速查表工具技术路线核心定位跨平台上手成本主要应用场景Charles代理型移动端/接口调试macOS/Windows/Linux中等HTTP/HTTPS抓包、Mock、弱网、断点Fiddler代理型Windows平台接口调试Windows为主中等HTTP/HTTPS抓包、AutoResponder、脚本扩展Proxyman代理型macOS/iOS生态体验优先macOS/Windows较低移动端抓包、多Tab调试、协议细节查看TraceEagle代理型国内团队轻量调试跨平台低日常接口联调、轻量Mock、团队分享Wireshark嗅探型全链路协议分析跨平台高TCP/IP分析、TLS握手、排障、协议学习所以你在选工具之前先问自己两个问题我是要调接口还是要查网络问题如果答案是前者从 Charles、Fiddler、Proxyman、TraceEagle 里选如果答案是后者Wireshark 几乎不可替代。当然最理想的状态是两类工具各留一个互补使用。下面我逐个展开说说选型和注意事项。2. 五款工具逐一点评定位、强项和硬伤2.1 Charles移动端接口调试的事实标准Charles 在移动开发圈子里的地位有点像青花瓷这个外号一样深入人心。它基于 Java 开发跨平台但实际使用体验在 macOS 上最顺滑。它的核心优势有三个第一SSL Proxying 的配置非常灵活。你可以针对某一个域名单独开启 HTTPS 解密也可以配置通配符这在业务复杂、域名繁多的项目里很实用。我一般会把*.example.com这类业务域名放进去然后让其他外部域名的流量保持原样减少证书解密的干扰。第二Map Local / Map Remote 功能做得非常顺手。右键一个请求可以直接 Save Response 存成文件然后通过 Map Local 映射回来再配合 Rewrite 功能就能实现比较完整的 Mock 流程。前端界面还没开发好的时候我用这套方案先给 App 喂数据完全不影响联调进度。第三Breakpoints 断点功能比较稳定。在请求发出前拦截、在响应返回前拦截都能直接修改报文内容再放行。这比改完代码重新跑一遍要快太多了。不过要注意断点开启后如果忘了关会导致接口像是卡死了一样实际上是被断点挂住了排障时容易吓自己一跳。Charles 的硬伤在于手机端抓 HTTPS 包需要安装并信任证书而且 Android 7.0 之后很多 App 默认不信任用户证书这时候要么用「安卓系统证书」方案需要 root 或刷机要么依赖 App 内部配置的调试包。这个问题是代理型工具的共性但 Charles 的文档对这部分写得不太直白新手很容易卡在证书安装了还是解密失败这一步。2.2 FiddlerWindows 平台的免费老将Fiddler 是老牌的 Windows 抓包神器。Fiddler Classic 版本完全免费功能也足够强大。因为我早期主要用 Windows 做开发Fiddler 是我接触最早的一款抓包工具印象最深的是它的 AutoResponder 和 FiddlerScript 脚本扩展能力。AutoResponder 可以理解为可视化的 Mock 规则。你可以把某些 URL 请求直接指向本地文件或者另一个 URL也可以自定义响应状态码和响应头。实际项目中我经常用它来模拟 404、500 这类异常响应测试前端对错误分支的处理是否全面。这点和 Charles 的 Map Local 异曲同工但 Fiddler 的规则匹配方式更直观一些还支持正则。FiddlerScript 是它区别于其他工具的大杀器。这个东西本质上是让用户用 C# 脚本去控制整个代理的行为你可以重写请求头、篡改响应体、自定义延迟、统计某个接口的耗时曲线。很多公司内部自研的弱网测试工具其实就是 FiddlerScript 的功能封装出来的。如果你愿意折腾脚本Fiddler 的扩展深度是目前几款工具里最高的。需要留意的是Fiddler 的默认界面比较陈旧第一次打开会看到一堆工具栏和监控面板新手容易觉得乱。而且 Fiddler Classic 的跨平台能力很弱在 macOS 上体验一般。同时它默认会修改系统代理设置如果卸载的时候没有正常还原就可能导致电脑上不了网。这个问题我在下面第4节会专门讲因为它太常见了。2.3 ProxymanmacOS 生态里的体验派Proxyman 是我近两年在 Mac 上切换频率较高的工具主要是因为它确实把抓包体验做得很现代。如果你经常在 macOS 和 iOS 模拟器上调试Proxyman 的流畅度会让你觉得 Charles 像是上一代产品。它的多 Tab 设计我很喜欢。一个 Tab 抓 API 请求另一个 Tab 看 WebSocket再开一个 Tab 抓 GraphQL互不干扰。相比 Charles 把所有请求堆在同一列里Proxyman 对复杂场景的管理更清爽。另一个亮点是它对 iOS 模拟器的支持很友好可以做到一键配置代理、自动信任证书省掉很多手动设置步骤。Proxyman 还内置了一些方便的小工具比如请求编辑重放、响应改写、限速模拟基本覆盖了 Charles 的常见功能。界面颜值高、交互顺畅对新手尤其友好配置证书的引导也做得很清楚不像 Charles 那样需要你自己去网上翻教程。不过 Proxyman 目前在国内的讨论度和团队普及率不如 Charles如果你习惯 Windows 或团队同事都在用 Charles那和同事对齐工具还是需要考虑的。2.4 Wireshark网络协议分析的显微镜前面说过Wireshark 是嗅探型工具和前面三款完全不是一个维度。它的强项在于全量抓包和协议分析。我举一个真实场景有一次线上反馈某个接口偶尔超时代理型工具只能看到请求发出后等了很久才返回但定位不了原因。这时候打开 Wireshark抓同一周期的流量立刻就能看到 TCP 重传次数明显偏高而且部分数据包到达顺序是乱的有的包还发生了重复 ACK。顺着这个线索最后定位到是某台负载均衡设备的 TCP 参数配置不当导致的。这种问题用 Charles 或 Fiddler 是根本看不到的。Wireshark 的过滤表达式是它最核心的技能之一。举几个常用的http // 只看HTTP请求 tcp.port 443 // 只看443端口 ip.addr 192.168.1.10 // 只看某个IP的流量 tls.handshake.type 1 // 过滤TLS ClientHello tcp.analysis.retransmission // 过滤TCP重传实际调试时我通常先用http || tls粗筛一轮再配合 Follow TCP Stream 查看完整的请求-响应内容。需要提醒的是Wireshark 抓包时默认会把当前机器的网卡设置为混杂模式在共享网络或者公司交换机下你可能会看到很多其他设备的广播包这时候过滤器的价值就体现出来了。另外Wireshark 默认并不自动解密 HTTPS需要你通过配置 TLS 密钥日志文件才能读取加密内容。这块操作略微有点门槛但用好了就是排障利器我下面会详细讲。2.5 TraceEagle国产轻量级工具的务实之选TraceEagle 可能相对小众很多人第一次听。它本质上也是一款代理型抓包工具走的路线是轻量、快捷、少配置。在实际使用中既不需要像 Wireshark 那样理解协议栈也没有 Fiddler 那么重的规则体系它更强调图形化操作和项目内共享数据。对国内团队来说TraceEagle 对中文环境比较友好界面和文档的门槛低处理 HTTPS 解密的手续也简化了很多。调试日常接口时它完全能满足查看请求、修改参数、模拟响应这些核心需求。如果你所在团队对工具选型没有强制要求只是希望新人能快速上手TraceEagle 可以作为一个降低沟通成本的选项。但也要客观地讲TraceEagle 在功能深度上确实不如 FiddlerScript 和 Charles 那么复杂社区资料和第三方教程也少遇到刁钻问题往往只能靠自己琢磨。我的建议是把它当作快速验证和入门教学的辅助工具真正做复杂调试和深度协议分析时还是得回到前面那几款专业工具上。3. 核心场景实战同一个需求五款工具怎么选工具选型不能只看参数关键要看具体场景。下面我按高频场景拆解一下方便你直接对号入座。3.1 HTTPS 解密抓包信任证书与密钥日志如果你要抓取的是 HTTPS 流量代理型工具和 Wireshark 的解密思路完全不同。代理型工具Charles、Fiddler、Proxyman、TraceEagle采用中间人的方式先安装代理工具自己生成的根证书然后代理在客户端和服务端之间分别建立 TLS 连接这样代理就能读到明文。操作上基本是三步走在电脑端安装并信任代理工具的根证书。在手机端或者浏览器端配置代理并下载、安装同一根证书。如果是手机端还要在系统的证书信任设置里主动信任这个证书iOS 往往比 Android 多一步。这一步最常见的坑是 iOS 上证书装了但提示未受信任。正确做法是安装描述文件后去「设置-通用-关于本机-证书信任设置」里把开关打开。这一步漏掉Charles/Proxyman 里的 HTTPS 请求会全部显示为乱码或者握手失败的密文。Wireshark 的解密思路不一样。它不是中间人不改变流量路径只是把浏览器或客户端生成的 TLS 会话密钥文件喂给 Wireshark让它逆向解密已经捕获的加密报文。具体配置路径是编辑 → 首选项 → Protocols → TLS → 在 (Pre)-Master-Secret log filename 里填入 SSLKEYLOGFILE 文件路径。要生成这个密钥日志文件可以在本机设置环境变量SSLKEYLOGFILE/path/to/sslkeylog.log配套使用 Firefox 或者 Chrome 时浏览器会自动把会话密钥写到这个文件里。之后在 Wireshark 里同时开着抓包和密钥文件就能看到 HTTPS 明文内容。这个功能对排查证书链异常、TLS 版本协商失败这类问题特别有效。3.2 手机 App 抓包同一网络、代理设置、证书信任三件套手机抓包是最多朋友问我的场景不管用 Charles、Proxyman 还是 Fiddler原理都是一样的。最常见的失败原因不外乎三个电脑和手机不在同一个局域网。手机代理的 IP 或端口填错。HTTPS 证书没有安装信任尤其是 iOS。先说第一项电脑和手机必须在同一个网段手机代理的 IP 填写的是电脑的局域网 IP而不是 127.0.0.1。端口方面Charles 默认 8888Fiddler 默认 8888Proxyman 默认 9090如果你改过端口手机上要同步修改。第二项代理设置完成后先在电脑端浏览器里随便访问一个 HTTP 网站确认代理能正常转发再去测手机这样可以降低排查难度。如果电脑端浏览器走代理没问题但手机端还是抓不到再回到证书和网络隔离的问题上。第三项Android 7.0 之后的问题比较麻烦。很多 App 在代码里设置了默认不信任用户证书就算你安装了用户证书App 发起的 HTTPS 请求仍然会失败。这时候可选的方案是在 App 的networkSecurityConfig里增加对用户证书的信任重新打包调试包。使用代理工具配合修改 App 代码在测试环境禁用证书校验。使用支持系统证书导入的设备通常是 root 后的设备。iOS 这边相对简单一点普通开发模式下安装描述文件并信任就能抓。但如果有 App 做了证书固定Certificate PinningCharles 和 Proxyman 也会失效基本上只能靠注入脚本或者 Hook 绕过作为日常调试手段要做好心理准备。3.3 弱网测试与 Mock 数据Charles、Fiddler、Proxyman 的正面交锋弱网测试是移动端开发绕不开的环节。Charles 的 Throttle Settings 可以直接模拟 3G、4G 网络也能自定义带宽、延迟、丢包率。Fiddler 自带 Simulate Modem Speeds 规则更精细的延迟可以通过 FiddlerScript 里的OnBeforeRequest加上一段延时来实现。Proxyman 的 Network Condition 面板做得更直观拖动滑块就能改网络参数。Mock 数据这块前面提到过 Charles 的 Map Local / Map Remote、Fiddler 的 AutoResponder、Proxyman 的 Map Local / Remote 大同小异。我分享一下日常工作中比较顺手的 Mock 流程先用抓包工具录制一条真实请求。右键保存 Response存为本地 JSON 文件。开启 Map Local / AutoResponder把请求 URL 映射到本地文件。修改本地 JSON 后刷新页面前端就能看到新的 Mock 数据。这个流程避免了反复让后端改数据也能模拟各种极端返回。但有个细节要注意映射成功后抓包工具的缓存可能会让你误以为还在请求服务器实际上流量已经指向本地文件了排查问题的时候记得先看请求的 Source 是 Remote 还是 Local。3.4 底层协议分析Wireshark 的专属主场如果你要做 TCP/UDP 层面的分析、Packet Loss 检测、VLAN 标签查看、TLS 握手细节那没得商量直接上 Wireshark。它不仅可以看单包结构还能用统计功能做传输耗时分析。我举个例子。当你想看一个 HTTPS 请求在 TCP 三次握手上花了多久可以设置过滤器tcp.port 443然后找到建立连接的第一个 SYN 包。Wireshark 的 Time 列会显示每个包的相对时间戳从 SYN 到 SYN-ACK 再到 ACK 的间隔基本就是一次连接的握手耗时。如果这个延迟明显偏高再往下看是不是有重传基本上问题就明朗了。再比如排查某些报文为什么显示不了完整内容其实很多情况下是 TCP 的分段重组问题。你在 Wireshark 里看到每个包最多 1514 字节左右以太网帧的限制如果应用层一次发了 2090 字节TCP 会按 MSS 把它切分成多个段Wireshark 默认会尝试重组只要你在 Preferences 里开启 TCP 的 Allow sub dissector to reassemble TCP streams 就好。关于这个我在第4节会专门展开讲。4. 真实踩坑与问题排查记录4.1 抓不到包的通用排查顺序不管是你第一次用 Charles 抓手机包还是 Fiddler 突然失灵按照下面这套顺序排查能解决九成问题确认电脑和手机/设备在同一局域网。确认代理 IP 是电脑的局域网 IP不是localhost。确认代理端口没被其他进程占用也没有被防火墙拦截。关闭手机上的其他的代理或加速类 App避免数据被二次转发。在电脑浏览器里先验证代理抓包是否正常再跳到手机端。HTTPS 请求解密失败的话检查证书是否安装、是否信任。如果以上都正常但有些 App 请求还是抓不到考虑是不是做了证书固定。我在实际工作中发现有相当一部分抓不到包的案例最后都卡在代理端口或网络环境问题上。比如某些企业办公网络开启了 AP 隔离手机和电脑虽然连着同一个 WiFi但彼此之间根本不通这时候代理自然就无效了。这种情况下可以尝试用手机开热点让电脑连手机热点重新组网来调试。4.2 Wireshark 为什么只显示 520 字节怎么看到 2090 字节这个问题被搜索得非常多说明很多人第一次用 Wireshark 都会遇到同样的困惑。我先说结论Wireshark 并不会只显示 520 字节所谓只显示 520 字节通常指向两个层面的原因。第一种情况你看到的单个数据包本来就只有 520 字节。以太网的 MTU 通常是 1500 字节扣掉 IP 头 20 字节和 TCP 头 20 字节MSS 一般是 1460 字节但实际应用层发送的数据量不一定能填满 MSS。如果发送方一次只写了 500 字节数据TCP 段总长度就大约是 500 20(TCP) 20(IP) 540 字节加上以太网头 14 字节和帧校验 4 字节就接近 560 字节。520 字节出现要么是应用层发送量小要么是某些控制报文只有几十字节。这并不代表 Wireshark 抓包不全。第二种情况更常见你抓到了一个大的应用层数据但 Wireshark 没进行重组只看到一个个分段。当应用层一次要发送 2090 字节的数据TCP 会把它拆成两个或更多个段。Wireshark 默认会根据配置对 TCP 流进行重组但重组的开关有时候会被误关。你可以在「编辑-首选项-Protocols-TCP」里确认以下选项是开启的Allow subdissector to reassemble TCP streamsReassemble out-of-order segments开启之后Wireshark 会在报文列表里显示TCP segment of a reassembled PDU并通过 Follow TCP Stream 把完整的数据还原出来。你看到的 2090 字节就不再是分散的多个包而是合并后的整体了。如果你关心的只是某列显示的数据大小还可以在列头自定义一个frame.len列这样每个包的总长度一目了然不用靠眼睛去数十六进制内容。顺便提一句有些网卡开启了巨型帧Jumbo Frame单包能承载 9000 字节以上不过那是在特定网络环境里才有的情况日常看 1500 左右才是正常现象。4.3 卸载 Fiddler 后上不了网这个问题很经典很多朋友卸载 Fiddler 之后发现浏览器打不开网页了其实就是 Fiddler 卸载时没有把系统代理设置还原。Fiddler 在运行期间会把系统代理指向 127.0.0.1:8888正常退出的时候会还原但如果强杀进程、崩溃退出或者卸载流程不正常代理就会一直残留。解决办法很简单。按 Win R 打开运行输入inetcpl.cpl回车打开 Internet 选项在「连接」选项卡里点「局域网设置」取消勾选为 LAN 使用代理服务器确定保存。如果是命令行环境也可以用netsh winhttp reset proxy把 WinHTTP 代理清掉。再不行就检查一下环境变量里有没有 HTTP_PROXY 或 HTTPS_PROXY有些软件会写这个变量也会导致请求全部走到无效代理上。这类问题排查思路就是先把所有层级的代理设置恢复默认再逐步确认。4.4 证书相关的疑难杂症代理型抓包工具用久了多多少少都会遇到证书问题。我把常见的几个整理了一下现象常见原因处理方式手机装了证书但 HTTPS 显示错误iOS 没在证书信任设置里手动信任到「设置-通用-关于本机-证书信任设置」打开开关Android 装了证书但 App 请求失败Android 7.0 默认不信任用户证书修改 networkSecurityConfig 或使用系统证书方案电脑浏览器提示证书无效证书链不完整或过期重新导入根证书并确认始终信任抓包工具导出证书后手机无法安装描述文件文件类型或日期格式问题用代理工具自带的导出按钮不要手动改后缀某个域名 HTTPS 解密失败其他域名正常SSL Proxying 没勾选该域名在 SSL Proxying 设置里添加该域名有个容易被忽略的点Charles 和 Fiddler 这类工具的根证书一般默认有效期为几年甚至十年但实际用起来还是会遇到证书过期的问题。尤其 Charles很多人安装后一直不更新某天突然发现所有 HTTPS 请求都失败了一查发现是根证书过期。这时候去工具里重装一次证书并把系统里的旧证书删掉就能恢复正常。5. 选型落地建议别再纠结哪个最好5.1 按岗位职责选型如果你是前端开发、移动端开发、测试工程师日常工作就是调接口、看请求参数、做 Mock、模拟弱网那《Charles Fiddler / Proxyman TraceEagle》这一类代理型工具足够用了。不同平台的推荐组合可以这样排macOS iOS 生态优先选 Proxyman其次是 Charles。Proxyman 体验更现代Charles 兼容性和社区资料更成熟。Windows 生态优先选 Fiddler它的系统集成和脚本能力无可替代如果团队统一用 Charles那 Charles 跨平台也可以。对中文文档和低上手成本有要求TraceEagle 值得一试作为团队辅助工具没问题。如果你负责网络运维、后端性能排查、系统排障、或者是做协议方向的技术研究Wireshark 是必须掌握的核心工具。它给你的不是接口长什么样而是网络本身发生了什么。这类工作里代理型工具再花哨也只是辅助手段。5.2 按目标协议选型抓 HTTP/HTTPSCharles、Fiddler、Proxyman、TraceEagle 都行。看平台偏好看团队习惯。抓 WebSocket、GraphQLProxyman 体验不错Charles 也支持Fiddler 需要额外配置脚本。抓 TCP/UDP、DNS、TLS、QUIC 基础细节只有 Wireshark 合适。抓本地回环流量LoopbackWireshark 在 Windows 上需要安装 Npcap 并注意回环抓包的限制Fiddler 在代理层面就能看到 localhostCharles 也可以。5.3 组合拳打法两台工具互补使用最后分享一套我自己的组合打法也是我认为最省心的工作流。日常接口调试我用 Charles 或 Proxyman 解决因为它们抓包、Mock、弱网一条龙效率很高。遇到线上问题排查我会开 Wireshark 全量抓包再配合代理型工具做业务请求的定位一边看业务语义一边看协议细节。TraceEagle 更多是在团队新同事入门培训时用它简单直观最快让对方建立抓包的概念等到上手之后再切到更高级的工具。一个具体的排障过程可以这样描述先用 Wireshark 抓了 30 秒流量发现某个请求存在大量 TCP 快速重传然后切换到 Charles 看这个接口是否触发了重试逻辑最后定位到是客户端在重传超时后发起了二次请求导致重复提交。如果只依赖任何一款单一工具这个问题的定位就会很绕。跨工具对照查看数据往往是最快的路径。根据我个人的实际体验抓包工具这件事真的不是越多越好也不是越贵越好。把一款代理型工具用熟再来学 Wireshark 的过滤和重组就已经能覆盖绝大多数开发调试场景。那些花哨的脚本和扩展等你真正遇到重复性高、手工处理效率低的场景时再回过头来研究学习动力会强很多。希望这篇对比能帮你少踩几个坑快速找到顺手的那款工具。