搞开发这些年抓包工具我换了好几轮。Charles、Fiddler、Wireshark、Proxyman再加上最近不少人问的TraceEagle每一款我都实际用过一段时间也踩过不少坑。这篇文章就围绕抓包工具的选型和使用来展开先讲清楚每款工具的定位差异再把手机抓包、HTTPS解密、弱网模拟、报文过滤这些高频操作的关键细节一起拆开讲。如果你正准备挑一款抓包工具或者已经在用但总遇到“抓不到包”“证书不生效”“数据解不开”这类问题这篇文章应该能帮你省下不少排查时间。1. 五款工具的定位差异先想清楚你要解决什么问题很多新手上来就问“哪个抓包工具最好”这个问题本身就没法回答。抓包工具不是一个完全同质化的品类它们工作的层级不同、适用的场景不同、解决的核心痛点也不同。选错了工具后面再努力都是事倍功半。1.1 一张表看懂核心区别我先把五款工具的核心定位、适用场景、平台支持和上手难度放在一起做个对照方便你快速锁定目标。工具核心定位最常用场景支持平台上手难度CharlesHTTP/HTTPS 调试代理移动端 App 接口调试、Mock 数据、弱网模拟Windows / macOS / Linux低ProxymanHTTP/HTTPS 调试代理macOS 和 iOS 生态调试、接口快速查看macOS含 iOS 模拟器低FiddlerHTTP/HTTPS 调试代理Windows 平台 Web 与客户端调试、弱网测试Windows / .NET中Wireshark网络协议分析底层协议排查、TCP/UDP 分析、报文追溯全平台高TraceEagle新一代 HTTP 调试平台跨平台接口调试、团队协作、接口文档沉淀全平台中低1.2 别急着安装先对号入座如果你主要调试的是移动端 App 的接口Charles 和 Proxyman 会是更顺手的工具。它们把请求、响应、Header、Cookie、请求耗时这些信息组织得非常直观而且可以一键过滤某个域名、一键模拟弱网做前后端联调非常省心。如果你工作在 Windows 环境下或者需要频繁用脚本批量修改请求、做自动化式的抓包验证那 Fiddler 的 FiddlerScript 机制会让你感觉如虎添翼。它和 Windows 生态的契合度很高很多早期的.net 客户端调试案例都是围绕 Fiddler 展开的。如果你遇到的问题已经超出 HTTP 层比如 TCP 重传、丢包、延迟抖动、DNS 解析异常、某个端口上到底有哪些连接那就得用 Wireshark 了。它抓的是经过网卡的全部数据包能看到传输层、网络层甚至链路层的信息是底层网络排障的最终手段。至于 TraceEagle它属于这个领域的新面孔。从它目前暴露出来的产品理念看更像是想把 Charles 的易用性和团队协作、接口管理能力结合起来。如果你所在团队经常多人联调、希望把抓包记录沉淀成文档它值得关注但还没到能完全替代老牌工具的程度。还有一点需要说清楚Charles、Fiddler、Proxyman 这类工具本质上是一个本地代理服务器手机或浏览器把请求指向你电脑上这个代理工具才能解析和展示数据。而 Wireshark 不是代理模式它直接监听网卡上的网络流量。理解了这两类原理你就知道为什么有时候用代理工具抓不到包换 Wireshark 却能抓到——因为一个是依赖应用主动走代理一个是网卡层全量捕获。2. 日常开发场景下的主力工具Charles 与 Proxyman 实战拆解日常开发里Charles 和 Proxyman 是我用得最多的两个工具因为它们把 HTTP 调试体验做得足够细。下面我把手机抓包的完整链路、HTTPS 解密的关键配置、Mock 和弱网的常用玩法分别讲透。2.1 手机抓包的完整链路代理、证书、过滤一个都不能少“为什么手机连上代理还是抓不到包”是我见过最多的新手问题。其实手机抓包是一个非常标准的三步走少了任何一步都不行。第一步是确保手机和电脑在同一局域网。这个听起来是废话但真有人把手机连了 4G、电脑连 WiFi然后折腾一下午抓不到包。第二步是在手机 WiFi 设置里配置手动代理把代理地址填成电脑的局域网 IP端口填成抓包工具的代理端口。Charles 默认是 8888Proxyman 通常在 9090 左右Fiddler 默认也是 8888。电脑 IP 可以直接在抓包工具界面里看到Charles 的 Help - Local IP Address 就能看到当前局域网 IP。第三步是安装并信任根证书。HTTP 协议下代理工具可以明文解析但 HTTPS 流量是加密的工具必须用自己生成的根证书对流量做中间人解密。以 Charles 为例手机浏览器访问chls.pro/ssl下载证书下载后到系统设置里安装。iOS 用户注意只点“安装”还不够还需要到“设置 - 通用 - 关于本机 - 证书信任设置”里把 Charles 的证书开关打开否则 Safari 和部分 App 依然会报证书错误。做完这三步还要检查抓包工具本身的过滤设置。Charles 左下角有一个 Filter 输入框如果你之前填了某个 host那其他域名的请求都会被过滤掉。我遇到过好几次“抓不到包”最后发现是过滤条件没清掉。2.2 HTTPS 解密的关键为什么装了证书还是乱码很多新手装完证书发现 Charles 里看到的还是 CONNECT 开头的内容或者响应体是一堆乱码这大概率是 SSL Proxying 没有开启。默认情况下Charles 对 HTTPS 流量只会显示 CONNECT 隧道信息不会解密具体内容。你需要到 Proxy - SSL Proxying Settings 里勾选 Enable SSL Proxying然后在 Location 里添加要解密的域名。直接填*代表解密所有域名开发环境为了省事可以这样填但如果遇到证书校验很严格的情况抓包工具会伪造不出有效证书反而引发更多问题。建议还是按域名添加比如api.example.com:443。再说一个比较隐蔽的坑Android 7.0 之后系统默认不再信任用户安装的证书只信任系统证书。也就是说即使你在 Android 手机上装了 Charles 的证书普通 App 发起的 HTTPS 请求依然会把你这个代理视为不可信直接握手失败。解决思路有三个一是让开发在调试包里配置networkSecurityConfig信任用户证书二是 Root 手机把证书装进系统证书目录三是如果只是看网页流量用 Chrome 这类浏览器访问一般没问题因为浏览器对用户证书是放行的。这个问题在 iOS 上相对好办只要证书信任开关打开大部分 App 都能正常抓。2.3 Mock 数据和弱网模拟前后端联调的两把利器Charles 里 Map Local 和 Map Remote 这两个功能简直是前后端联调的救命稻草。后端接口还没写完时前端可以先用 Map Local 把某个接口的响应映射到一个本地 JSON 文件让请求直接返回本地定好的数据。操作路径是 Tools - Map Local勾选 Enable Map LocalAdd 一条规则指定协议、host、path 和本地文件路径。这样前端不用等后端接口自己就能把页面流程跑通。Map Remote 则是把请求重定向到另一个环境比如线上请求打到测试环境或者灰度环境请求打到本地服务调试一些环境差异问题非常方便。弱网模拟也很常用。Charles 的 Proxy - Throttle Settings 里有预设的网速档位也能自定义带宽、延迟、丢包率。想模拟用户在地铁里的体验可以设置一个较小的带宽加 300ms 延迟看看页面加载和接口超时表现。Proxyman 在这几个方面做得也很接近而且它的 UI 对 macOS 用户更友好。比如启动后会自动检测 iOS 模拟器勾选一个按钮就能让模拟器流量自动走代理省掉了手动配置 WiFi 代理这一大串操作。它还有一个我很喜欢的小功能接口响应可以直接以 Pretty Print 方式展示 JSON还把每个字段的类型高亮出来排查数据结构问题非常直观。3. 网络协议层的指挥官Wireshark 抓包与报文分析如果说 Charles 和 Proxyman 是“应用层放大镜”那 Wireshark 就是“协议层显微镜”。它能让你看到 TCP 三次握手、每一个 ACK、每一次重传甚至数据包在网卡层面的实际大小。代价就是学习曲线陡峭但一旦掌握排查网络问题的能力会直接上一个台阶。3.1 抓包原理与基本过滤语法Wireshark 不是代理模式不需要在应用里设置代理它直接监听网卡的流量。启动时选择正确的网卡很重要如果你要抓本机回环流量比如本机服务之间的通信在 Windows 上需要安装 Npcap 并勾选支持 Loopback否则127.0.0.1的流量是抓不到的macOS 上一般用Loopback: lo0口就能抓。Wireshark 的过滤分为两种抓包过滤器和显示过滤器。抓包过滤器在开始抓包前设置语法是 BPF比如tcp port 443、host 192.168.1.100。显示过滤器是抓完包后在上方输入框里过滤语法更友好也是非常高频使用的功能。几个最常用的显示过滤器示例ip.addr 192.168.1.100只看这个 IP 的流量tcp.port 443只看 443 端口流量http.request只看 HTTP 请求报文tls.handshake.type 1只看 TLS 握手中的 ClientHelloframe contains password查找 payload 中包含某段字符串的报文vlan.id 100只看指定 VLAN 的报文很多人还会问怎么“可视化”其实 Wireshark 自带不少分析视图。Statistics - Flow Graph 可以看到连接建立和断开的过程Statistics - I/O Graph 可以按时间轴画出报文速率曲线排查突发流量和拥塞时非常好用。3.2 HTTP/TLS 解密用 SSLKEYLOGFILE 还原明文Wireshark 虽然能看到加密后的 TLS 报文但看不到 HTTP 明文内容。想解密只有一个正规路径拿到 TLS 会话密钥。好在现代浏览器都支持通过环境变量把会话密钥导出到文件。以 Chrome 为例启动前设置环境变量SSLKEYLOGFILE指向一个文件路径比如D:\keys\sslkey.log然后用命令行启动 Chrome所有 TLS 会话的密钥就会写入这个文件。接着在 Wireshark 的 Preferences - Protocols - TLS 里把(Pre)-Master-Secret log filename指向同一个文件再次抓包Wireshark 就能把 TLS 加密的 HTTP 请求明文还原出来。Firefox 也支持同样的方式只要在启动前设置好环境变量即可。这个技巧在做 API 联调、排查第三方 SDK 请求、分析网页性能时特别有用。需要注意新版 TLS 1.3 在某些场景下对会话密钥的导出方式有调整Chrome 如果开启了部分加密的 ClientHello可能需要在 Wireshark 里配合 ECH 相关设置才能完整解密但这属于比较进阶的场景了。3.3 常见困惑MTU、分片与“只能显示520字节”的问题热搜里有个问题很典型“Wireshark 为何只能显示 520 字节数据怎么显示 2090 字节数据”。这个得从网络报文的基本机制说起。以太网的 MTU最大传输单元通常是 1500 字节。一个 IP 包封装进以太网帧时IP 头占 20 字节TCP 头占 20 字节所以一个 TCP 段最多携带的应用层数据就是 1500 - 20 - 20 1460 字节。这个 1460 就是常见的 MSS。因此你看到的单条 TCP 报文的载荷长度正常情况下不会超过 1460。那为什么有时候看到 520 字节有时候又需要看到 2090 字节这背后是 TCP 的分段机制。当应用层一次性写入 2090 字节数据时TCP 协议栈很可能把它分成两个段第一个段 1460 字节第二个段 630 字节。当然还有一种可能应用层本身只写了 520 字节整个载荷就是 520 字节这完全是合法的。Wireshark 默认会对同一 TCP 流的数据做重组所以你在 Follow HTTP Stream 或 TLS Stream 视图里能完整看到 2090 字节的连续数据但数据包列表里每一条记录显示的就是单个段的长度。如果你的 Wireshark 在流视图里依然只看到零散的段去 Preferences - Protocols - TCP 里检查两个开关Allow subdissector to reassemble TCP streams和Desegment all TCP streams把它们打开通常就能看到重组后的完整应用层数据了。简单总结就是520 或 2090 本身都不是错误而是 TCP 分段的正常现象。你要确认的是工具设置是否允许重组而不是怀疑工具坏掉了。4. Windows 生态的调试利器Fiddler 的高级玩法Fiddler 在最辉煌的年代几乎是 Windows 开发者人手一个的工具。现在它的热度比当年低了一些但在 Windows 平台和自动化调试场景下它依然有不可替代的位置。4.1 从抓包到断点用 FiddlerScript 做请求拦截Fiddler 的杀手锏是 FiddlerScript。它允许你在请求前后执行 JavaScript 代码实现自定义逻辑。你可以在 Fiddler 的FiddlerScript页签里直接改写代码改完按 CtrlS 保存立即生效。举个例子我想把所有发往api.example.com的请求重定向到本地环境static function OnBeforeRequest(oSession: Session) { if (oSession.HostnameIs(api.example.com)) { oSession.host 127.0.0.1:8080; } }保存之后请求就会全部打到本地服务上。这种能力在做后端迁移验证、灰度对比时非常实用。Fiddler 还支持断点调试菜单里的Rules - Automatic Breakpoints - Before Requests可以拦截请求After Responses可以拦截响应配合右侧的 Inspectors 面板可以手动修改请求参数或响应内容再放行这在调试边界条件时特别有用。4.2 弱网模拟与性能观察Fiddler 内置的弱网模拟入口很简单Rules - Performance - Simulate Modem Speeds。不过这个“调制解调器速度”偏向于极限弱网如果你想模拟 3G、4G 或者更细粒度的延迟和丢包可以打开 FiddlerScript查找OnBeforeRequest里与延迟相关的逻辑手动添加延时逻辑。比如模拟 200ms 的固定延迟加 20% 丢包可以这样写static function OnBeforeRequest(oSession: Session) { System.Threading.Thread.Sleep(200); if (new Random().Next(100) 20) { oSession.Abort(); return; } }这段代码能让你快速体验一下在劣化网络下接口的表现。不过 Fiddler 的弱网模拟更偏“粗粒度”如果你需要精细控制用 Charles 或 Proxyman 的 Throttle 设置会更顺手。4.3 卸载后上不了网代理残留问题排查“Fiddler 卸载后上不了网”这个话题在热搜里出现得非常多我也遇到过几次。原因基本是同一种Fiddler 在开启抓包时会把 Windows 的系统代理设置为127.0.0.1:8888。正常退出它会还原设置但如果在抓包状态下强制杀进程、或者用第三方清理工具把它当作垃圾文件直接删掉系统代理就不会被还原。排查顺序很简单。先看 IE 或 Edge 的“Internet 选项 - 连接 - 局域网设置”如果勾选了“为 LAN 使用代理服务器”取消勾选就能恢复。如果取消了还不行那就是 WinHTTP 层面的代理被改了打开命令行执行netsh winhttp reset proxy再执行netsh winhttp show proxy确认输出是“Direct access (no proxy server)”一般就恢复了。如果还不放心可以打开注册表编辑器定位到HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings把ProxyEnable的值改成 0删掉ProxyServer的值。操作前记得先备份注册表。整个过程的本质就是清理残留的代理配置和网卡驱动、系统文件没什么关系。顺便一提Windows 下如果浏览器访问 localhost 却走代理也可能报“无法访问此网站”常见解法是把地址写成http://localhost.:端口端口前加一个点或者用http://127.0.0.1就能绕开系统代理的干扰。5. 新一代工具与选型建议TraceEagle 值得关注吗TraceEagle 算是个比较新的名字公开资料还没有老牌工具那么丰富但这不代表它没有参考价值。从产品设计方向来看它代表了一类“工具平台化”的新趋势——抓包不只是看报文而是把调试、协作、文档沉淀绑定在一起。5.1 TraceEagle 的核心思路我个人的初步体验是TraceEagle 更像一个跨平台的 HTTP 调试工具目标用户很明确做接口联调的客户端、前端、测试同学。它的界面走的是现代设计风格不像老工具那样堆满密密麻麻的表格请求详情展示更接近 Postman 的阅读体验这对新上手的开发者非常友好。它比较有辨识度的点是团队协作方向。抓包记录可以持久化保存也可以导出成接口文档类的结构化数据多人联调时可以共享某一个抓包会话的上下文而不是像 Charles 那样靠截图和口头描述来同步问题。另外它还内置了 mock server可以把某个抓包记录直接变成一个可访问的 mock 接口这对后端接口还没写好的前端同学挺实用。不过要提醒一句工具越新生态越薄弱。它目前的社区资料、教程案例都比不上 Charles 和 Wireshark遇到奇奇怪怪的问题时能搜到的答案有限。所以我的建议是可以在个人项目或非核心项目里先体验不要盲目拿它替代已经跑顺的正式链路。5.2 五款工具怎么选最终决策建议如果你让我直接给配置方案我会这么说日常移动端接口调试首选 Charles。全平台支持、稳定、资料多团队里任何一个人遇到问题都能很快找到解法。如果你主力机是 macOS、又主要调试 iOS 生态Proxyman 会更顺手模拟器支持比 Charles 更自然。如果你在 Windows 上又经常需要写脚本改请求、断点调试、做自动化验证Fiddler 更合适。一旦问题掉到 TCP、DNS、丢包、重传、报文大小这些层面别犹豫切到 Wireshark。TraceEagle 可以作为团队协作场景的补充工具去观察等它的生态更成熟一些再纳入正式选型。工具从来不是越多越好而是要在合适的场景用合适的工具。我自己电脑上常年装着 Charles 和 Wireshark这两者一个管应用层、一个管协议层基本覆盖了 90% 的调试和排障场景。6. 高频问题与排查手册这节我把日常见到的高频问题统一整理成速查表并展开讲两类最让人头疼的故障排查过程方便你以后直接对照处理。6.1 问题速查表问题现象常见原因处理方式手机连上代理但 App 加载失败证书未安装或不信任安装抓包工具根证书iOS 需在证书信任设置里开启完全信任Charles 里全是 CONNECT看不到内容未启用 SSL ProxyingProxy - SSL Proxying Settings 开启并添加域名iOS 装证书后仍然报错未开启完全信任设置 - 通用 - 关于本机 - 证书信任设置Android 7 抓不到 App 的 HTTPS用户证书对 App 默认不生效使用可调试包并配置 networkSecurityConfig或 root 后装系统证书卸载 Fiddler 后浏览器无法上网系统代理残留取消“为 LAN 使用代理服务器”执行netsh winhttp reset proxyWireshark 抓不到本地回环流量网卡选择错误或未装 Npcap选择 Loopback 网卡Windows 安装 Npcap 并启用 Loopback 支持Wireshark 显示数据不完整TCP 重组未开启Preferences - Protocols - TCP 开启重组选项Fiddler 无法抓取 localhost系统代理绕过本机访问http://localhost.:端口或使用机器名6.2 代理端口冲突与启动失败排查很多代理类工具启动时会监听一个本地端口如果这个端口被其他程序占用就会出现类似failed to listen tcp on 108或failed to listen tcp on 8888这样的报错。这类问题看起来吓人其实就是端口被占用了。排查思路很简单。Windows 上打开命令提示符执行netstat -ano | findstr :8888如果看到 LISTENING 状态的记录最后一列就是占用进程的 PID。再用tasklist | findstr PID查这个 PID 对应的进程确认不是必要服务后用taskkill /PID 8888 /F结束它或者直接在任务管理器里找到对应进程结束。macOS 和 Linux 上用lsof -i :8888 kill -9 PID除了杀掉占用进程也可以在抓包工具里换一个端口比如把 Charles 的代理端口从 8888 改到 8899避开冲突。如果是在公司网络环境防火墙也可能拦截这类代理端口的入站流量需要确保电脑防火墙允许抓包工具对外监听。6.3 证书信任类问题汇总证书信任是所有 HTTP 调试代理工具的命门这块我多写几句。Windows 上安装 Fiddler 或 Charles 的证书一般会遇到浏览器提示“不是安全连接”的问题。解决方式是打开浏览器或系统的证书管理器把抓包工具的根证书导入到“受信任的根证书颁发机构”目录下。Chrome 内核浏览器会读取系统证书存储导入后基本就能正常访问。macOS 上安装证书后还要到“钥匙串访问”里把该证书的信任级别改为“始终信任”光双击安装是不够的。iOS 上除了安装描述文件还要在“设置 - 通用 - 关于本机 - 证书信任设置”里打开完全信任这个前面已经说过。要注意的是企业证书和根证书的安装位置不一样别弄混了。Android 的信任机制最麻烦特别是 Android 7.0 以上对用户证书的限制。建议开发阶段在 App 的networkSecurityConfig里显式信任用户证书或者测试时选择 browser 类的应用验证流量。Root 后把证书写入系统分区是另一个思路但不建议为了抓包专门去折腾系统分区风险大于收益。我在实际使用中还有一个经验如果 App 做了证书固定Certificate Pinning即使你信任了根证书它依然会拒绝代理的中间人证书。这种情况普通的抓包工具很难突破需要在 App 端配合调试或使用支持 SSL Pinning 绕过方案的增强工具。所以遇到抓不到包的问题先不要怀疑工具坏了按“代理通不通、证书信不信、App 让不让”这个顺序排查效率会高很多。最后再分享一个自己的使用习惯。日常开发调试我主力是用 Charles 或 Proxyman因为它们对 HTTP 的展示最友好手机抓包和 Mock 都很顺手一旦数据链路出现诡异问题我会立刻切到 Wireshark 看底层报文绝不在应用层靠猜Fiddler 则是在 Windows 上需要写脚本批量改请求、验证一些自动化逻辑时才登场。抓包工具选型没有绝对的对错关键是你对每款工具背后的原理理解得够不够深排查问题的思路够不够清晰。希望这篇对比和实操拆解能帮你少走一些弯路。