企业官网建设流程全解析

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. 底层诊断阶段必须上的Wireshark

3.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 SSLKEYLOGFILE=C:\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命令采集，采集完用Ctrl+C停止，然后把生成的pcap文件拉到电脑上用Wireshark分析。Android设备上tcpdump需要有root权限才能完整抓包，没有root的场合可以用一些App间接实现但不稳定，所以我建议有条件还是用模拟器或者可root的设备做这类实验。

如果是要分析USB设备和主机之间的底层通信，比如排查一个USB外设为什么插上没反应、枚举失败，那这就需要USB协议分析工具了。常用的包括开源的Wireshark配合USBPcap驱动，在Windows下装了USBPcap之后，Wireshark就能列出USB设备并抓取总线上的URB（USB Request Block）报文。另一个是USBlyzer，Windows下商业软件，界面做得更友好，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的监听端口8888（Charles默认是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证书的问题，解决方法主要有两种。一种是把用户证书移动到系统证书分区，这需要模拟器能root，mumu模拟器有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 Interface（HCI）这几个层次的报文。简单解释一下，蓝牙设备之间的交互可以分成控制器（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的默认端口是8888，Charles默认是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. 工具选型速查表：我最终的建议

我把常用抓包工具按适用场景整理成了一张速查表，方便大家直接对照选择。

从优先级来说，如果你刚开始接触抓包，先把Fiddler或Charles用熟练，日常绝大多数联调场景就够用了；然后逐步了解Wireshark的过滤器，万一碰到诡异的网络问题不至于手足无措；再往后根据自己的项目方向，深入到模拟器证书处理、USB协议或者蓝牙HCI日志这类专用领域。

这里我也想分享一个经验：不要贪多，每个层次的工具选一个用顺手的，深入研究它的配置和脚本能力，比把所有工具都安装了一遍、但每个都只会点一下“Start”要有用得多。抓包工具的最终价值在于帮你形成数据包思维——看到问题先猜哪个阶段出问题，再选择合适的工具去验证，而不是打开一个工具盲目地抓，抓完又看不懂。

如果你刚开始换到一个新的抓包工具，花二十分钟把它的设置项全部过一遍，重点看证书、代理监听地址、日志存储位置这几个关键项，后面能少踩很多坑。模拟器和小程序抓包遇到难题时，也别忘了先看官方文档和开发者选项，有时候最简单的开关就能解决折腾半天的问题。