全平台免费抓包工具详解：Wireshark、Fiddler与mitmproxy场景化选型

抓包这件事，听起来像黑客专属技能，其实早就成了后端开发、前端联调、移动端排障、协议分析甚至硬件调试的日常刚需。Windows 上有人双击打开 Wireshark 就蒙了，满屏花花绿绿的包不知道看哪个；macOS 用户到处找 Charles 的破解版，结果发现新版早就不免费了；还有一群做微信小程序、USB 外设、蓝牙 IoT 调试的朋友，满世界搜“某某场景抓包工具哪个最好用”。这篇文章我打算按场景把所有主流的免费全平台抓包工具彻底捋一遍，不光是报菜名，还会把每个工具的适用边界、坑点、和它背后的抓包原理讲清楚，保证你看完能直接对号入座选对工具。

• 如果你是后端工程师，想排查接口超时和 TCP 重传，往下看 Wireshark 部分。
• 如果你是前端/客户端开发，要调 HTTPS 接口和微信小程序请求，直接跳到 Fiddler、mitmproxy 那几节。
• 如果你搞硬件、驱动、蓝牙 IoT，最后一章讲 USB 和蓝牙怎么抓包，这部分全网讲得少，我尽量写细。

文章的所有结论都来自我本人实际用过的经验，免费优先，能不花钱解决的坚决不花钱。

1. 抓包之前，先搞清楚协议栈“三层”决定了你选哪类工具

很多人上来就问“哪个抓包工具最好用”，这个问题其实没法直接回答，因为抓包工具按工作原理分成完全不同的几类，各抓各的包。选错工具等于拿望远镜看细菌，不是工具不行，是压根用错了维度。

1.1 你平时说的“抓包”，可能不是同一个“包”

我见过太多人把抓包简单理解为“看看数据包里有什么”，但实际上至少分三层：

第一层：网卡数据包（L2-L4）。这一层抓的是网卡上真实流动的以太网帧、IP 包、TCP/UDP 报文。抓包工具通过底层驱动（Windows 上是 Npcap/WinPcap，Linux 上是 AF_PACKET，macOS 上是 BPF）把网卡收到的原始二进制流量复制一份给你看。这一层的代表性工具是 Wireshark、tcpdump。

第二层：HTTP/HTTPS 会话（L7 应用层）。这类工具本身常驻一个本地代理，把应用的流量先转发到代理上，代理再转到目标服务器，所以它能直接看到完整的请求头、请求体、响应体。代表性工具是 Fiddler、Charles、mitmproxy。它们和 Wireshark 抓的“包”完全是两个视角——Wireshark 也能看到 HTTP 报文，但它是从 TCP 流里重组出来的，操作体验远不如专门的应用层代理工具。

第三层：专用总线/协议层。比如 USB 抓包、蓝牙 HCI 抓包、串口抓包。这层的工具通常会绑定专用的硬件嗅探器（比如 USB 协议分析仪、蓝牙 Sniffer），而且抓到的不是 IP 报文，而是总线上的传输描述符、HCI 事件、链路层数据包。纯软件能做的比较有限，但确实也有几条路可以走。

1.2 三层定位决定了工具选型

你只要搞清楚一个问题——你关心的数据在哪一层产生，选型就完成了一半。

我举个具体例子：你在电脑上用浏览器访问一个网页，发现页面加载很慢。如果怀疑是后端接口响应慢，那应该用 Fiddler 看 HTTP 请求耗时；如果怀疑是网络本身丢包、延迟大，那应该用 Wireshark 看 TCP 握手时间、是否有重传；如果怀疑是 DNS 解析有问题，Wireshark 里也能直接过滤 DNS 报文。同一个现象，三种排查方向，对应两个工具，不冲突。

另外还有个容易踩的盲区：很多人以为 Fiddler 和 Wireshark 装一个就行，其实它们经常需要配合使用。Fiddler 擅长看业务数据，Wireshark 擅长看网络链路状态。后面第 6 章我会专门讲一次真实的排查案例，演示两者怎么打配合。

所以，别迷信“某个工具最牛”，最关键的是你先定位自己工作在协议栈的哪一层。下面的内容我按层级来展开介绍每个主流免费工具。

2. 网卡层面的通用抓包主力：Wireshark 的安装配置与上手要点

Wireshark 是整个抓包工具生态里当之无愧的一哥，免费、开源、全平台（Windows/macOS/Linux），支持几百种协议解析，从 TCP/IP 到 Modbus、MQTT、蓝牙 HCI 都能看。它的前身叫 Ethereal，2006 年改名后一直活跃到现在，可以说是网络分析领域的“瑞士军刀”。

2.1 安装时最容易忽略的驱动选择

Wireshark 在 Windows 上抓包的核心依赖是 Npcap（新版已经不再推荐 WinPcap）。安装 Wireshark 的时候，安装向导会附带安装 Npcap，这一步大多数人直接一路 Next 过去，但里面有隐藏雷。

Npcap 安装时有两个关键选项：“Support raw 802.11 traffic”和“Restrict Npcap to admin users only”。

• 如果你做无线网卡监听，需要勾选“Support raw 802.11 traffic”，否则 Wireshark 抓不到 Wi-Fi 数据帧里的 802.11 管理帧，只能看到普通 IP 报文。
• “Restrict Npcap to admin users only”默认是勾上的，意味着非管理员用户打不开 Wireshark 抓包。如果你在团队环境里用普通域账号工作，建议取消这个勾，否则每次抓包都得右键管理员运行，非常烦。

macOS 和 Linux 上装 Wireshark 相对省心，安装包会自动调用 BPF 或 libpcap。Linux 用户还需要注意把当前用户加入wireshark用户组，否则非 root 无法访问抓包接口，这是很多人刚装完发现“双击网卡没反应”的常见原因。

2.2 两个过滤器别搞混：抓包过滤器 vs 显示过滤器

Wireshark 新手最懵的就是它有两个过滤器输入框，功能完全不同。

抓包过滤器（Capture Filter）在抓包开始前设置，作用是从源头只捕获符合条件的包，不满足条件的直接丢弃。语法是 libpcap 过滤表达式，比如：

# 只抓主机 192.168.1.100 的流量 host 192.168.1.100 # 只抓 80 端口流量 tcp port 80 # 抓 HTTP 和 DNS tcp port 80 or udp port 53

显示过滤器（Display Filter）是在已经抓到的一大堆包里面做筛选，语法是 Wireshark 自己的协议字段表达式，灵活得多：

# 只看 HTTP 请求 http.request # 只看源 IP 是 10.0.0.5 的 TCP 流量 ip.src == 10.0.0.5 && tcp # 只看 TCP 重传统计 tcp.analysis.retransmission

我的建议是：日常基本不用抓包过滤器，全量抓下来再用显示过滤器慢慢筛就行。因为抓包过滤器一旦设置错误或者漏掉条件，流量没抓进来就得重新来；而显示过滤器随时可以改，对数据没有任何损失，最多就是文件大一点，对现在的磁盘来说完全不是问题。

2.3 看 HTTPS 内容时，Wireshark 的 SSLKEYLOGFILE 用法

这里必须说清楚一个误区：Wireshark 本身并不能直接解密 HTTPS 流量。它能看到 TCP 报文里传输的是密文，但内容是无法直接阅读的。想要看到明文 HTTP 请求和响应，有两个办法：

1. 用 Fiddler/mitmproxy 这种中间人代理（MITM），证书由代理工具下发，流量被解密后转发。
2. 配置环境变量SSLKEYLOGFILE，让浏览器或支持该特性的程序把 TLS 会话密钥写入指定文件，Wireshark 读取密钥文件后解开对应会话。

第二种方式在网络诊断和协议分析场景非常实用，操作步骤大概是：

• 在系统环境变量里新建SSLKEYLOGFILE，路径指向一个可写的文件，比如C:\sslkeys\keys.log。
• 重启浏览器，确保变量生效。
• 打开 Wireshark，进入“首选项 -> Protocols -> TLS”，在(Pre)-Master-Secret log filename里填入同样的路径。
• 重新抓包，会发现原来显示为 “Application Data” 的 TLS 流量变成了可读的HTTP/2明文。

这个技巧做全栈开发调试时极其有用，尤其适合排查浏览器里某个前端请求的完整 HTTP 头。注意 Fiddler 自带解密，但那是在 Fiddler 里看；如果你想在 Wireshark 里结合 TCP 层信息一起看，只能用 SSLKEYLOGFILE 这条路。

3. HTTP/HTTPS 应用层抓包：Fiddler Classic 与 mitmproxy 的实战选择

如果 Wireshark 负责“看网络链路”，那应用层代理工具负责“看业务数据”。这一节我重点讲 Fiddler Classic 和 mitmproxy，因为 Charles 现在只有 30 天试用期，严格来说不算免费工具，不再展开只提结论。免费场景下，真正干活的是这两个。

3.1 Fiddler Classic：Windows 平台入门的首选，但要注意“免费版”的身份

Fiddler 分两个产品线：Fiddler Classic（经典版）和Fiddler Everywhere。Classic 是免费的，只能在 Windows 上跑，.NET Framework 的界面，现在 Progress 公司已宣布经典版停止更新，但它依然能用，而且功能完整。Everywhere 是跨平台付费产品，有试用期，不是本文讨论的免费范畴。

Fiddler Classic 的核心定位是HTTP/HTTPS 调试代理。安装后默认监听127.0.0.1:8888，它会自动修改系统代理设置，让浏览器和不少桌面应用的请求都经过它。你打开 Fiddler 后能看到左侧会话列表里刷出所有 HTTP 请求，点击任意一条，右侧能看完整的请求头、响应头、Cookies、JSON 或表单数据。这种体验比 Wireshark 舒服太多了，因为不需要懂协议字段，所见即所得。

我第一次用 Fiddler 抓微信小程序时，就是靠这个列表定位到小程序启动时请求的十几个接口，把其中几个高延迟请求单独拎出来做了性能分析。步骤是：先打开 Fiddler，再打开小程序开发者工具，请求直接全部出现在列表里，连切换都不用。

Fiddler 最实用的三个功能：

• 断点（Breakpoints）：在请求发出前、响应返回前设置断点，手动修改请求参数或响应内容再放行。这在模拟后端异常返回时非常方便，前端想验证“接口返回 500 时页面怎么展示”，直接改响应状态码就行。
• 弱网模拟（Simulate Modems）：菜单里自带 256kbps/2G/3G 速度档位，能在本地复现移动网络卡顿。新版在工具栏Rules -> Performance -> Simulate Modems可快速开启。
• AutoResponder：把某个域名或路径的请求直接映射到本地文件或指定响应，免启动后端服务也能联调前端。

3.2 mitmproxy：跨平台、脚本能力强，接口自动化测试神器

mitmproxy 是一套命令行代理工具，支持 Windows/macOS/Linux，免费开源，本质上是 Python 写的一个中间人代理。它默认监听8080端口，使用时把手机或程序的代理指向电脑 IP 的 8080 端口，流量就会经过它。

很多新手看到 mitmproxy 是命令行界面就劝退了，这其实是个误解。mitmproxy 不只是终端里的 TUI 界面，它还附带一个基于 Web 的界面mitmweb，启动后浏览器访问http://127.0.0.1:8081就能像 Fiddler 一样点选查看请求和响应。如果你的机器上没有图形桌面环境（比如开发服务器、Docker 容器），还能用纯终端模式mitmproxy，按键交互式查看。

mitmproxy 最狠的地方在于Python 脚本扩展。它提供了一套成熟的 API，可以写脚本拦截请求、修改响应、筛选特定接口。比如我想让某个测试账号在 App 里表现出“VIP 用户”，就写过 5 行脚本把响应中的vip_level字段强制改成 3。这在 Fiddler 里也能做（Fiddler 支持 C# 脚本），但 mitmproxy 的 Python 生态对新手的友好度明显更高。

安装非常简单：

pip install mitmproxy

启动 Web 界面：

mitmweb -p 8080

手机连接 Wi-Fi，代理指向电脑 IP 的 8080 端口，访问http://mitm.it安装证书后，HTTPS 请求就能明文看到了。整个过程比 Fiddler 在手机上配证书还要顺滑。

3.3 全平台用户直接看这里：Fiddler、mitmproxy、Charles 的取舍

很多人纠结这三个工具到底选哪个。我给一个最简单的选择逻辑：

• 你在 Windows 上、主要做 Web 和小程序调试、想要图形界面的点选操作 →Fiddler Classic，免费够用。
• 你在 macOS/Linux 上，或者需要自动化脚本批量处理请求 →mitmproxy，免费且跨平台。
• 你非常在意 UI 美观度且只差临时用几天 → 可以尝试 Charles 试用版，但不是长期方案。

我自己的主力环境是 macOS，早些年用 Charles，后来因为它收费就彻底转向 mitmproxy + 偶尔开 Fiddler（跑到 Windows 虚拟机里用）。实测下来，配合 mitmweb 的 Web 界面，日常调试体感不输 Charles，而且写脚本做自动化回归时效率反而是 Charles 的好几倍。

4. 移动端与小程序抓包的完整链路：从证书安装到 SSL Pinning 处理

热搜词里“微信小程序抓包工具”搜索量非常高。小程序抓包本质上就是移动端 HTTP 抓包，但它有几个坑点非常典型，单独拉出来讲。

4.1 手机抓包的环境准备工作

移动端抓包有两种方式，一种是把手机和电脑接入同一局域网，把手机 Wi-Fi 代理指向电脑；另一种是用 USB 连接，把手机流量通过 USB 网络共享给电脑，但代理配置仍然走 Wi-Fi 的 IP 比较常见。我现在用最多的模式是：手机开飞行模式 -> 打开热点 -> 电脑连手机热点 -> 手机代理指向电脑。这样确保所有流量都在一台设备上，避免办公室局域网限制。

以 Fiddler 为例，开启Tools -> Options -> Connections -> Allow remote computers to connect，然后手机浏览器访问http://电脑IP:8888，下载并安装 Fiddler 的根证书，HTTPS 流量就可以正常解密了。mitmproxy 的流程类似，访问http://mitm.it下载对应系统的证书即可。

4.2 Android 7.0 以后，证书信任机制是最大的坑

从 Android 7.0（API 24）开始，应用默认不信任用户安装的 CA 证书，只信任系统证书。这导致你走上面流程装完证书后，浏览器和部分应用能正常抓包，但很多 App 和小程序里的 HTTPS 请求直接报“证书校验失败”或“网络异常”。

解决办法有几条：

• 低版本 Android 机型：如果测试机还是 Android 6.0 及以下，用户证书可以直接被 App 信任，这也是很多人建议“抓包找个老手机”的原因。
• Root 后把证书装进系统证书目录：先将证书转换成系统认可的哈希名称，adb remount后放到/system/etc/security/cacerts/，这种办法对大多数 App 有效，但仍对抗不过 SSL Pinning。
• 使用支持导入系统证书的 ROM/模拟器：比如部分国产 ROM 的开发者选项提供了“将用户证书并入系统证书”的功能，实测对微信小程序调试有效。

微信小程序的开发者工具本身也提供了抓包面板，但它更适合看前端发起的请求。如果你要分析的是小程序访问后端时证书是否被中间人拦截，建议用真机 + Fiddler/mitmproxy 抓。

4.3 遇到 SSL Pinning（证书锁定），纯软件方案基本无解

不少金融类、大厂 App 会做 SSL Pinning，就是客户端内置了服务器的公钥指纹，代理证书即使被信任也会被拒绝。遇到这种场景，纯软件抓包是没有通用解法的，除非能 hook 客户端的证书校验逻辑——这已经超出“免费抓包工具”的范畴，属于逆向和 Hook 领域了。

我的经验是：遇到 SSL Pinning 别在抓包工具上死磕，先确认是不是自己团队的 App。如果是自己团队开发的，让开发在 Debug 包临时关闭 Pinning 或者加白名单。如果是第三方 App，技术上可以研究 Frida/Xposed Hook，但这涉及合规和安全边界，不建议公开讨论。回到抓包本身，能够处理 HTTPS 就是不 Pinning 的应用，或者你能拿到的测试包。

5. 热搜词里的特殊场景：USB 抓包、蓝牙抓包和串口抓包

搜索引擎的热词里挂着“usb抓包工具哪个最好用”“蓝牙抓包工具”，说明相当一部分人做的是硬件、驱动、IoT 方向。这几个场景的“包”完全不是 IP 报文，选型逻辑跟前面完全不同。

5.1 USB 抓包：Windows 用 USBPcap，Linux 内核自带 usbmon

USB 抓包主要分析设备与主机之间的 USB 控制传输、批量传输和中断传输，典型应用是调试 U 盘枚举失败、自定义 HID 设备上报异常、USB 摄像头带宽不足这类问题。

Windows 上目前最主流的免费 USB 抓包方案是USBPcap，它能和 Wireshark 直接集成。安装 USBPcap 后，打开 Wireshark 会看到多个以USBPcap1、USBPcap2命名的接口，每个对应电脑上的一个 USB 控制器，选择对应接口就能开始抓包。抓到的包能看到 USB 的 URB 请求块，包括传输方向、端点号、传输类型、数据长度和数据内容。需要注意，USBPcap 对 USB 3.0 的支持依赖主板和控制器的兼容性，实测部分主板抓 3.0 设备时只能看到 2.0 的流量，需要改用主板后置 USB 3.0 口或专用分析仪才稳定。

Linux 下更简单，内核原生支持 usbmon，无需安装额外驱动。只需：

# 加载 usbmon 模块 sudo modprobe usbmon # 查看可用 USB 总线编号 lsusb

然后在 Wireshark 里选择usbmonN对应的接口抓包即可。这种方式抓 USB 全量流量完全免费且数据非常真实，比买几万块的 USB 协议分析仪更轻量，只是缺少时间戳精确到纳秒和高级解码功能。

5.2 蓝牙抓包：Ubertooth 与 nRF Sniffer，配合 Wireshark 分析

蓝牙抓包分两种：BR/EDR（经典蓝牙）和 BLE（低功耗蓝牙）。免费可玩的方案主要是针对 BLE。

Ubertooth One是一个开源硬件项目，硬件成本几百块，配合 Ubertooth 固件和 Wireshark 可以抓 2.4GHz 频段的 BLE 广播包和连接数据包。它的优点是开源、价格便宜、社区资料多；缺点是只能抓 BLE，对经典蓝牙不支持，而且抓连接事件时需要提前知道跳频序列，实操中有一定门槛。

nRF Sniffer是 Nordic Semiconductor 提供的软硬件方案，逻辑上就是一块 nRF52840 Dongle（百元左右），刷上 Sniffer 固件后，用 Wireshark 的 nRF Sniffer for BLE 插件就能抓 BLE 所有链路层数据，包括连接事件、广播包、LL Control PDU，还能关联解密（如果知道 LTK）。我实际用过这个方案调试 BLE 设备的断连问题，一次就锁定了是连接参数更新请求被设备拒绝导致，效率很高。对比商业化蓝牙协议分析仪（动辄几万块），nRF Sniffer 的输出虽然没那么精致，但完全够用了。

5.3 串口抓包：别忘了一个基础方法

做嵌入式开发的人经常要抓串口日志，严格来说这不是抓包，但逻辑类似——分析 UART 上的通信内容。Windows 下可以直接用 AccessPort、ComMonitor 这类免费的串口监听工具；Linux 下的做法是 socat 重定向串口数据到虚拟串口对，或者直接用strace跟踪 read/write 系统调用。这个相对简单，就不展开写了。

6. 场景化选型：一张表找到最适合你的免费抓包工具

最后把全文的工具收拢成一个场景化对照表，方便你收藏后直接按需选用。

按这个表选型，基本能覆盖你 90% 的抓包需求。

6.1 一次真实排查里，Wireshark 和 Fiddler 是怎么搭配的

去年我调试过一个 PC 客户端上报问题时数据丢失的情况。用户反馈软件偶尔上传失败，前端看到的是接口 504。我同时开了 Fiddler 和 Wireshark 抓包，发现 Fiddler 里接口确实 504，但 Wireshark 里看到 TCP 层有大量零窗口（Zero Window）和重传。零窗口说明接收方缓冲区满了，应用层没及时读取数据，导致 TCP 背压。问题最终定位到客户端的一个 SDK 在 Windows 更新后不再自动处理大响应分片，缓冲区越积越大。如果只开 Fiddler，只能看到“504”这个现象，根本不会知道是底层网络栈背压导致；如果只开 Wireshark，也要花大量时间重组 HTTP 才能定位是哪个接口。两个工具互相印证，很快就把链路层的异常锁定了。

这就是我强调的“按层级选工具，按需要做组合”的核心价值。

6.2 抓包合规与边界提醒

最后补一个容易被忽视的点：抓包可以抓自己的设备、自己开发的 App、自己所在网络的流量，但抓取他人设备、破解他人应用、绕过安全防护的抓包行为可能涉及法律风险。日常开发调试中，务必在授权范围内操作。尤其是 SSL Pinning 绕过、注入脚本这类手段，仅建议用于自己团队的应用和已获授权的测试环境。

几个高频踩坑问题的快速排查备忘

1. 装完 Wireshark 打不开网卡接口→ Windows 加用户组或管理员运行，Linux 加wireshark用户组并重新登录，macOS 检查是否已在系统设置授权 Wireshark 访问网络接口。
2. Fiddler 抓不到 HTTPS 明文→ 检查是否已在 Fiddler 中安装并信任根证书；检查手机/浏览器是否真的走了代理；先访问 http 站点确认代理通则再排查证书。
3. 手机 App 抓包失败且报证书错误→ 优先确认应用是否信任用户证书，Android 7.0 以上需要系统证书或 Root 方案；实在不行找团队开 Debug 包。
4. mitmweb 打开后请求列表为空→ 确认手机代理 IP 和端口是否正确，确认防火墙放行了 8080 端口，确认手机和电脑在同一个局域网。
5. USB 抓包看不到数据→ 先确认 Wireshark 里选的是带USBPcap标识的接口而不是普通以太网接口，并且插拔设备时抓包列表有反应；如果毫无反应，换 USB 口或换 USB 控制器节点。
6. 蓝牙 Sniffer 抓不到连接包→ BLE 连接事件是跳频的，需要提前知道连接参数才能跟包，纯广播包抓不到连接态数据是正常现象；如果调试自己的 BLE 设备，代码里把连接间隔写长一点会更好抓。

这个排查备忘是我自己把博客评论区高频问题汇总后整理的，遇到问题时直接对着查，能省下大量搜索时间。

抓包工具选型永远没有一个“万能答案”，但我可以负责任地讲一句：免费工具已经覆盖了绝大多数个人开发者和中小企业能用到的场景，从 Wireshark 到 Fiddler、mitmproxy、USBPcap、nRF Sniffer，这套组合已经帮我在各种疑难杂症面前站稳了脚跟。你不需要一开始就把所有工具都学会，先根据自己当前最常遇到的场景选一个主力，把它用得滚瓜烂熟，再按需扩展其他的，这是最务实的路径。