企业官网建设流程全解析

日常做开发、搞测试、排查网络故障的人，手里肯定离不开抓包工具。不管你是要调试接口、分析页面请求、看App有没有偷偷上报数据，还是想搞清楚某个视频流的地址到底在哪，全平台可用的网络抓包软件总能派上用场。市面上的抓包工具名字一堆，分布在不同平台、不同场景，真正免费又好用的其实就那么几个，但很多人一上来就卡在选型上。

这篇文章就围绕“全平台、网络抓包、抓包工具”这三个关键词展开，我会从工具选型逻辑讲起，把主流的免费跨平台抓包软件逐个拆一遍，连手机App、小程序、USB、蓝牙这些特殊场景的抓包方案也一起整理出来。内容适合刚接触抓包的后端开发、客户端开发、测试工程师，也适合做网络运维和协议分析的朋友。前后梳理了好几个月的实操经验，包括证书配置、过滤器语法、抓包踩坑，直接照着抄就行。

1. 全平台抓包：先搞清楚工具选型的基本逻辑

1.1 抓包到底在抓什么？

很多人以为抓包就是“看请求和响应”，其实这只是最表层的东西。抓包工具在系统底层做的事情是捕获网卡上经过的数据帧，然后把网络协议栈层层解开，还原成你能看懂的HTTP请求、TCP连接、DNS解析、TLS握手过程。也就是说，抓包不是某个软件“发明”了数据，而是它把原本就存在于网络中的数据“截获并翻译”给你看。

从技术本质上分，抓包工具工作在网络的不同层级。像Wireshark这种是基于pcap库的，直接抓取链路层的数据帧，网卡上跑什么它全都能看到；而Fiddler、Charles这类工具则是把自己注册成系统代理，应用层的数据会主动经过它，所以它们天然更关注HTTP/HTTPS协议。这也就解释了为什么有些工具能分析“TCP重传”，有些工具却只擅长“改请求、看响应”。

理解了这一点，你在选工具的时候就不会被带偏。做协议分析、排查网络层问题，首选Wireshark；只调接口、看请求参数、调试问题，Fiddler或Charles更顺手；搞Web安全测试，Burp Suite几乎是标配；而在命令行环境或服务器上，tcpdump加mitmproxy的组合才是王道。

1.2 免费工具怎么选？先按平台和使用场景分类

所谓“全平台”，指的是Windows、macOS、Linux三大桌面系统上都能跑，而不是说只有一个平台的版本。很多新手在Windows上用惯了Fiddler，换成Mac之后发现Fiddler Classic装不了，就以为没工具可用了，其实跨平台方案早就很成熟。

选型的时候我习惯先问三个问题：你要抓什么流量？你在什么环境里操作？你需不需要改包重发？如果是纯看流量分析协议，Wireshark是免费工具里覆盖面最广的，桌面端三平台全覆盖，还有命令行版TShark，远程服务器上也能用。如果核心需求是HTTPS调试、查看请求细节、定向抓取某个App或小程序的流量，Fiddler Everywhere、Charles、mitmproxy这些代理型工具会更友好，因为它们天然就能解密HTTPS。如果做安全测试、想手动构造和重放数据包，Burp Suite社区版虽然有点限制，但代理、拦截、重放这些核心功能都还是免费的。

下面这张对比表，把目前主流的免费或提供免费版本的全平台抓包工具放在一起，方便你横向参考。

2. 主力全平台抓包工具逐个拆解

2.1 Wireshark：协议分析的王牌

Wireshark这个工具做网络的人应该没人不知道，它免费、开源、全平台，正儿八经的协议分析神器。它的抓包原理是直接通过操作系统的pcap接口读取链路层数据帧，所以你不仅能看到HTTP请求，还能看到TCP握手、TLS证书交换、DNS查询、ARP广播这些底层细节。换句话说，只要流量经过你正在监听的网卡，它都能记录下来并帮你解析成可读的结构化信息。

Wireshark最强大的地方在于协议解码能力。它内置了上千种协议的解码器，从常见的HTTP、TCP、UDP，到工业协议、蓝牙HCI、USB流量都能解。你只需要在“显示过滤器”里输入一句语法，比如http.request.method == "GET"，它就能立刻帮你把所有GET请求过滤出来；输入tcp.analysis.retransmission，它就直接把所有TCP重传包高亮显示。这种“从海量数据流中快速定位问题”的能力，是其他代理型工具完全没法比的。

我实际用得最多的一个功能是“Follow HTTP Stream”（跟踪流）。抓完包之后右键选中一条HTTP记录，选择追踪TCP流，Wireshark会把这次完整请求的请求头、请求体、响应头、响应体全部按顺序拼在一页显示出来。排查接口为什么返回500、某个字段为什么没传对，这个功能效率极高。

但Wireshark也有明显的学习门槛。过滤器语法不算复杂，但新手初次打开看到几万条数据包，根本不知道从哪看起。我的建议是先学会三四个核心过滤器：按IP过滤ip.addr == 192.168.1.10、按端口过滤tcp.port == 443、按协议过滤http或dns、按请求方法过滤http.request.method == "POST"。只要把这几个记住，日常排查问题就够用了。

2.2 Fiddler系列：HTTP/HTTPS调试的效率之选

Fiddler在老一代Windows开发者心中的地位很高，它不是一个网络层抓包工具，而是把自己注册为系统代理，应用层所有的HTTP/HTTPS流量都会经过它。正因为这样，它天生就能看懂请求和响应，能一键解密HTTPS，还能打断点、改请求、模拟弱网，在做接口调试和前后端联调的时候非常顺手。

目前Fiddler有两套产品线：Fiddler Classic只支持Windows，完全免费，老用户习惯性称它为“经典版”；Fiddler Everywhere是跨平台版本，支持Windows、macOS、Linux，基础抓包功能免费，界面更现代化，它也保留了Classic里的核心交互逻辑。如果你现在用的不是Windows系统，直接用Fiddler Everywhere就行；如果你是Windows用户，其实Classic的体验依然很好，而且不用登录账号、没有任何平台限制。

Fiddler最让我离不开的功能是AutoResponder（自动响应器）。它可以把某个请求直接映射到本地文件，或者返回预设的响应内容。做前端开发的时候，后端接口还没就绪，我会先用AutoResponder把假数据放上去，页面立刻就能正常联调，不用干等后端。这个功能在调试异常流程、模拟不同返回码时也特别有用。

另一个用得多的功能是Composer，相当于一个可视化接口调试面板。你可以从左侧会话列表里把任意一条请求拖进来，修改方法、地址、请求头、请求体之后就重新发送，观察响应变化。对比有些独立的API调试工具，它的优势在于上下文是完整的——你修改的是真实抓下来的请求，而不是手工造出来的。

2.3 Charles和Burp Suite：开发调试和安全测试场景

Charles是macOS生态里非常流行的抓包工具，当我第一次在Mac上用它抓iPhone的包时，只需要在手机上把WiFi代理指向Mac的IP和Charles监听的8888端口，再安装并信任证书，HTTPS流量就能在Charles里明文看到。它在移动开发圈的普及率很高，因为苹果生态里很多工具链不如Windows那么齐全，Charles提供了一个足够顺手的跨平台方案。

Charles的核心机制也是代理，但它的界面设计更强调“会话结构”——左侧按照域名和URL自动归组，你可以快速看出某个App调用了哪些接口、每个接口的耗时是多少。它的“SSL Proxying”设置支持按域名精确控制是否解密HTTPS，这样可以避免抓到大量无关流量。另外Charles的Map Local和Map Remote功能也和Fiddler的AutoResponder对应，适合做重定向和本地替换。

Burp Suite则是完全不同的方向，它面向Web安全测试场景，代理只是它的众多功能之一。社区版免费，可以跨平台运行在Windows、macOS和Linux上。Burp的代理模块可以拦截所有经过它的HTTP/HTTPS请求，你可以在Repeater里修改请求并重放，在Intruder里做参数爆破，在Decoder里做编码转换。安全测试人员常说的“抓包改包”，九成情况下指的就是Burp。

不过Burp的入门门槛比Fiddler高不少，它的配置方式也更“重”。默认情况下Burp需要关闭系统代理或安装扩展证书，而且社区版的Intruder速度受限（专业版才支持并发爆破）。我的建议是：如果你不是做安全方向，日常接口调试优先用Fiddler或Charles；如果做Web渗透或者需要手动构造攻击报文，再把Burp用起来。

3. 特殊场景的抓包方案：手机App、USB与蓝牙

3.1 小程序与手机App抓包：代理加证书那套事

手机App和小程序用的是加密的HTTPS流量，想抓到明文，核心步骤就两步：把流量引到你的抓包工具上，然后让手机信任抓包工具签发的CA证书。一般流程是在电脑上打开Fiddler或Charles，开启“允许远程连接”，手机连同一个WiFi后把代理指向电脑IP和监听端口，然后访问一个特殊地址下载安装CA证书，安装后在系统设置里手动信任。

但这里有个常见的坑：Android 7.0及以上版本，App默认不信任用户安装的证书，即使你装了CA证书，很多App仍然报“证书校验失败”或直接断网。原因就是Android的网络安全配置默认只信任系统证书。解决办法要么是root后把证书移入系统证书目录，要么通过反编译修改App的networkSecurityConfig，要么用Frida配合脚本绕过SSL Pinning。对于只想调试接口的普通开发者，我建议直接用模拟器（比如Windows上的MuMu模拟器）配合Fiddler，把证书装进系统镜像里，比真机折腾起来省心很多。

小程序抓包的情况更特殊。先说微信小程序，它在移动端默认不走系统代理，所以常规的“手机设置代理”方案在部分新版本上无效。实测下来最稳妥的方式是用Windows版微信，在电脑上登录微信后打开小程序，然后让Fiddler或Charles抓电脑端的HTTPS流量。电脑端的微信流量会走系统代理，所以能直接抓到小程序发起的请求。如果你在模拟器里装了微信也可以用类似思路，但要额外处理模拟器网络与宿主机代理的连通性问题。小红书、支付宝这类App内嵌的小程序或H5，原理都差不多，核心就是“让目标请求走代理”。

iOS端抓包相对简单一点，但证书信任多一步：装完描述文件后，还需要去“设置—通用—关于本机—证书信任设置”里手动打开该证书的完全信任开关，否则HTTPS照样解密不了。

3.2 USB抓包怎么搞？

提到USB抓包工具哪个最好用，这个问题得分平台。Windows平台上最主流的免费方案是USBPcap，它本身是一个抓包驱动，配套的界面非常简陋，但抓出来的文件可以保存为pcap格式，直接用Wireshark打开分析。USBPcap安装后需要管理员权限，抓包时会让你选择捕获哪条USB总线或设备，选定之后运行，再复现一次你的USB操作，这样数据的完整交互过程就被记录下来。

Linux平台可以用内核自带的usbmon模块，不需要额外安装驱动，只需要加载usbmon并挂载调试文件系统，通过Wireshark的usbmon接口就能抓取USB流量。

macOS平台比较麻烦，苹果对USB驱动的管控很严格，免费方案非常有限，Wireshark只能抓有限的USB流量，很多USB设备的数据根本捕获不到，更靠谱的方案是借助Bus Pirate这类硬件调试工具或者商业版的USB协议分析仪。对于绝大多数人来说，Windows的USBPcap加Wireshark是最省事的选择。

抓USB流量不像抓网络流量那样能立刻看到HTTP明文，USB包里全是传输层的数据块，需要结合你设备的协议规范去解读。所以USB抓包更多用于嵌入式设备调试、驱动开发、外设协议逆向这些专业场景。

3.3 蓝牙抓包的设备和工具

蓝牙抓包又是一个不同维度的领域，想抓到完整的蓝牙通信数据，光靠软件是不够的，因为蓝牙流量走的是无线电而非网卡，普通电脑根本收不到。你需要一个专门的蓝牙嗅探硬件，把空中的蓝牙数据包截获下来再交给软件解析。

目前最常见的低成本方案是Nordic的nRF Sniffer for Bluetooth LE。它需要搭配一块nRF52840 USB Dongle（大概一百多块钱），固件刷成Sniffer模式后插到电脑上，用Wireshark直接选择该设备作为捕获接口，就能实时看到周围的蓝牙LE广播包和连接数据包。这套方案的好处是Wireshark原生兼容，解析出来的报文结构很完整，广告数据、扫描响应、LL控制包都能逐层展开看。

Android设备还有一个另类方案：在开发者选项里打开“启用蓝牙HCI信息收集日志”，系统会把蓝牙协议栈收到的HCI数据包保存为btsnoop文件。拿到这个btsnoop文件后用Wireshark打开，就能看到这台手机收发过的蓝牙数据包。这个方案不需要额外硬件，但问题在于它只能看自己设备上的蓝牙数据，看不到其他设备之间的通信。

如果你想分析的是经典蓝牙（BR/EDR），或者需要抓两个外设之间真正的空中数据包，还是得入手Ellsys或Frontline这类商业蓝牙分析仪，价格很贵，一般个人开发者用不上。

4. 一次完整的抓包实操：从零开始抓到HTTPS请求

4.1 配置代理与安装CA证书

这里我用Fiddler Classic在Windows系统上抓浏览器和手机App的HTTPS流量做示例，完整走一遍流程，你换到Charles或Fiddler Everywhere也完全类似。

第一步，打开Fiddler菜单里的Tools—Options—HTTPS，勾选“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”，这时候会弹出提示是否信任Fiddler根证书，选“Yes”。这一步的实质是把Fiddler生成的根证书安装到你的Windows系统证书库里。只有完成这步，浏览器访问HTTPS网站时才不会因为证书不受信任而报错。

第二步，确认代理端口。Fiddler默认监听8888端口，在Tools—Options—Connections里可以看到。如果要抓手机上的流量，打开“Allow remote computers to connect”，然后查看你电脑在局域网里的IP地址（命令行里输入ipconfig查IPv4地址）。手机连上同一个WiFi，在网络设置里把代理设为“手动”，服务器填电脑IP，端口填8888。

第三步，手机安装证书。用手机浏览器访问http://电脑IP:8888，页面上会有一个FiddlerRoot certificate的下载链接，下载后安装到手机证书区。iOS用户装完描述文件后要记得去证书信任设置里开启完全信任。Android用户装完后，建议先去浏览器随便访问一个HTTPS网站，确认能正常打开且Fiddler能看到明文，再继续后面的App抓包。

这一步最常遇到的问题就是“装了证书还是不信任”，九成原因是Android 7.0以上的用户证书信任机制。你可以在手机上用命令查一下证书是不是装到了“用户证书”区域，如果App坚持不认，就只能想办法进“系统证书”区域，或者用模拟器方案绕开。

4.2 过滤器的核心用法

抓包工具一旦跑起来，流量是海量的，尤其是在电脑上开着浏览器、微信、各种App，一分钟就能刷出几千条请求。这时候如果不过滤，你根本找不到想看的那个接口。过滤能力的使用熟练度，直接决定了抓包效率。

Fiddler的过滤器在左下角的“Filters”页签里。最简单的用法是勾选“Use Filters”，然后在Hosts区填上你要抓的域名，比如www.example.com，它就会只显示来自该域名的请求。更精细的做法是在“Request Headers”里填特征字段，或者按响应状态码过滤，比如只看500、403的请求。

Wireshark这边更依赖显示过滤器语法。我整理几个高频使用场景的过滤器写法，你直接复制就能用：

# 只看某个IP的流量 ip.addr == 192.168.1.100 # 只看HTTP GET请求 http.request.method == "GET" # 只看某个域名的HTTPS握手（TLS SNI过滤） tls.handshake.extensions_server_name contains "api.example.com" # 只看所有TCP重传包 tcp.analysis.retransmission # 只看DNS查询 dns.flags.response == 0

熟练掌握这些语法之后，你用Wireshark排查问题的速度会提升一个层次。比如用户反馈某功能请求很慢，我先过滤出该域名的所有TCP流，然后看发起时间间隔、看有没有重传、看TLS握手用了几次RTT，基本几秒就能定位是网络层问题还是服务端处理慢。

4.3 抓包之后的流量分析思路

抓到包之后，分析才是重头戏。我分享一个日常排障的分析顺序：先看请求是否发出、再看响应是否返回、然后看耗时分布、最后看内容是否正确。

用Fiddler举例，左侧会话列表每一行代表一个请求，列名包括结果、协议、主机、URL、内容类型、耗时等。如果页面有问题，先找到对应请求，看它是否返回200；如果返回404或500，直接看Response里的报错内容；如果返回200但页面不对，把请求体和响应体拉出来，前后端逐个字段排查。

如果是网络慢的问题，就用Wireshark看“耗时细节”。Wireshark里有“Statistics—Service Response Time”一类功能，也可以直接看TCP流的往返时延。一个最简单的判断方法是看瀑布图（Statistics—Flow Graph），它能直观展示每个请求从发出到收到响应的时序变化，如果发现某个请求在前面排队了很久，那问题多半出在浏览器同域名并发连接数或服务端连接池上。

再补充一个很实用的技巧：抓完包后把关键会话保存导出。Fiddler可以按快捷键“Ctrl+S”导出为.saz存档，Wireshark可以导出为.pcapng文件。把这个文件发给同事或服务商，对方用同样工具打开，就能看到完整的请求数据、头部字段、响应体，比截图省事得多，也能避免手动复制过程中遗漏细节。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

这些问题都是我在各个项目里实际遇到的，按“现象—原因—解决办法”整理成了一张速查表，你遇到类似的可以直接翻。

5.2 几个独家心得

说几个常规文档里不会写的实操体验，都是踩坑踩出来的。

第一个心得：抓包之前先想清楚“当前会话的边界”。比如你要调试小程序，那就只打开对应的工具和界面，其他App、后台更新、浏览器标签页全部关掉或过滤掉，这样流量列表才干净。流量越少，定位越快，这不是洁癖问题，而是真实效率问题。

第二个心得：不要同时开两个代理型抓包工具。Fiddler、Charles、Burp都抢着设置代理时会互相覆盖，轻则抓不到包，重则整机断网。遇到“设置半天就是不通”的情况，先查一下是不是系统代理已经被别的工具占用了，Windows上可以在“设置—网络和Internet—代理”里看手动代理是否开着，macOS在“网络—高级—代理”里查。

第三个心得：分析HTTPS抓包结果时，别只看Header，Response Body里的信息往往更有价值。有一次我帮同事排查线上接口偶发超时，从Fiddler响应体里发现服务端在业务异常时返回了一个非常长的堆栈信息，导致响应大小暴增，传输耗时就上去了。这种问题只看状态码根本发现不了。

第四个心得：网课视频、在线音视频这类流媒体请求，很多人想抓包是为了拿到视频地址、分析卡顿原因。用Fiddler或Wireshark抓到m3u8、mp4地址后，你可以用它来测试带宽、验证CDN节点、分析延迟和重传，这些都属于正常的网络排查用途。但要注意，视频内容本身有版权归属，分析地址用于调试没问题，未经授权下载、录制和二次分发就涉及合规风险了，这个边界一定要把握好。

6. 写在最后：抓包这事，工具只是第一步

工具列得再多，最终还是要落到实际问题的分析和解决上。我的个人经验是，新手学抓包不要一上来就追求把所有工具都摸透，那会很快消耗掉耐心。正确路径应该是：先用Fiddler或Wireshark中的一个，把浏览器端某个你熟悉的页面请求完整抓一遍，看一遍请求头、响应头、Cookie、证书、耗时，等你对“流量长什么样”有了体感，再横向扩展去学其他工具和特殊场景。

真正值钱的能力是那套分析思路：请求有没有发出去、数据从哪里来、哪一段耗时最长、服务端返回了什么、客户端怎么处理的。工具只是把你的“眼睛”延伸到数据链路里而已，看清楚之后，怎么判断、怎么定位，靠的还是你对协议和业务的理解。

最后分享一个小技巧：每次抓包分析完一个疑难问题，我会把当时的过滤器表达式和关键分析过程存到自己的笔记里。过几个月再遇到类似问题，直接翻出来套用，省的时间远比当初记笔记花掉的多。希望这篇抓包工具大全，能让你少走一些我走过的弯路。