
1. 先说结论别指望一款工具吃遍所有场景抓包这件事很多人一上来就纠结“哪个工具最好用”结果在工具选择上花的时间比真正排查问题的时间还多。我的建议很直接先确认你要抓什么再挑工具。Charles、TraceEagle、Wireshark、Fiddler、Proxyman 这五款本质上对应的是完全不同的使用场景硬要放在一起比谁更强没有太大意义。我个人的划分标准很简单如果你主要调 App 的 HTTP/HTTPS 接口、看请求响应、Mock 数据Charles 或 Proxyman 是首选如果你在 Windows 上做接口调试、弱网测试Fiddler 是绕过不去的经典选择如果你要看 TCP 层、UDP 流量、协议交互过程、甚至排查“数据到底有没有到达网卡”Wireshark 才是真正的主力至于 TraceEagle这类偏向调用链追踪和轻量化抓包的新兴工具适合快速梳理 API 依赖关系但还没有到替代前三者的程度。后面我会把这五款工具的核心用法、常见坑、以及我实际踩过的雷全部摊开讲尽量让不同基础的读者都能找到自己能用的部分。2. 五款工具的定位差异先选对赛道再谈对比2.1 一张表看懂适用场景先给一个比较直观的对照表后面再逐个拆细节工具核心领域是否支持 HTTPS 解密移动端抓包协议深度上手难度平台CharlesHTTP/HTTPS 调试代理支持需安装并信任 CA 证书支持配置代理和证书即可HTTP 层为主能看到 TCP/SSL 握手摘要中Windows/macOS/LinuxFiddlerHTTP/HTTPS 调试代理支持需信任根证书支持需手机设置代理HTTP 层为主附带性能分析中Windows主要、macOSProxymanHTTP/HTTPS 调试代理支持内置 CA 管理支持对 iOS 设备非常友好HTTP/2、WebSocket、TCP 能看中低macOSWireshark网络协议分析支持需导出 TLS 会话密钥间接支持需在终端做 TAP/远程抓包全协议栈从二层到七层都能看高Windows/macOS/LinuxTraceEagleAPI 调用链追踪与轻量抓包支持视具体产品形态而定偏向 API 层、调用链分析低以桌面端产品为主这张表的核心含义是Charles 和 Fiddler 是“调接口”的工具Wireshark 是“查网络”的工具。很多人拿 Wireshark 去找接口参数结果被一堆 TCP 包淹没体验非常痛苦反过来拿 Charles 去看 TCP 重传、确认包、VLAN 标签也完全看不到。工具一旦选错赛道再熟练也是白搭。2.2 为什么不能只看功能数量我见过不少新人一看到某款工具“功能多”就认定它更好。实际上抓包工具的体验差距体现在细节里而不是功能列表里。举一个最常见的例子Charles 的手机抓包体验核心在于它帮你处理了证书安装和代理转发的完整链路。你只需要把手机代理指向电脑的 8888 端口然后访问一个下载页安装证书再在系统设置里信任证书剩下的就是正常看请求。这个过程虽然也有坑但整体引导很成熟。Fiddler 在 Windows 上同样有 iOS/Android 代理配置方案但证书安装的路径藏在设置里第一次操作的人很容易卡在“安装完证书但全是 CONNECT 隧道”那一步。再说 Wireshark它的功能列表很长但你需要自己理解“捕获过滤器”和“显示过滤器”的区别捕获过滤器是在抓包开始前过滤比如只看某个 IP 的数据显示过滤器是在抓包结束后过滤比如只显示 HTTP 协议。这两个概念刚开始容易混但实际用下来日常 90% 的需求只需要掌握几个显示过滤表达式就够了不需要把每项功能都研究透。所以我的建议是选工具先看你的主场景再看工具的默认操控流程是否顺手最后才看那些锦上添花的功能。3. Charles移动端调试绕不开的主流选择3.1 证书信任与手机抓包Charles 最常被人问的就是“明明代理设置了为什么手机还是抓不到包”。这里面的坑90% 出在证书信任上。先梳理一遍标准的手机抓包流程电脑上打开 Charles在 Proxy Settings 里确认 HTTP Proxy 开启了 8888 端口手机连到和电脑同一局域网把 WiFi 代理设为“手动”填电脑的局域网 IP 和 8888 端口手机浏览器访问chls.pro/ssl下载并安装 Charles CA 证书关键一步iOS 设备需要到“设置 - 通用 - 关于本机 - 证书信任设置”里把 Charles Proxy CA 这个开关打开Android 设备则在“安全 - 加密与凭据 - 信任的凭据”里确认用户证书已生效回到 Charles会弹出一个提示框询问是否允许该设备连接点 Allow。很多人到了第 4 步就断了尤其是在 iOS 上安装完证书以后不去“证书信任设置”里打开信任开关Charles 会出现你看到的一堆失败证书内容显示“You may need to configure your browser or application to trust the Charles Root Certificate”。这个提示翻译成人话就是证书装了但你的手机不认所以连接没法解密。还有一类情况手机设置了代理后浏览器能打开网页但 App 里全部请求超时。这个大概率是 App 本身做了网络安全配置或证书校验不允许用户级证书。在 Android 7.0 及以上系统默认不信任用户证书部分 App 会用networkSecurityConfig限制信任范围这种情况下要么连 Charles 自己也会提示“SSL handshake failed”要么只能对抓包客户端的证书做更进一步的系统级处理。如果你的测试手机有条件可以先把证书装进系统证书目录再试。3.2 Mock 数据的三种玩法Charles 的价值不只是“看包”它的 Mock 能力在前后端联调时非常方便。我平时用得最多的是这三种方式第一种Map Local 本地映射。右键一个请求选择 Save Response把响应保存成一个 JSON 或文件之后用 Tools - Map Local 把线上地址映射到本地文件。这样前端在接口还没开发完成时直接返回本地假数据开发页面完全不依赖后端环境。第二种Repeat 与 Repeat Advanced。右键请求后点 Repeat是单次重放点 Repeat Advanced可以设置并发次数和间隔时间。后端接口不稳定时我用它做简单的并发验证不必写脚本就能模拟几次并发请求。第三种Breakpoints 断点。在 Proxy - Breakpoints 里添加规则请求到达 Charles 时会暂停你可以在 Request 面板里临时改 URL、Header 或 JSON Body再点 Execute 放行。响应同样可以改比如故意把 status code 改成 500看前端有没有处理异常分支。这三种方式覆盖了我日常 70% 以上的 Mock 需求。注意一点Map Local 和 Rewrite 这类改动对团队协作不太友好因为它依赖当前电脑的 Charles 配置别人那边不会自动同步。如果 Mock 规则需要长期共享建议还是用独立的 Mock 服务。3.3 高频翻车现场关于 Charles 的“翻车”经验我攒了不少抓不到浏览器请求先检查电脑是否开了系统代理。Charles 在第一次启动时通常会问你“是否配置系统代理”如果当时选了 No浏览器流量不会走 Charles。Windows 用户还要额外注意系统代理是否被 WinINET 缓存的旧配置干扰可以在 Internet 选项里看“局域网设置”。抓不到 App 请求但浏览器正常一般是 App 不走系统代理比如部分直播、上传类应用使用底层 Socket 直连也有的是因为配置了自定义 DNS。这种情况 Charles 无能为力你需要转用 Wireshark 从网卡层抓包。证书过期或提示连接非私密Charles 的根证书有过期时间老版本尤其明显。解决方案是删掉旧证书重新在本地生成一个新 CA再让你的手机重新安装信任。具体路径是 Help - SSL Proxying - Reset Charles Root Certificate。实操心得Charles 显示的是 HTTP 层的请求连接层面的 TCP 三次握手、TLS 细节都是被隐藏起来的。如果你排查的问题涉及“连接被重置”“握手失败”只看 Charles 的 Error 信息往往不够建议把问题分成两层应用层错误看 Charles连接层错误直接换 Wireshark。4. Wireshark从协议层看问题才是降维打击4.1 安装与抓包基础Wireshark 的安装本身没什么可说的官网下对应系统的安装包一路 Next 就行。但很多人装完之后卡在第一步打开软件一列网卡列表不知道选哪一个。我的建议是记住一个原则看“数据包数量”那一列哪个网卡在跳数字就说明哪个网卡正在收发流量。如果你要抓本机访问外网的包就选连接路由器的那个物理网卡或 Wi-Fi 网卡如果要看本机进程之间通信选 Loopback 回环网卡。抓包开始之后第一步看到的通常是满屏的 TCP 包。别慌靠显示过滤器控制流量。我最常用的是这么几个ip.addr 192.168.1.100 tcp.port 443 http dns tls.handshake.type 1ip.addr是过滤某个 IP 的所有进出流量tcp.port过滤某个端口http直接只看 HTTP 明文流量dns看解析请求tls.handshake.type 1专门看 TLS 的 ClientHello。这几个组合使用已经能应付绝大多数日常场景。4.2 解决“只显示520字节”的疑惑有网友问“为什么我的 Wireshark 只显示 520 字节数据怎么显示 2090 个字节”。这个问题其实要拆成两种情况看。第一种情况数据包确实被拆成了多个分段。一个 HTTP 响应如果有 2090 字节应用数据TCP 层会按 MSS最大分段大小拆包以太网环境下通常是 1460 字节一段。所以你会看到多个长度不同的 TCP 包比如 1460、540、还有约几十字节的最后一个尾巴520 字节只是其中一个分段而已。这时候如果只想看完整内容右键任一相关包选择“Follow TCP Stream”Wireshark 会把所有分段重组完显示完整的 2090 字节数据流。第二种情况抓包时被截断了。Wireshark 的捕获选项里有一个“Limit each packet to N bytes”的配置默认可能是 262144 字节一般不会截断。但如果有人在Edit - Preferences - Capture - Default capture options里改过或者用了-s 64之类的命令抓包每个包只会保存前 64 字节剩下的被丢弃。判断方法很简单看摘要栏里某个包的 Length 是不是 64、520 这种边缘值再对比原始抓包文件的大小。如果确认被截断只能重新抓包已经抓到的数据补不回来但可以用来分析 TCP 头的控制字段。另外还有一个细节Wireshark 摘要栏里显示的 Length 是包含以太网头 14 字节的帧长度不包含 4 字节 FCS。如果你按应用层 2090 字节去对包长度大概率对不上。记得按协议层来看Frame Length - Ethernet Header - IP Header - TCP Header TCP Payload。比如一个 Length 为 1460 的包去掉以太网头 14 字节、IP 头 20 字节、TCP 头 20 字节剩余刚好 1406 字节应用数据加上下一段数据就拼出完整内容了。理解这个换算关系再遇到“数字对不上”的问题就不会慌。4.3 VLAN 与时间间隔筛选VLAN 过滤是做网络运维或交换机测试时经常用到的功能。Wireshark 里过滤 VLAN 包的方法是vlan vlan.id 100 vlan.id 100 ip.addr 192.168.10.2这里注意普通家庭网络里通常没有 VLAN 标签抓不到是正常的。需要有交换机或虚拟化环境给报文打上 802.1Q 标签Wireshark 才能解析并显示 vlan.id。如果你是在本机做虚拟机流量分析网卡上可能也会出现 VLAN ID要看虚拟交换机是否启用了 VLAN 模块。UDP 前后两包的时间间隔筛选这个问题我说实话在 Wireshark 里做不到像ip.addr x.x.x.x那样直接输入一个过滤表达式去筛“间隔超过多少毫秒”的包。Wireshark 的显示过滤器不支持这种基于包间时间差的条件过滤。实际做法是添加时间增量列在包列表的表头右键选择 Column Preferences新增一列字段名写frame.time_delta抓包停止后点击这一列的标题排序就能看到每两个相邻包之间的时间差较明显的间隔一眼就能看出来如果数据量特别大需要把所有包的时间间隔导出分析用 tshark 命令更高效tshark -r capture.pcap -T fields -e frame.number -e ip.src -e ip.dst -e frame.time_delta把输出结果丢到 Excel 或脚本里排序就能找出间隔异常的包。这个思路比在 Wireshark 界面里手工翻高效得多。4.4 TLS 解密配置Wireshark 解密 HTTPS 流量核心原理是提供 TLS 会话密钥让 Wireshark 能够解开加密内容。最方便的做法是设置环境变量把浏览器导出的会话密钥写到文件里再在Edit - Preferences - Protocols - TLS里配置 (Pre)-Master-Secret log filename。具体步骤新建一个空文本文件比如C:\sslkey\log.key在系统的环境变量里新增一个变量名SSLKEYLOGFILE值填这个文件路径重启浏览器打开需要调试的 HTTPS 网站让浏览器往这个文件里写入浏览器和服务器协商的会话密钥回到 Wireshark在 TLS 协议设置里把同一个文件路径填进去重新抓包或打开已有 pcap 文件。有人问“为什么我配置了还是解不开”。一个常见原因是浏览器版本或系统环境不读这个环境变量。Firefox 对SSLKEYLOGFILE支持比较好Chrome 系在 Windows/Linux 上也支持但 macOS 上部分版本存在限制。碰到这种情况换个浏览器试是最快的。还有一个原因是主密钥生成时机有些协议变体用的是 TLS 1.3密钥导出方式稍复杂Wireshark 版本太老可能不支持解密。建议保持 Wireshark 版本在 3.6 以上对 TLS 1.3 的支持明显更好。5. FiddlerWindows 生态里的老牌选手5.1 安装、汉化与系统代理Fiddler 现在的版本分两类Fiddler Classic 是免费的经典版界面停留在 .NET Framework 时代Fiddler Everywhere 是跨平台付费版界面现代化。除非你公司购买了 Everywhere 授权否则我建议从 Fiddler Classic 用起日常调试功能完全够用。安装完 Fiddler Classic 后我第一次打开总觉得界面有点陈旧很多人想汉化。网上有不少汉化包但我实际经验是汉化包版本和 Fiddler 版本不同步时很容易导致界面挂掉或功能按钮缺失。如果你只是不想看英文我建议先去菜单 Tools-Options-HTTPS 里把各项点一遍把这几个核心菜单的英文混熟了比折腾汉化包划算。真要汉化注意下载和你的 Fiddler 版本完全对应的汉化包替换前先备份原文件。Fiddler 启动时会默认把系统代理设置为 127.0.0.1:8888这也是它抓本机请求的原理。但你把它关掉之后如果没有恢复系统代理就会出现一个很经典的问题——卸载后上不了网。5.2 弱网测试参数Fiddler 做弱网测试是老传统。菜单路径是Rules - Performance - Simulate Modems Speed开启后能模拟拨号上网一样的高延迟低带宽。但这个内置方案太过粗暴只适合演示场景。更精细的做法是用Customize Rules打开 FiddlerScript在OnBeforeRequest里添加延迟逻辑if (m_SimulateModem) { oSession[request-trickle-delay] 300; oSession[response-trickle-delay] 150; }request-trickle-delay是每个请求数据块之间的延迟毫秒数response-trickle-delay是每个响应数据块之间的延迟。调整这两个值你可以模拟上传慢、下载快或者反过来。配合 Charles 的 Throttle 设置做弱网测试时思路是一样的都是控制上行/下行的带宽和延迟。不过要注意模拟弱网和真实弱网还是有差距的。模拟器只压缩带宽和延迟不会模拟真实的丢包、信号抖动、DNS 超时等行为。如果你要测的是一个对网络切换很敏感的 App建议还是用真实弱网环境或者专门的服务端限速方案。5.3 卸载后上不了网的修复Fiddler 卸载后上不了网这个坑我踩过也给很多同事远程修过。原因其实很简单Fiddler 运行时会修改系统的 WinINET 代理设置如果非正常退出或者卸载程序没有清理掉这些配置系统就会继续尝试通过 127.0.0.1:8888 访问网络但 Fiddler 已经没了端口上没东西监听网络自然就断了。修复方法有两种打开“Internet 选项 - 连接 - 局域网设置”取消了“为 LAN 使用代理服务器”的勾选或者把地址栏里的“127.0.0.1:8888”清空更彻底的方式是用netsh重置 WinHTTP 代理设置netsh winhttp reset proxy重置后最好重启一下浏览器或其他依赖网络的程序。这段时间如果你正在做测试不至于因为卸载了 Fiddler 就断了整个日常网络。经验是Fiddler 里关闭程序时尽量用File - Exit而不是直接点 X。直接关窗口时它有时候来不及清理代理设置系统代理残留的概率会大不少。6. Proxyman 与 TraceEagle新一代工具补齐了什么6.1 Proxyman 在 iOS 调试上的体验Proxyman 是 macOS 平台上的抓包工具对 iPhone 调试做了一些针对性的优化这是我实际用下来比较喜欢它的原因。首先它的 CA 证书管理比 Charles 更人性化。启动 Proxyman 后在Certificate菜单里可以一键生成并安装根证书iOS 设备需要访问proxyman.io/ssl下载证书然后到系统设置信任。整个流程很清楚不像 Fiddler 那样把证书选项藏在多级菜单里。其次它对 HTTP/2 和 WebSocket 的支持更直观。Proxyman 会直接把 WebSocket 的帧逐条列出来能看到 text frame、ping、pong 的收发顺序用于调实时消息类接口体验很好。Charles 对 WebSocket 的处理相对简单适合看连接层不适合逐帧排查。另一个亮点是它的“Scripting”功能可以给请求写脚本做自动化处理。比如给所有 API 请求自动加一个 Header或者把响应里的某个字段统一替换成 mock 值不用像之前那样傻傻地在每个请求上右键手动操作。和 Charles 对比Proxyman 的脚本钩子更贴近工程师的使用习惯。不过 Proxyman 的硬伤是平台绑定在 macOS 上Windows/Linux 用户用不了。团队协作时如果其他同事是 Windows 机器工具不互通就成了选型障碍。6.2 TraceEagle 的轻量化思路TraceEagle 是一个相对新的工具关注度还没有前三者高但它的定位和传统抓包工具有明显差异重点不是把所有请求列出来而是把一次用户操作背后涉及的多个 API 调用串成一条调用链让开发人员快速看到接口之间的依赖关系。这种思路在排查分布式系统或前后端联调问题时非常有用。比如你点击 App 里的某个按钮实际会触发登录鉴权、订单查询、库存扣减等好几个请求传统抓包工具把所有请求平铺在一个列表里你得靠时间戳和参数去猜谁先谁后。TraceEagle 用调用链视图把这些请求组织成一棵树打开就能看到入口请求调了哪些下游接口、耗时多少、哪个环节出错。如果你所在的项目是微服务架构或者前端调试时需要经常向后端确认接口依赖TraceEagle 这类轻量工具可以作为一个补充视角。它目前的应用范围还在扩展单独成为主力抓包工具还早但作为日常“看链路”的助手挺好用。7. 常见问题速查表下面这些是我在社区、同事、以及自己项目里经常遇到的典型问题整理成速查表问题出现原因快速解决Charles 抓不到手机 App 请求证书未信任或 Android 7.0 不认用户证书检查代理 IP/端口iOS 打开“证书信任设置”Android 将证书装进系统证书目录安装证书后提示“You may need to configure”证书未被系统完全信任Mac/Windows 钥匙串里把证书设为“始终信任”iOS 在“关于本机”里打开开关Fiddler 卸载后上不了网系统代理残留指向 127.0.0.1:8888Internet 选项里取消代理或执行netsh winhttp reset proxyWireshark 抓包全是 TCP 包找不到 HTTP走了 HTTPS 加密流量Wireshark 里叫 TLS配置 TLS 会话密钥日志文件过滤tls或httpWireshark 看到 Length 只有 520/1400TCP 分段或 snaplen 截断Follow TCP Stream 看重组的完整数据确认没有启用包截断搜索 UDP 相邻包时间间隔Wireshark 显示过滤器不支持帧间隔查询添加frame.time_delta列并排序或导出 CSV 用脚本分析手机设置代理后 App 超时App 忽略系统代理或做了证书校验临时改用测试包/关闭证书校验或使用 Wireshark 抓网卡流量端口 8888 被占用启动失败其他程序占用了 Charles/Fiddler 默认端口换端口Charles 在 Proxy Settings 调整Fiddler 在 Tools-Options-Connections 调整再补充一个细节任何代理型抓包工具Charles、Fiddler、Proxyman抓到的“客户端 - 服务器”流量本质上都是经过了它再转发所以它本身就是一个中间人。企业级、金融类应用的签名校验或双向证书校验会直接拒绝这类代理的请求这属于正常现象不代表工具坏了。碰到这种情况只能回到应用日志或使用服务端侧的接入层日志排查。8. 一些选型建议写到最后分享一些我在实际项目里的体会。如果你是个前端或移动端开发日常主要调 HTTP 接口我建议优先熟悉 Charles因为它在移动端场景的引导和 Mock 能力最成熟。就算换了公司Charles 的部署方式基本是通用的。如果你长期在 Windows 上工作Fiddler 可以当作主力但注意维护好系统代理设置。如果你是一个网络工程师、后端开发或者做协议分析Wireshark 必须掌握。它不只能抓包还能分析 TCP 重传、确认、乱序、延迟分布这些是 Charles 和 Fiddler 完全给不了的信息。刚开始不用怕先把ip.addr、tcp.port、dns这几个过滤器练熟再慢慢看 TLS 解密和统计工具。Proxyman 适合使用 macOS 且比较在意调试效率、喜欢用脚本自动化的开发者尤其适合 iOS 原生项目里频繁看 WebSocket 和 HTTP/2 的场景。TraceEagle 可以关注着但不必作为主工具投入过多时间它对调用链的梳理能力在微服务调试中能起到补充作用未来值得期待。还有一个小技巧工具之间不是非此即彼的。排查一个复杂问题时我经常是 Charles 和 Wireshark 同时开着Charles 看接口层参数Wireshark 看连接层状态。接口调用失败先在 Charles 里确认请求是否发出、响应是否返回如果 Charles 层面一切正常但业务仍异常再打开 Wireshark 抓原始报文看 TCP 重传、RST 包、证书协商失败这类底层信号。这样两条线对照定位问题的速度会快很多。