企业官网建设流程全解析

做接口调试这些年，我几乎每天都要打开抓包工具看看请求到底长什么样。经常有朋友问我：免费的抓包工具到底选哪个？网上搜出来的答案七零八落，不是只讲Wireshark，就是只讲Fiddler，看完还是不知道怎么下手。正好借这个机会，把我实际用过的、在全平台都能跑起来的免费抓包方案一次性整理出来。从原理讲起，到工具选型，再到具体操作和踩坑记录，争取让你看完就能自己动手抓包。

1. 抓包原理与工具认知

1.1 抓包到底在抓什么

抓包这个概念，说白了就是把电脑或手机上经过网卡的流量截获下来，看一眼数据包里面到底装了什么内容。平时我们说“抓包”，绝大多数场景指的是抓HTTP/HTTPS协议的流量，也就是浏览器、APP和后端服务器之间交互的那层数据。你打开一个网页，浏览器会发一个GET请求，服务器回一个JSON或者HTML，这段一来一往的对话，就是抓包工具展示给你的核心内容。

更深一层，Wireshark这类工具还能往下探到TCP、UDP、DNS、TLS这些底层协议。比如你发现某个APP启动后一直在悄悄连某台服务器，表面上没有打开任何页面，但底层的DNS请求和TCP连接都记录得清清楚楚。抓包工具能看到的东西，远比你想象中的多。

这里要理清一个关键概念：抓包和监听不是一回事。监听是被动地看着流量经过，而HTTPS抓包需要做一次“中间人解密”。原因是HTTPS的流量是加密的，直接截获下来是一堆乱码，得让客户端信任你手里的证书，流量才会在你这边解开成明文。市面上大多数HTTP调试工具，包括Fiddler、Charles、mitmproxy，干的都是这个活儿。

1.2 谁需要抓包工具

我总结了一下，日常需要抓包工具的人大致分成这么几类：

第一类是前端和后端开发人员，排查接口问题时，总得确认请求头、请求体、响应数据到底对不对。有时候后端说“我返回了”，前端说“我没收到”，这时候抓一次包，真相立刻见分晓。第二类是移动端开发，APP的接口调试、推送消息排查、Android模拟器里的网络请求，都离不开抓包。第三类是测试工程师，尤其是做接口自动化测试和性能测试的，需要抓包验证请求参数和响应断言。第四类是协议分析和安全方向的朋友，需要看底层报文、做安全测试，这时候Wireshark和Burp Suite就是主力工具。

不管你是哪一类，选工具的逻辑其实就一句话：先搞清楚你关心的是哪一层流量，再决定用哪把“刀”。只关心HTTP接口用Fiddler或mitmproxy，关心底层网络报文用Wireshark，做安全渗透测试用Burp Suite。别指望一把工具通吃所有场景。

2. 全平台免费抓包工具全景盘点

2.1 全平台底层抓包选手：Wireshark

Wireshark在抓包工具里属于“天花板”级别的存在，免费、开源、跨平台，Windows、macOS、Linux全都有稳定版本。它抓的是网卡上经过的所有报文，不区分你是浏览器流量还是命令行流量，也不在乎你是HTTP还是TCP，统统展现在你面前。

Wireshark的强项是底层协议分析。它内置了上千种协议解析器，小到ARP、ICMP，大到HTTP/2、gRPC、TLS，基本你能想到的协议它都认识。界面虽然看起来很复杂，满屏的协议树和数据包列表，但核心操作其实很简单：选择网卡、开始抓包、输入过滤表达式、看结果。

它的学习曲线主要卡在过滤表达式上。比如你想只看HTTP请求，得在过滤栏输入http，想看某个IP的流量就输入ip.addr == 192.168.1.10。这些表达式看起来像一门小语言，但常用的大概十个左右，用熟了效率极高。我在排查线上问题时，经常是先抓一份完整的pcap文件，再慢慢用过滤条件筛选线索。

需要提醒的是，Wireshark本身不做HTTPS解密。它能把TLS握手过程看得明明白白，但握手之后的内容是加密的。要解密HTTPS，得配合浏览器或应用导出会话密钥，操作门槛略高。所以如果你只关心HTTP接口内容，直接用Fiddler或mitmproxy更省事。

2.2 HTTP/HTTPS调试专属工具：Fiddler与mitmproxy

Fiddler是Windows平台老牌抓包工具，老版本只支持Windows，新版Fiddler Everywhere虽然跨平台了，但免费版有限制。这里说的免费全平台方案，我更推荐把Fiddler Classic（Windows专用）和mitmproxy（全平台）搭配着用。

Fiddler Classic的优势是开箱即用，图形化界面，装完就能抓。它启动后会自动接管系统HTTP/HTTPS流量，左边是所有请求列表，右边是请求头和响应体的预览，还有Composer功能可以手动构造请求，调试接口非常方便。唯一的问题是需要先安装并信任它的根证书，否则HTTPS请求会直接报证书错误。

mitmproxy就完全是另一个路子，它是命令行工具，安装方式是一行命令：pip install mitmproxy。启动mitmproxy后，它会监听8080端口，把手机或浏览器的流量指过来，然后你就在终端里看到一条条请求记录。如果命令行看得不习惯，还可以用mitmweb启动一个网页版界面，在浏览器里查看和筛选请求。

mitmproxy最强大的地方是可以写Python脚本直接修改请求和响应，做自动化测试、mock数据、流量回放都是它的拿手好戏。比如我想把线上某个接口的返回值改成测试值，几行Python脚本就能搞定，这在Fiddler里实现起来就麻烦得多。

2.3 安全测试方向与命令行抓包工具

安全测试领域，免费工具的首选就是Burp Suite Community Edition。它和Fiddler一样属于HTTP调试代理，但侧重点完全不同。Burp Suite自带爬虫、扫描器、Repeater（请求重放）、Intruder（暴力枚举）等一系列功能，做渗透测试、接口安全性验证的时候几乎是标配。

Burp Suite Community Edition免费版虽然去掉了主动扫描和一些高级功能，但核心的拦截、重放、修改请求都保留着，学习Web安全完全够用。我身边很多做安全和测试的朋友，都是先从Community版练手，后面有需要再上专业版。

命令行场景也有一把经典工具叫tcpdump，Linux和macOS自带，Windows上可以通过WSL使用或者装WinPcap。它的用法非常极简，比如sudo tcpdump -i eth0 port 80就是监听80端口的流量。日常排查服务器网络问题、确认某个端口有没有数据包进来，tcpdump比Wireshark更好用，因为它不依赖图形界面，还能直接在服务器上跑。

为了让你对这几款工具的选择有个直观认识，我把它们的核心属性整理进一张表：

3. 按场景选型：从Web到APP的抓包方案

3.1 Web端与浏览器调试

网页调试是最基础的场景。其实前端同学用浏览器自带的开发者工具（按F12）就能完成90%的调试工作，Network面板能看到所有请求的URL、状态码、耗时、请求头和响应体，还能直接复制为cURL命令，根本不需要额外装抓包工具。

但是浏览器开发者工具有一个盲区：它看不到非浏览器发起的流量。比如你在终端里执行一段Python代码请求某个接口，或者某个后台进程在偷偷调接口，浏览器控制台里永远看不到这些流量。这时候就需要系统级的抓包工具。在Windows上打开Fiddler，在macOS上启动mitmproxy，所有经过本机的HTTP流量都会被截获，不管是浏览器、命令行、还是某个服务进程。

我自己的习惯是：日常调接口用浏览器F12足够，但凡是遇到“这个请求到底是不是这个程序发出来的”这种问题，就直接开Fiddler看全局流量，省得猜来猜去。

3.2 移动端与小程序抓包

手机APP和小程序的抓包是另一个高频需求。基本思路是：让手机和电脑连同一个Wi-Fi，手机上的Wi-Fi代理指向电脑的IP和抓包工具的监听端口，然后把抓包工具的根证书安装到手机里。这样APP里的HTTPS请求就会被电脑上的抓包工具解密看到。

这里有一个现实问题：现在手机APP很多都做了防抓包处理，比如校验证书指纹、检测代理设置等。如果你的目标是调试自己开发的APP，那没问题，开发阶段关闭这些校验就行。如果你想看第三方APP在调什么接口，技术上有多种手段，但一定要留意合规性，只对自己的设备、自己有权测试的应用进行操作。

模拟器场景也很常见，比如在Android模拟器里调试应用。有人用网易MuMu模拟器配合Fiddler抓包，原理和真机一样，只是把Wi-Fi代理设置换成了模拟器里的设置。实际踩坑点在于：模拟器默认的Wi-Fi网络经常无法直接修改代理，需要长按网络名称手动修改代理配置，这个我在后面实操部分会细说。

小程序抓包的逻辑和APP完全一致。微信开发者工具本身就有调试面板，但如果要看正式版小程序在手机上的真实请求，还是得走“手机代理+证书信任”这条路。抓包工具选Fiddler、Charles还是mitmproxy都可以，关键是证书要安装到位。

3.3 流媒体与在线视频抓包

“网课视频抓包工具”“视频地址抓取”这类搜索热度一直很高，本质上是想通过抓包拿到在线视频的播放地址或者媒体流文件。这个场景里，需要的不是抓包本身，而是分析媒体流的能力。

一个在线视频页面通常经历了这样的流程：浏览器先请求一个HTML页面，页面里的JavaScript会去请求一个视频清单文件。常见的清单格式是HLS的m3u8，里面写的不是视频数据本身，而是一串ts分片文件的地址，播放器按顺序下载这些分片就能播放完整视频。用抓包工具抓到m3u8地址后，再用下载工具把分片拼接起来，就能得到完整视频。

用Fiddler或mitmproxy都能抓到这些请求和响应，过滤条件也很简单，直接在抓包结果里搜索m3u8或者ts关键词。但我要特别提醒一句：在线视频的版权归属很明确，抓取媒体流的技术本身是中立的，但如果你是去下载没有权限分发的网课内容，那就有侵权风险。安全合规的做法是：只对自己的内容、自己购买的素材、或者明确允许下载的视频源进行抓包分析，用在学习播放器开发、CDN调试这些正当用途上。

3.4 USB抓包与蓝牙抓包

电脑上除了网卡流量，还有USB设备和蓝牙通信的数据流，这两类也有专门的抓包方案。

USB抓包最常用的工具是USBPcap，这是Windows平台的免费USB抓包工具，安装之后会作为Wireshark的一个抓包接口出现。你在Wireshark里选择USBPcap接口，就能捕获USB设备与主机之间传输的数据。常见应用场景包括：分析USB键盘输入、调试USB摄像头、排查USB设备驱动异常。操作上比网络抓包稍麻烦，因为USB流量包含大量底层描述符数据，过滤表达式得配合usb.transfer_type这类条件来筛选。

蓝牙抓包的门槛更高一些。常规做法是使用蓝牙嗅探硬件，比如Nordic的BLE Sniffer板子，配合Wireshark的蓝牙解析插件，能捕获低功耗蓝牙的数据包。也有纯软件的方案，比如Android系统上开启Bluetooth HCI snoop log，把蓝牙日志存成文件再用Wireshark分析。这个方向偏硬件和底层，普通开发者用得少，但如果你是做蓝牙外设开发，这套组合几乎是标配。

坦白说，USB和蓝牙抓包属于长尾需求，普通人日常开发中用得不多。我在这里列出来，主要是因为搜索“USB抓包工具哪个最好用”“蓝牙抓包工具”的人确实不少，先给出正确答案，避免大家走弯路。

4. 新手实操：三套工具从零跑通

4.1 Wireshark：第一次抓包就这么简单

Wireshark的安装过程不多说，官网下载对应系统的安装包，一路下一步就行。启动后你会看到网卡列表，这是整个操作里最需要留意的一步：如果同时有有线网卡、无线网卡和虚拟网卡，得选对真正在传输数据的那个。

判断方法很笨但很有效：双击某个网卡开始抓包，然后用浏览器随便打开一个网站，看界面里有没有不停跳动的新数据包。如果有，说明就是它。如果等了十秒一条包都没有，多半选错网卡了。

选对网卡后，你马上就能看到满屏的数据包，这时候不要慌，抓住一个核心操作：过滤。在顶部的过滤栏里输入http，按下回车，列表就只剩下HTTP请求和响应了。浏览器再访问一次网页，你会看到每次请求都对应着两三条记录，请求行显示GET /index.html HTTP/1.1，响应行显示HTTP/1.1 200 OK。

想更精确一点，输入http && ip.addr == 192.168.1.10，就只看某个IP相关的HTTP流量。想看TCP握手过程，输入tcp.flags.syn == 1。这些都是我每天不知道要敲多少遍的过滤条件。

如果抓到一半发现数据包太多，可以先点击左上角的红色方块停止抓包，再慢慢分析。分析完成后，记得把文件保存为pcap格式，后续排查问题或者发给同事协作分析都非常方便。

4.2 Fiddler：解密HTTPS请求的详细步骤

Windows上装好Fiddler Classic之后，第一步不是直接抓包，而是先开启HTTPS解密功能。默认情况下Fiddler只解密HTTP流量，HTTPS显示的全是加密乱码。打开菜单Tools -> Options -> HTTPS，勾选Decrypt HTTPS traffic，如果弹窗提示安装证书，一路确认即可。

接着在同一个配置页里确认Capture CONNECTs也是勾选状态，这一步能让Fiddler正确捕获通过HTTPS协议建立的连接。设置完成后，重启Fiddler让配置生效。

现在打开浏览器随便访问一个HTTPS网站，回到Fiddler界面，左侧列表已经能看到一条条请求记录了。点击任意一条，右侧上半部分是请求的Headers、Cookies和请求体，下半部分是服务器的响应内容。如果想看原始格式，切换到Raw标签页，请求报文和响应报文的原始文本都在这里。

手机端抓包的配置流程是这样的：先确保电脑和手机在同一个局域网，然后在电脑命令行执行ipconfig查看本机IP，记下IPv4地址。Fiddler默认监听8888端口，所以手机上的代理地址填192.168.x.x:8888。设置好代理后，手机浏览器访问http://192.168.x.x:8888，页面会显示Fiddler的证书下载页，点击下载并安装证书到手机上。

Android模拟器里的操作逻辑相同。以网易MuMu模拟器为例，打开设置里的Wi-Fi界面，长按当前连接的Wi-Fi网络，选择“修改网络”，展开高级选项，把代理改成手动，主机名填电脑IP，端口填8888。接着在模拟器浏览器里访问代理地址下载证书。这里最容易踩的坑是MuMu自带浏览器下载证书后，安装证书时需要先设置一个锁屏密码，否则系统会拒绝安装。

4.3 mitmproxy：命令行与脚本化抓包

macOS和Linux用户如果没有Windows虚拟机，Fiddler指望不上，用mitmproxy是最顺手的方案。安装只需一条命令：

pip install mitmproxy

启动也极其简单，在终端执行：

mitmweb

mitmweb会启动一个Web界面并且默认监听8080端口。这个时候把手机或浏览器的代理指到电脑IP:8080，然后到手机浏览器访问http://mitm.it，按页面提示下载对应的证书，安装信任即可。

和Fiddler最大的不同是，mitmproxy的设计哲学是“一切皆可脚本化”。它的官方文档里给了很多Addon脚本示例，我提供一个最基础的修改响应内容的脚本作为参考：

from mitmproxy import http def response(flow: http.HTTPFlow) -> None: if "api.example.com" in flow.request.pretty_host: flow.response.text = flow.response.text.replace("prod", "dev")

把这段代码保存为modify.py，然后用下面的命令启动：

mitmweb -s modify.py

这样所有经过mitmproxy的API请求，只要域名是api.example.com，响应里的prod就会被替换成dev。做开发联调、Mock数据、接口回归测试的时候非常好用。相比之下Fiddler也有这个能力，但写脚本和调试脚本的体验远不如mitmproxy顺畅。

5. 高频问题与排查技巧

5.1 抓不到包的几个原因

“为什么我打开抓包工具，但浏览器里的请求一条都看不到？”这是我被问过最多的问题，没有之一。排查思路基本固定，按顺序检查这几处：

第一，抓包工具是不是真的在运行。Fiddler和mitmproxy这类HTTP调试工具，必须先启动，再把客户端流量指过去。如果只是开个界面没开始监听，自然什么都抓不到。第二，代理设置是否正确。手机抓包时，Wi-Fi代理的IP和端口必须和电脑上抓包工具的监听地址一致，任何一位填错就全废。第三，证书有没有安装信任。HTTPS请求如果证书不受信任，客户端会直接断开连接，工具的日志里会看到TLS handshake failed之类的报错。第四，是不是抓错了网卡。Wireshark场景下，选错接口是最常见的失误，判断方法就是我前面说的“开网页看列表有没有新包”。

我还遇到过一种隐蔽情况：有些安全软件会主动屏蔽本机代理，导致Fiddler和mitmproxy无法正常接管流量。如果基础项都检查了还是抓不到包，把安全软件暂时退出再试一次，往往立竿见影。

5.2 证书与HTTPS显示乱码

证书类问题在抓包初始阶段高频出现。常见现象有两种：一是装了证书后浏览器还是提示不安全，二是抓包工具里能看到请求但响应内容是乱码。

浏览器提示不安全，大概率是证书信任范围不对。Windows和macOS的证书信任操作略有不同，但核心逻辑一致：必须把抓包工具的根证书安装到“受信任的根证书颁发机构”或“系统”级别的信任区，只安装在当前用户的“个人”证书里是无效的。Android手机上有时候必须手动去“安全 -> 加密与凭据 -> 安装证书”里操作，单纯从浏览器下载安装可能只对浏览器生效，对其他APP无效。

响应内容乱码的原因则有两个：一是没开启HTTPS解密，流量是以TLS加密形态展示的，看起来像乱码其实是正常的；二是响应内容是Gzip或Brotli压缩格式，抓包工具没自动解压。Fiddler和mitmproxy一般都能自动解压Gzip，遇到无法解析的情况，可以尝试在工具里关闭压缩，或者用Wireshark手动查看。

5.3 性能和兼容性问题

抓包工具开着的时候，浏览器打开网页明显变慢，这种情况太正常了。原因是所有流量都被截获、解析、展示，CPU和内存占用都会上去。缓解办法有三个：一是一次只抓需要的流量，能用过滤表达式就别全量抓取；二是抓完立刻停止，别一直挂在后台；三是Wireshark里可以勾选“Only capture packets that pass the filter”，让不相关的包压根不进内存。

兼容性方面，Android 7.0及以上系统有一个“默认不信任用户证书”的改动，导致很多APP的HTTPS流量即使装了证书也抓不到。这个限制主要影响的是调试第三方APP，调试自己开发的APP时，可以在AndroidManifest里的networkSecurityConfig中声明信任用户证书，或者在debug构建中自动允许。具体配置不展开，但遇到“同一个小程序在Android手机上抓不到包”的问题，优先往这个方向上想。

还有一个容易被忽略的点：模拟器和真机的代理设置可能不同。不同版本的Android系统、不同厂商定制系统，Wi-Fi设置入口差异很大，搜“XX手机抓包代理怎么设置”不如直接在设置里逐个找“代理”关键词来得快。养成自己动手找设置项的习惯，能省下大量踩坑时间。

6. 实操心得与合规底线

工具清单和操作步骤聊完了，说点我自己的体会。

刚开始学抓包的时候，我总想着把所有工具都装上，恨不得每一个都试一遍。后来发现真正高频使用的其实就两样：日常调试用Fiddler或mitmproxy，排查底层问题用Wireshark。其他工具放在硬盘里吃灰的时间居多。工具不在多，把一两把趁手的用到极致，远比“装了一堆都不熟”更有价值。

第二点体会是，抓包之前一定要想清楚自己要找什么。没有目标地乱抓，面对满屏的数据包很容易迷失。我现在的习惯是开工前先写一句话，比如“找出登录接口的请求参数”“确认前端是否把token放进了请求头”，然后带着问题去抓包，效率高很多。

最后必须认真说一句：抓包技术本身是中立的，但使用场景有边界。别去抓取别人设备的流量，别去截获未经授权的账号密码和敏感信息，别用抓包工具做侵害他人权益的事。做开发和测试的人，本事越大，越要清楚什么该碰、什么不该碰。把抓包用在调试自己的项目、排查自己的系统、学习网络协议这些正当方向上，它就是你工具箱里最锋利的一把刀。