1. 先认清一个事实为什么你需要好几把抓包工具干网络调试这行久了你会发现一个现象——没有一个抓包工具是万能的。网上天天有人问“抓包工具哪个最好用”每次看到这种问题我都有点犯难因为答案真不是一句两句能说清楚的。Fiddler、Wireshark、Charles、tcpdump这些主流工具我全都天天在用但它们的侧重点完全不同。有人觉得Fiddler能抓HTTPS就很牛了有人认为Wireshark能看底层报文才是真功夫还有人非要争出个“最强”来。实际上这些工具在开发调试的不同阶段分别承担着不同的角色。就像你装修房子电钻、水平仪、切割机各有各的用武之地你非要说电钻最牛那切割机它也不答应啊。拿我自己的日常工作举例接口联调阶段我大概率开Fiddler或Charles做代理调试抓包排查某个TCP连接为什么反复重建、某个请求为什么延迟特别高我会打开Wireshark看底层交互处理安卓模拟器上的App或者微信小程序抓不到包的问题又得专门处理证书信任要是碰到蓝牙设备和USB外设的通信问题前面这些全都不好使得换专门的抓包方案。每个阶段都有自己最趁手的工具把这几个工具的配合关系理清楚你才能做到兵来将挡、水来土掩。这篇文章我会从实际工作的角度出发把不同阶段、不同场景下抓包工具的选型和操作细节一次讲透。内容会覆盖HTTP/HTTPS代理型工具、网卡底层抓包、安卓模拟器和微信小程序抓包、USB与蓝牙抓包这几个主要方向同时把我在实际使用中踩过的坑一并整理出来。2. 开发联调阶段的主角Fiddler与Charles这类HTTP代理工具2.1 为什么代理型工具是日常开发的首选假设你的前端页面调用后端接口返回结果不对你要怎么定位是前端传参的问题还是后端返回的问题最直接的方式就是把请求报文完整地看一遍。Fiddler和Charles这类工具做的事情特别纯粹——在你电脑上启动一个HTTP代理服务把所有经过它的请求缓存下来然后以列表的形式展示每个请求的Method、URL、状态码、耗时、请求头和响应体。你只需要把客户端或者浏览器的代理指向这个工具监听的端口流量就会自动经过它实现“中间人”观察的效果。这类工具最好的地方在于它们不关心TCP三次握手有多慢、不关心底层报文片段是怎么切割的而是把HTTP层的完整语义直接呈现在你面前。对于前后端联调、接口字段核对、请求头认证信息检查这类高频需求用它们效率是最高的。如果你用Chrome的开发者工具(F12)也能看这些信息那为什么还装Fiddler最大的区别在于Fiddler可以处理来自任何客户端的流量而不仅限于浏览器。安卓模拟器、微信开发者工具、桌面端App只要把它们的代理指向Fiddler你就能看到这些程序发出的请求。这一点在后端排查线上问题、移动端联调时特别关键。2.2 Fiddler的HTTPS解密配置详解现代的接口请求基本上都是HTTPS默认情况下Fiddler看到的全是加密后的密文完全没法用。要看到明文内容你需要做两件事第一在Fiddler中开启HTTPS解密开关它会生成一个根证书第二让发起请求的客户端信任这个根证书。Fiddler的根证书默认安装后会作为系统根证书被Windows信任所以本地浏览器发起的HTTPS请求可以被直接解密。但移动端设备或者模拟器里的应用并不会自动信任这个证书你需要把生成的证书导出并安装到目标设备里。具体操作路径是在Fiddler的Tools - Options - HTTPS选项卡中点击Export Root Certificate to Desktop然后把证书传到目标设备上安装。这里面有一个特别常见的坑在Android 7.0以上的系统里App默认不会信任用户添加的CA证书只有系统分区里的证书才会被信任。这就导致你Fiddler上能看到模拟器发的HTTP请求但看到的所有HTTPS请求都显示为Tunnel To内容完全解密不了。我后面在模拟器和微信小程序抓包部分会专门讲这一节的完整解决方案这里先记着这个现象。2.3 Charles适合谁用Charles在很多方面和Fiddler是同类产品但它有两点优势是Fiddler难比的。第一Charles是跨平台的macOS下用得特别顺对于我这个经常在Windows和macOS之间横跳的人来说操作方式和配置逻辑是一致的不需要重新适应。第二Charles的UI在展示请求树和结构体数据时更清晰尤其是JSON嵌套层级很深的时候展开收起的体验好得多。如果你是一个后端开发日常主要是看接口参数和分析返回结果我建议你优先尝试Charles如果你需要更复杂的请求导出、脚本自动处理、与Visual Studio调试器联动这样的能力Fiddler的生态圈更丰富一些。整体上这两者不需要纠结太久选一个用顺手的然后在需要的时候再来对比。3. 底层诊断阶段必须上的Wireshark3.1 Wireshark能看到什么Fiddler看不到的东西回到之前的场景Fiddler告诉你某个请求耗时3秒状态码500但你知道这3秒花在哪了吗是DNS解析慢、TCP握手延迟、TLS协商卡住还是服务器处理慢、响应体传输时间长这些问题Fiddler这种HTTP代理是没法拆解清楚的因为时间粒度不够细而且TCP握手发生在HTTP层之下。Wireshark就不一样了。它直接在你电脑的网卡上采集原始数据包看到的每一个报文都是真实的物理传输单元。你能通过连续几个包的时间戳计算出TCP三次握手花了多久能看到TLS Client Hello和Server Hello之间的间隔能分析一个TCP流里是否有大量重传和快速重传这些是抓包工具里最有含金量的诊断能力。实际工作中我最常用的几个Wireshark过滤器可以分享给你# 只看某一个IP的流量 ip.addr 192.168.1.100 # 只看某一个TCP端口 tcp.port 443 # 只看HTTP请求不含HTTPS加密流量 http.request # 过滤出TCP重传包 tcp.analysis.retransmission # 只看某一台服务器与主机的HTTP/HTTPS流量 http.host api.example.com ip.addr 192.168.1.100很多人抱怨Wireshark抓包看不懂其实主要是两点原因一是抓得太多、没有用过滤器约束范围导致整个列表全是无关包二是对TCP协议本身不够熟悉分不清SYN、ACK、FIN这些标志位意味着什么。我想说的是Wireshark的正确用法是先明确问题再抓包。比如“为什么A接口比B接口慢很多”带着这个疑问去抓、去用过滤器缩小范围比漫无目的地看一堆包有用得多。3.2 本地回环流量抓取的注意点开发调试过程中你经常会遇到自己本机的服务进程之间交互或者服务同时部署在本机的情况。这种请求走的是网卡的回环地址(127.0.0.1)默认情况下Wireshark在Windows上是抓不到的。在老版本中需要用Npcap并勾选“Support loopback traffic”选项新版Npcap一般会自动开启这个能力。如果发现抓不到回环数据第一件事就是检查Npcap的安装选项里有没有打勾。其实对于本机回环HTTP/HTTPS流量的调试用Fiddler这种代理型工具反而更简单因为代理本身就绕开了网卡抓包的限制直接截获应用层数据。3.3 Wireshark看HTTPS加密流量的思路Wireshark本身不能直接解密HTTPS但有一个让我觉得极其好用的功能——它可以读取浏览器或应用导出的TLS会话密钥SSLKEYLOGFILE从而解密已经抓到的加密流量。Chrome和Firefox都支持设置一个环境变量SSLKEYLOGFILE来导出会话密钥Windows上设置方式如下set SSLKEYLOGFILEC:\temp\sslkeys.log然后在Wireshark的Preferences - Protocols - TLS中把该文件路径配到(Pre)-Master-Secret log filename里。这样Wireshark就能把之前抓到的HTTPS包自动解密在协议列表里直接看到HTTP的明文内容。这个能力强在什么地方呢你可以回看一个已经发生的历史请求完整分析它的TLS握手过程、证书信息以及解密后的HTTP层响应这在排查加密流量中的性能问题时会给你带来很大的便利。但我必须提醒一句SSLKEYLOGFILE是对自己本机可控环境而言的如果目标应用是第三方App或者你不具备修改其运行环境的前提条件这个方案就不成立了。4. 移动端与模拟器专属场景USB抓包、Windows mumu模拟器与微信小程序抓包4.1 USB抓包工具哪个最好用提到USB抓包工具很多人第一反应是“USB抓包到底是在抓什么”。其实有两种情况一种是通过USB线将Android手机连接到电脑然后用adb和tcpdump在手机端抓取网络包另一种是抓取USB物理协议层的通信数据比如分析USB鼠标、键盘、U盘或自定义USB设备的通信报文。这两者差异很大工具的选择逻辑也完全不同。如果是抓Android设备通过USB转发的网络流量那核心工具还是tcpdump加上adb。操作上你需要先在手机上执行tcpdump命令采集采集完用CtrlC停止然后把生成的pcap文件拉到电脑上用Wireshark分析。Android设备上tcpdump需要有root权限才能完整抓包没有root的场合可以用一些App间接实现但不稳定所以我建议有条件还是用模拟器或者可root的设备做这类实验。如果是要分析USB设备和主机之间的底层通信比如排查一个USB外设为什么插上没反应、枚举失败那这就需要USB协议分析工具了。常用的包括开源的Wireshark配合USBPcap驱动在Windows下装了USBPcap之后Wireshark就能列出USB设备并抓取总线上的URBUSB Request Block报文。另一个是USBlyzerWindows下商业软件界面做得更友好URB的展示更结构化但需要付费。如果只是日常做嵌入式开发或者驱动调试Wireshark加USBPcap基本就够用了。在“usb抓包工具哪个最好用”这个热搜词上我的经验是如果你想抓Android网络包最稳的是带有root环境的设备或模拟器加tcpdump如果你想分析USB底层协议Wireshark加USBPcap是性价比最高的起步方案。4.2 Windows mumu模拟器抓包配置完整流程模拟器抓包算是移动端开发的高频需求尤其是网易mumu模拟器在Windows上的用户量很大。很多人遇到的情况是模拟器里能上网但Fiddler或者Charles的抓包列表里就是看不到模拟器App的请求。这通常是代理配置和证书信任两步没有做全。先说代理配置。模拟器界面里找到“设置”应用进入Wi-Fi设置长按当前连接的Wi-Fi选择修改网络然后把HTTP代理设置为“手动”。主机名填你电脑在局域网中的IP地址端口填Fiddler的监听端口8888Charles默认是8888或你自己设的端口。如果你用的模拟器支持自定义启动参数也可以在命令行里直接加代理参数比如mumu-player.exe 或者 emulator 相关启动命令加上 -http-proxy 192.168.1.100:8888但这里要注意Fiddler默认监听的是127.0.0.1只允许本机访问。你要让模拟器通过局域网IP访问到Fiddler还得在Fiddler的Options - Connections中勾选Allow remote computers to connect这一步漏掉的话模拟器里配了代理也连不上。配置完成后先在模拟器浏览器访问一个HTTP网站验证代理是否生效搜索Fiddler的抓包列表里有没有出现请求。没有的话先排查网络连接从模拟器ping一下电脑IP通了再检查端口。ping不通一般是防火墙拦截Windows的防火墙需要在入站规则里放行Fiddler或者对应端口。接下来是证书信任。前面提到了Android 7.0以上默认不信任用户CA证书的问题解决方法主要有两种。一种是把用户证书移动到系统证书分区这需要模拟器能rootmumu模拟器有root版本用adb remount后把用户证书复制到系统证书目录另一种是用Magisk模块或者Xposed插件绕过系统的证书校验但Xposed在模拟器上的稳定性参差不齐而且非官方环境操作有风险。在mumu这种通常自带root权限的模拟器上我一般会走系统证书方案。另外一个更省事的做法是在模拟器内安装旧版系统的镜像比如Android 6.0或者7.0以下这样用户证书就能被直接信任很多测试团队就是靠这种方式处理“小程序抓不到包”的问题的。4.3 微信小程序抓包的特殊难点微信小程序的网络请求与其他App不太一样的地方在于小程序的请求可能经过微信自身的网络框架处理且部分请求会走微信专门的长连接通道不会完全都走HTTP代理。所以你在Fiddler里能看到HTTP请求能用但在开发版或线上版小程序里很多请求根本不会出现在代理列表中。针对开发者工具里的微信小程序比较成熟的方案是打开微信开发者工具把“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”选项勾上然后在开发者工具中设置代理为Fiddler或Charles。这样工具里发起的请求就能通过代理被看到。微信开发者工具的新版本甚至自带网络面板可以直接看到请求详情不一定要借助外部抓包工具。如果你要在真实的微信客户端里抓小程序请求那就需要设置系统级代理并且让微信的进程信任你的证书。这里的复杂度主要体现在微信本身可能使用了自己的通道而且它对证书的校验策略比较严格。所以在很多公司内部测试环境中团队会直接采用专项抓包工具或者预先配置好证书信任环境的测试手机来操作。坦白说这一块没有百分百通用的傻瓜式方案需要结合自己手里的设备和环境实际情况去调试。我个人的习惯是优先在微信开发者工具里调试请求逻辑如果需要看线上版本的请求情况再配置系统代理和证书信任尽量不折腾各种二次封装工具。因为微信等大型应用会把请求体做加密混淆你即便抓到包也可能看不到明文业务字段需要在请求进微信之前截获或者反编译分析这已经超出常规抓包工具的角色范围了。4.4 电脑端模拟器流量和无线设备抓包的常用组合除了mumu之外BlueStacks、雷电模拟器等各有各的用户群但抓包配置逻辑大同小异核心还是代理加证书两步。要是模拟器内置浏览器访问不了代理端口建议直接把防火墙关了测试一次确认是防火墙还是模拟器的问题别在配置上反复猜测浪费时间。无线设备抓包场景里还有一个思路是设置一个软路由或者使用可做流量镜像的Wi-Fi设备让手机连接该Wi-Fi后所有流量被转发到电脑上的Wireshark或Fiddler。这种方式主要适合真实手机测试因为不用在手机上装证书或者改代理设置。不过部署复杂度更高一点小白可以先跳过。5. 物联网场景蓝牙抓包工具的分析与选型5.1 蓝牙抓包到底在抓什么蓝牙抓包和前面几种抓包有一个本质区别前面对付的是IP网络流量蓝牙抓包关心的是射频层、链路层和Host Controller InterfaceHCI这几个层次的报文。简单解释一下蓝牙设备之间的交互可以分成控制器Controller和主机Host两大部分控制器负责射频收发和链路管理主机负责逻辑链路控制和适配。HCI协议就是它们之间的沟通桥梁。对于开发者来说蓝牙抓包主要解决这几类问题第一设备A为什么连不上设备B连接参数如广播间隔、连接间隔是否合理第二蓝牙的数据传输为什么总是中断是信号干扰还是协议栈bug第三厂商自定义的GATT服务能不能正常解析广播数据里的厂商字段是否合法。这些问题靠打日志往往只能看到一个方向抓包能从协议层次还原出真实交互过程给出更可靠的分析依据。5.2 常用的蓝牙抓包工具与硬件选择蓝牙抓包的软件工具一般需要配合硬件设备使用纯软件方案在普通电脑上很难直接抓到射频层的蓝牙包。市面上常见的方案有Wireshark加BLE嗅探硬件比如Nordic的nRF Sniffer通过一个开发板把空中的BLE数据包分析成pcap回放给Wireshark展示。Ubertooth One开源硬件主要适用于扫描、嗅探和注入实验适合学习研究和低成本场景。Ellisys蓝牙分析仪专业级的商用设备支持BR/EDR和BLE的完整协议分析价格很贵一般是蓝牙协议栈开发或者认证测试才会用。如果你的设备是项目调试阶段手头又没有这些硬件还有一个软件方案值得考虑手机系统自带的HCI日志抓取。Android在开发者选项里有一个“启用Bluetooth HCI信息收集日志”的开关打开后系统会把蓝牙HCI日志记录到手机存储里可以导出后用专门的工具查看或转成pcap。这种方式不需要额外硬件但对于分析射频干扰、丢包这类问题就不够用了因为它只记录了主机侧和控制器侧的交互看不到空中的实际无线信号情况。我个人的建议是对于初学者或者普通App开发者先从HCI日志开始能解决大部分应用层交互问题只有当你要做协议栈底层调试或者产线排查的时候再考虑购入硬件嗅探器。从热搜词来看“蓝牙抓包工具”是很多人关注的但大多数人其实只需要HCI日志这个入门方案就够了。5.3 蓝牙抓包的分析思路实例假设你的设备用BLE连接手机经常出现连接不稳定的问题你用Android的HCI日志抓到一份log接下来怎么分析第一步确认连接事件是不是正常建立。在日志里搜索连接完成的LE Connection Complete事件记录连接的Interval、Latency、Timeout字段看这些参数是否符合预期。如果连接建立得很快被动断开再查连接更新请求和响应。第二步看GATT层的数据交互。如果某个Service读取或者写入失败在日志中会看到GATT Error同时会有对应的ATT错误码比如0x08就是“Attribute Not Found”0x0E是“Insufficient Authorization”这些错误码能直接告诉你问题的类型。第三步如果HCI日志里出现大量的TX或者RX失败结合实地环境的蓝牙信号强度检查一下是否有干扰源存在。这种分析方法虽然没有射频层的完整视角但至少能过滤掉协议栈和应用的大部分问题。往往排查完这三步问题就已经浮出水面了。6. 经典抓包问题排查实录6.1 Fiddler抓不到HTTPS请求只看到Tunnel To这个现象太经典了。Fiddler列表里出现一堆Tunnel To xxx:443说明代理接管了连接但HTTPS解密没有生效。排查思路先在Options里确认HTTPS解密开关是否勾选再看目标设备是否安装了Fiddler的根证书最后检查Android版本是否在7.0以上且不信任用户证书。实际中还有一个更隐蔽的问题Android应用使用了SSL Pinning证书锁定即应用内置了服务器证书的公钥哈希即使系统信任了抓包工具证书应用校验后依然会拒绝连接。这类问题在银行类、支付类App上非常常见。解决办法是通过反编译绕过去或者使用Frida这类动态插桩工具hook掉证书校验函数但这是比较高级的技术路线普通联调阶段不建议深挖。6.2 Wireshark抓到包但看不到应用层数据不少人第一次用Wireshark抓到的包全是TCP分片找不到HTTP层内容。这多半是因为抓包时机太晚或者收到了分片的TCP包需要点击右键Follow - TCP Stream来重组整个TCP流。重组之后就能看到这次TCP连接里的完整数据内容了。还有一种情况是流量被TLS加密得到的是密文这就要用到前面讲的TLS会话密钥方案或者放弃明文需求直接用Fiddler代理层面解决。6.3 为什么在模拟器里配置了代理还是连不上网模拟器里的代理配置看起来是对的但打开浏览器访问任何网站都提示无法连接。多数是因为Windows防火墙没放行抓包工具的监听端口。Fiddler的默认端口是8888Charles默认是8888你在防火墙入站规则中需要允许这些端口。还有一种情况是代理配置的IP不对。mumu模拟器里如果网络模式是NAT模拟器里的虚拟网络和宿主机局域网不是同一网段但代理填的可以是路由器分配给宿主机电脑的局域网IP这一点一般没问题但如果你填的是模拟器虚拟网卡的IP那模拟器自己都访问不到。看IP的一个简单办法是电脑上输入ipconfig查看Wi-Fi或以太网适配器的IPv4地址把这个IP填进模拟器代理设置里就不会错了。6.4 灰度排查用抓包工具定位请求慢的完整案例有一次我在排查一个接口卡顿问题用户反馈某个页面转圈至少5秒才能出数据。我用Fiddler抓包先看到该请求总耗时6秒里面Time to First Byte占了4.8秒Content Download时间较短。这说明瓶颈主要在服务端响应阶段而不是网络传输。为了进一步确认是不是服务器处理慢我打开Wireshark抓了一次包。从TCP握手时间上看三次握手在1毫秒内完成说明网络链路通畅但发现从客户端发出HTTP请求到收到第一个TCP ACK数据包之间有接近5秒的间隔而且这段时间内没有任何TCP重传或乱序。这就能初步推断是服务器业务层处理时间过长或者是中间有负载均衡策略在等待上游。后续让后端同事看应用监控日志果然发现这个接口在某个时间段内存占用过高触发了GC长停顿。这个案例说明Fiddler定位到“请求慢在哪个阶段”Wireshark负责把慢的具体层次缩小到网络层还是应用层两者配合起来能够大幅节省排查时间。7. 工具选型速查表我最终的建议我把常用抓包工具按适用场景整理成了一张速查表方便大家直接对照选择。工具/方案适用阶段主要能力注意点FiddlerHTTP/HTTPS接口联调、代理配置查看HTTP层请求响应、构造请求、脚本扩展Windows为主Android 7.0需处理证书信任CharlesHTTP/HTTPS接口联调跨平台界面友好、JSON解析方便macOS上体验更好部分高级功能收费Wireshark底层网络诊断、TCP/TLS分析原始报文、过滤器、TLS会话密钥解密上手门槛高需要熟悉TCP/IP协议tcpdumpLinux/Android等远程环境抓包命令行抓包生成pcap文件通常需要root权限USBPcap WiresharkUSB设备协议分析抓取USB URB报文Windows下需要安装驱动需要一定的USB协议基础Android HCI日志蓝牙设备应用层调试捕获HCI交互、GATT错误看不到射频层信号情况nRF Sniffer等硬件BLE协议全流程分析空口数据包捕获和分析需要额外硬件上手难度高从优先级来说如果你刚开始接触抓包先把Fiddler或Charles用熟练日常绝大多数联调场景就够用了然后逐步了解Wireshark的过滤器万一碰到诡异的网络问题不至于手足无措再往后根据自己的项目方向深入到模拟器证书处理、USB协议或者蓝牙HCI日志这类专用领域。这里我也想分享一个经验不要贪多每个层次的工具选一个用顺手的深入研究它的配置和脚本能力比把所有工具都安装了一遍、但每个都只会点一下“Start”要有用得多。抓包工具的最终价值在于帮你形成数据包思维——看到问题先猜哪个阶段出问题再选择合适的工具去验证而不是打开一个工具盲目地抓抓完又看不懂。如果你刚开始换到一个新的抓包工具花二十分钟把它的设置项全部过一遍重点看证书、代理监听地址、日志存储位置这几个关键项后面能少踩很多坑。模拟器和小程序抓包遇到难题时也别忘了先看官方文档和开发者选项有时候最简单的开关就能解决折腾半天的问题。