做开发这些年我至少见过十几次这种场景前端和后端对着一个接口吵得不可开交前端说参数传了后端说没收到最后我打开抓包工具一看某个header不知道被哪层代理吞了真相一目了然。还有一次排查线上超时看了一圈服务端日志都没问题最后抓包发现是DNS解析到了旧的IP。说实话搞网络相关的开发、测试、运维不会抓包就像修车没有万用表很多问题只能靠猜。而这几年我接触过的免费抓包工具比很多人想象中多得多覆盖桌面、移动端、USB、蓝牙甚至物联网场景原理和用法差别很大选错工具确实会走不少弯路。这篇文章就把我实际用过、目前仍然值得推荐的免费全平台抓包工具梳理一遍会讲清楚每个工具的适用边界、核心原理和使用要点再附上一些踩过坑后的排查思路。如果你正在为联调、排障、学习网络协议而找工具按场景对号入座就行。1. 抓包工具选型前先分清这四类流量不少初学者上来就问哪个抓包工具最强但真正决定工具选型的不是工具本身而是你要抓的流量长什么样。这个搞不清楚后面每一步都会很别扭。1.1 网络层抓包与HTTP层抓包完全不是一回事Wireshark 这类工具走的是旁路收包路线它依赖操作系统的抓包驱动Windows 上是 Npcap/WinPcapLinux/macOS 上是 libpcap把网卡上流过的原始数据帧一枚枚拷贝给分析器。它能看到的包是最底层的包括 TCP 三次握手、TLS 握手、DNS 查询、ICMP 包甚至 ARP 广播。优点是全、深缺点是信息密度低HTTP 请求和响应是分在很多个 TCP 段里的肉眼直接看很费劲。Fiddler、mitmproxy 这类工具走的是中间人代理路线。它会在本机开一个 HTTP 代理端口应用把流量发到代理代理再转发给真正的服务器。对应用来说它面对的是一个可控的中转站所以它天然能重构出完整的 HTTP 请求和响应能做断点、改包、重放、模拟弱网这是 Wireshark 不擅长的。缺点也明显应用如果不走代理它就什么都抓不到。打个比方Wireshark 是小区门口的监控摄像头所有进出的车都能看到但是看不清车里坐了谁。Fiddler 是门卫岗亭只看和你打交道的那些人却能查验身份证。哪个工具合适取决于你想解决什么问题。1.2 全平台到底覆盖了哪些端标题里说全平台但这个词在不同语境下含义差别很大。大多数人口中的全平台指的是 Windows、macOS、Linux 三大桌面系统这类工具相对好找Wireshark、mitmproxy 都算。但现实需求往往不止桌面。做 App 开发的人还需要抓手机上的流量可能是真机也可能是 Android 模拟器热词里就有Windows mumu 抓包工具这种具体诉求。做硬件的人还会涉及 USB 抓包、蓝牙抓包比如调试一个 USB 转串口设备或者排查 BLE 手环为什么连不上。这些场景对工具的要求完全不同有的靠软件就能解决有的必须配合特定硬件。所以我下面不会只给你一份工具清单而是按流量类型拆开讲每个场景给出对应的免费方案。2. Wireshark跨三大桌面平台的协议分析守门员Wireshark 在这个领域的位置基本等同于文本编辑器里的 Vim——你可以不用它但不能不知道它。它原名 Ethereal后来因为商标问题改名从 1998 年发展到现在是开源世界里最老牌也最活跃的网络分析项目之一。三大桌面平台全部支持并且完全免费这一点二十多年来没变过。2.1 抓包原理驱动层决定了你能不能抓到Wireshark 本身只是一个分析前端真正负责从网卡采数据的是底层驱动。Windows 上现在统一用 Npcap它和 WinPcap 是同一个血统Npcap 解决了 WinPcap 在 Win10/Win11 上驱动签名、性能、安全性方面的问题。装 Wireshark 时安装向导里会询问是否安装 Npcap我建议保持默认装好不然装完 Wireshark 也启动不了抓包接口。Linux 上没用过的话可能不太清楚Wireshark 抓包需要 root 权限或者把用户加入wireshark组才能访问/usr/bin/dumpcap。我见过不少人在 Ubuntu 上启动 Wireshark 后看不到任何网卡接口十有八九就是权限没给够。Debian/Ubuntu 下安装后执行一次sudo dpkg-reconfigure wireshark-common选是让非 root 用户可以抓包然后把自己的用户加入wireshark组重新登录一次就行。macOS 上安装时也会让你授权安装一个系统扩展否则抓包接口列表是空的。Npcap 还有一个很多人不知道的价值支持抓 loopback 回环流量。Windows 上装了 Npcap 之后Wireshark 里会出现一个Npcap Loopback Adapter或者Adapter for loopback traffic capture的接口本机进程之间通信的包也能抓到。Linux 上用any接口也能达到类似效果。这对调试本机 client-server 程序非常有用。2.2 高频操作会这几个就够用了Wireshark 的界面初看很劝退满屏的十六进制数据叠加一堆看不懂的列。但真正高频的操作实际上就三件事。第一件事是过滤。抓包开始之前最好先在显示过滤器Display Filter栏里把范围收窄。比如只想看 HTTP 通信输入http想盯某个 IP 输入ip.addr 192.168.1.100想看 TCP 重传直接tcp.analysis.retransmission。过滤器语法是 Wireshark 的核心资产会用几个常用表达式比一百个按钮都管用。第二件事是追踪流。抓到 HTTP 或 TLS 包后在一个数据包上右键选追踪流Follow→ TCP StreamWireshark 会把属于这个连接的所有数据重组成左右两栏的会话内容左边是客户端发的右边是服务端回的一眼就能看清请求头和响应体。排查接口问题的效率至少提升三倍。第三件事是导出对象。在文件 → 导出对象 → HTTP里可以把响应中携带的文件直接导出。这个功能在排查动态页面加载失败、确认图片或脚本是否被篡改时非常好用不需要额外写脚本。2.3 Wireshark 几个明显的短板虽然 Wireshark 很强但你也会很快发现它的局限。第一它对 HTTPS 内容是瞎的。如果应用走的是 TLS 加密流量Wireshark 只能看到一堆 TLS 握手包和 Application Data 密文看不到具体的 HTTP 请求内容。唯一的官方正路是配置SSLKEYLOGFILE环境变量让支持该机制的浏览器/程序导出会话密钥到文件然后在 Wireshark 的编辑 → 首选项 → Protocols → TLS里填上这个日志文件路径它才能解密当前会话。这个方法调试浏览器流量有用但对很多移动 App 无效因为 App 不会导出密钥。第二修改和重放流量非常麻烦。Wireshark 的设计目标是看不是改。虽然可以编辑包再重新发出去但操作繁琐到几乎没人会用。要改包、重放、模拟客户端行为还是得回到中间人代理类的工具。第三信息量太大反而成为负担。普通开发者面对海量数据包时很容易迷失在无关流量里。如果只是想知道我的 HTTP 请求到底发送了什么用 Wireshark 属于大炮打蚊子。3. HTTP/HTTPS 调试的免费主力Fiddler 与 mitmproxy大部分人的抓包需求集中在 HTTP/HTTPS 这一层——联调接口、看请求参数、复现线上问题、给后端甩证据。这一层最顺手的免费工具是 Fiddler 和 mitmproxy一个适合鼠标点选一个适合键盘党和自动化。3.1 Fiddler ClassicWindows 上抓 HTTP 包的经典答案Fiddler 是 Telerik 旗下的老牌工具目前分两条产品线Fiddler Classic 和 Fiddler Everywhere。Classic 版只支持 Windows现在依然免费安装包不大开箱即用适合做 Web 调试的场景Everywhere 版支持 macOS 和 Linux界面更现代但它走订阅制免费版有会话数量之类的限制。所以如果你在 Windows 上直接上 Classic 版最省心如果你在 macOS 或 Linux 上可以用 Everywhere 免费额度或者干脆用下面要说的 mitmproxy。Fiddler 的工作方式是在本机开启一个监听127.0.0.1:8888的 HTTP 代理装好之后它会自动把 IE/Chrome/Edge 的系统代理指过去所以很多新手打开 Fiddler 再刷新网页流量就出现在列表里了几乎感觉不到代理的存在。除了看请求Fiddler 最有杀伤力的功能是 Inspector 面板右侧的 Composer。你可以把抓到的请求拖进 Composer修改参数、Header、RequestBody 之后直接重放这在调试接口时是刚需。还有 AutoResponder 功能可以让指定请求不经过服务器直接返回本地预先编辑好的响应前端联调后端还没写好接口时靠它 mock 接口效率极高。这两个功能在 Wireshark 里做起来能要命在 Fiddler 里只是点两下的事。3.2 mitmproxy命令行和脚本党的跨平台选择mitmproxy 是 Python 生态里的明星项目完全开源免费三大平台都能跑。它提供三个可执行文件mitmproxy交互式终端界面能在命令行里用快捷键浏览请求像vim一样操作mitmweb启动一个本地 Web 页面浏览器里查看和搜索流量适合不习惯终端的人mitmdump纯命令行模式配合-s参数加载 Python 脚本适合自动化处理流量。启动方式很简单mitmweb --listen-port 8080然后把浏览器或操作系统的 HTTP 代理指向127.0.0.1:8080。第一次代理转发时会拦截到 HTTPS 连接但显示为不可读因为客户端还没信任 mitmproxy 的证书。浏览器打开http://mitm.it按提示下载安装根证书即可。mitmproxy 真正的强项是脚本扩展。下面这个 Python 脚本可以把响应里所有 JSON 的name字段改名在集成测试中非常实用from mitmproxy import http def response(flow: http.HTTPFlow) - None: if application/json in flow.response.headers.get(content-type, ): data flow.response.json() data[name] changed-by-mitmproxy flow.response.text str(data)用法是mitmdump -s replace_name.py。对于团队协作把这类脚本丢到 Git 仓库里大家拉下来直接复用比在 GUI 工具里手点稳定得多。3.3 HTTPS 解密的核心中间人代理和证书信任链不管是 Fiddler 还是 mitmproxy解密 HTTPS 的原理都一样工具自己生成一个根证书Root CA客户端在信任这个根证书的前提下代理就能以中间人身份同时和客户端、服务器建立两条 TLS 连接把明文请求在中间转一圈。这个机制叫 MITMMan-in-the-Middle是 HTTPS 抓包的基石。也因此能不能解开 HTTPS关键不在工具在于客户端是否信任这个根证书。Windows 上 Fiddler 装完会弹出是否安装证书的对话框macOS 上不仅要装到钥匙串还要在系统分类里把证书的信任级别改成始终信任Android 上装证书的路径和系统版本强相关iOS 上装完描述文件之后还要去设置 → 通用 → 关于本机 → 证书信任设置里手动开启信任开关。任何一步漏了结果都是同样的看到的 TLS 握手看不到明文内容。有一点必须说清楚面对 App 时很多 App 启用了 SSL Pinning证书绑定也就是客户端写死了只信任特定服务器证书或者特定公钥不信任用户的系统根证书。这种情况下代理手段会失效App 会直接断开连接或者报错。破解 Pinning 属于对抗性技术我不在这里展开。如果你是在调试自己开发的 App正规做法是在开发版本里预留关闭 Pinning 的开关或者把代理工具的证书加到networkSecurityConfig的信任列表里。调试他人应用的时候拿到授权是前提抓包工具本身是双刃剑用在哪一边取决于使用者的边界。4. 移动端、小程序与模拟器抓包的正确姿势Wireshark 抓不到手机包是我被问得最多的问题之一尤其配上Windows mumu 抓包这类关键词的时候。其实原理并不复杂只是涉及设备多有一个环节拧不对就全盘失败。4.1 真机抓包三步走同一个局域网、代理、证书让手机流量进到抓包工具里标准路径就三步。第一步保证手机和电脑连在同一个局域网里查清楚电脑的局域网 IP比如192.168.1.8。第二步在手机 Wi-Fi 设置里把代理改成手动服务器填电脑 IP端口填抓包工具的端口Fiddler 默认8888mitmproxy 默认8080。这一步之后走 HTTP 的请求已经能看到了走 HTTPS 的还看不到明文。第三步手机浏览器访问http://电脑IP:端口在工具自带的证书下载页下载并安装根证书。Android 上装证书有个容易踩的坑Android 7.0API 24开始应用默认不信任用户安装的 CA 证书只有系统证书才被信任。所以按上面的办法装完证书后普通浏览器通常没问题但很多 App 的 HTTPS 流量依然解不开这不是抓包工具的问题是系统安全策略变了。合理的做法是对于自己开发的 App在AndroidManifest.xml里配置一个networkSecurityConfig允许 debug 包信任用户证书。fiddler 官方的文档里也是这么建议的这属于正常开发调试流程。iOS 上的坑主要在最后一环装完描述文件后一定记得去设置 → 通用 → 关于本机 → 证书信任设置里把对应的根证书开关打开否则系统根本不会用这个证书去验证 TLS 连接。4.2 Android 模拟器以 MuMu 为例配置代理抓包用模拟器抓包比真机还简单一点因为模拟器和电脑天然在同一台机器上网络也通常走 NAT 模式代理地址甚至可以填10.0.2.2这类宿主机映射地址或者直接填电脑局域网 IP。MuMu 模拟器里的配置路径是打开设置 → WLAN → 长按连接的 Wi-Fi → 修改网络 → 高级选项 → 代理设置填上代理主机和端口即可。不同版本的 MuMu 菜单位置略有出入思路是一样的。证书部分模拟器本质是一个 Android 系统所以同样要装证书。推荐用adb命令把证书文件 push 到模拟器/sdcard/下再点击安装adb push mitmproxy-ca-cert.cer /sdcard/ adb -s emulator-5554 shell am start -a android.intent.action.VIEW \ -d file:///sdcard/mitmproxy-ca-cert.cer -t application/x-x509-ca-cert装完之后再用代理抓包流量就正常出现在工具列表里了。需要提醒的是用模拟器抓包通常会同时抓到很多系统后台流量的噪声记得在抓包工具里加过滤器比如只看目标域名host contains example.com不然排查问题的过程会很难受。4.3 微信开发者工具如何配合抓包工具调试小程序现在做小程序开发的人很多热搜词里小程序抓包工具微信小程序抓包工具基本就是这么来的。这里有个很自然的配合方式微信开发者工具自带网络调试能力但它展示的信息偏概要想看完整请求细节可以把它自己的请求发到外部抓包工具里。微信开发者工具的设置 → 代理设置里可以手动配置代理服务器填上127.0.0.1和 Fiddler 的8888端口或者 mitmproxy 的8080。这样开发工具里运行的小程序请求就会经过抓包工具你可以拿到完整的请求头、请求体、返回值。联调后端接口、排查登录态失效问题时这套组合基本够用。需要说明的是这种用法适用于调试自己开发的小程序未授权抓取他人小程序的接口流量既不符合平台规则也可能触碰法律红线。如果需要在真机上调试开发版或体验版小程序就在手机 Wi-Fi 里把代理配到电脑上确保开发者工具和手机在同一个局域网然后在真机预览时保持和开发者工具的 USB 调试连接这种方式也比较常见。4.4 抓不到包时按这个顺序排查移动端抓包失败不外乎下面几个原因我建议直接按顺序检查代理是否真的生效配置代理后先用手机浏览器访问一个 HTTP 页面看抓包工具里有没有流量没有流量就说明代理指向错了检查 IP 和端口。证书是否被客户端信任浏览器访问http://mitm.it看能否顺利打开如果提示证书无效重装证书并信任。抓包工具的端口是否被防火墙拦住Windows 上第一次启动 Fiddler 时Windows 防火墙通常弹窗询问是否允许监听如果点了取消手机上自然连不上。是否抓错了网卡或接口Wireshark 抓移动端流量时要确保选中的是手机接入的物理网卡通常是有线或正在使用的那块无线网卡不是虚拟网卡。目标 App 是否启用了 SSL Pinning如果上述都对但仍解不开 HTTPS且浏览器流量正常那基本可以判断是 App 的防代理或证书绑定策略在起作用。版本兼容问题Android 7.0 用户证书信任限制、iOS 新版本证书信任开关位置变化都可能导致看起来装了实际没生效。记住这个排查顺序能省掉大量盲目重试的时间。5. USB 与蓝牙抓包这些偏门场景用什么工具很多人以为抓包就是抓网络数据但从事硬件、驱动、物联网开发的人会告诉你USB 和蓝牙链路上的数据同样需要抓包来排查问题。这也是热搜词里usb 抓包工具哪个最好用蓝牙抓包工具背后的真实需求。5.1 USB 抓包Wireshark USBPcap 和 Bus HoundUSB 抓包和网卡抓包思路类似都是在内核层面把总线上的数据采集下来。Windows 上最方便的方案是安装开源的 USBPcap装好之后 Wireshark 的接口列表里会出现USBPcap1、USBPcap2这样的抓包接口选中之后就能看到 USB 设备枚举、控制传输、批量传输之类的事件适合排查设备无法识别、驱动枚举失败、USB 转串口通信异常等问题。另一个老牌 Windows 工具是 Bus Hound它专门做 USB 总线监控免费版能用但功能上有一些限制抓回来的数据会以表格形式呈现开发者、硬件测试人员用得多。对普通用户来说上手门槛比 Wireshark 低因为它不需要理解那么多协议但排查深度也浅一些。Linux 下不需要额外装商业软件内核自带usbmon。加载方式sudo modprobe usbmon然后 Wireshark 里就会出现usbmon1、usbmon2等接口数字对应 USB 控制器编号。调试树莓派外设、嵌入式 Linux 板卡的 USB 通信时这个方式零成本、够用。macOS 上普通用户权限下很难做 USB 抓包通常需要额外的调试配置一般场景下还是用 Windows 或者 Linux 来抓更省事。USB 抓包相对小众选哪个工具要看你是看现象还是看细节。只想确认设备有没有收到指令Bus Hound 足够需要结合 USB 协议标准逐字节分析就用 Wireshark 配合 USBPcap。5.2 蓝牙抓包的两条路线软件嗅探和硬件嗅探蓝牙抓包比 USB 又复杂一档分软件和硬件两条路线。软件路线的性价比最高。Linux 下的btmon是内核蓝牙子系统BlueZ自带的日志工具可以输出控制器和主机的 HCI 事件把日志保存后用 Wireshark 打开分析。Android 手机上开发者选项里有一个蓝牙 HCI 信息收集器打开后系统会把蓝牙通信写到/sdcard/btsnoop_hci.log导出来之后用 Wireshark 打开就能看到配对、连接参数、ATT/GATT 交互等排查 BLE 设备连接不稳定、服务发现失败这类问题非常有用。这个方案完全免费覆盖了大多数日常调试场景。硬件路线就是专用的蓝牙协议分析仪。比如 Nordic 的 nRF Sniffer配合 nRF52840 Dongle 之类的硬件板子可以在空中嗅探 BLE 广播和连接数据包。优势是能抓到没有和你本机建立连接的其他设备之间的空口报文适合做物联网设备互操作调试和安全研究。工具软件本身免费但需要买板子成本相对高。Frontline、Ellisys 这类商业分析仪功能更强但对个人开发者来说性价比太低初学阶段没必要上。5.3 什么时候才需要动用这些工具无脑把所有流量都抓一遍不是正确姿势。我个人的经验是当问题现象能靠日志和应用层信息解释时不用上升到抓包。但遇到下面几类情况抓包就是最直接的证据来源USB 设备插入后系统无任何反应USB 转串口工具通信时好时坏怀疑字节被截断或校验错误BLE 设备偶发断连应用层无报错蓝牙配对总是不成功怀疑 PIN code 或协议参数不对。这类问题靠打日志往往要反复改固件、重新编译周期很长抓包则是旁观者视角一把梭。不过也要有心理准备USB 和蓝牙抓包的产出信息都很底层读起来比 HTTP 包费劲得多需要稍微补充一些相关协议背景才能从数据里拽出问题根因。6. 一份速查表和几个我踩过的坑工具推荐这种事情如果不落到具体场景很容易变成名词堆砌。所以最后给一张我自己常用的选型速查表以及几条真金白银换来的经验。6.1 按场景选工具的速查表需求场景首选工具平台是否需要处理证书底层协议学习、网络故障排查TCP/DNS/ICMPWiresharkWindows/macOS/Linux不需要解析 TLS 才需要 SSLKEYLOGFILEWindows 下调试 Web/HTTP 接口Fiddler ClassicWindows抓 HTTPS 需要安装并信任根证书跨平台 HTTP/HTTPS 调试与自动化mitmproxy / mitmwebWindows/macOS/Linux需要安装并信任根证书移动 App、小程序联调Fiddler 或 mitmproxy 真机/模拟器代理桌面端 移动端配合需要安装根证书注意 Android 7.0 用户证书限制Android 模拟器抓包含 MuMuFiddler / mitmproxy 模拟器代理配置Windows/macOS需要USB 通信异常、枚举问题Wireshark USBPcap / Bus Hound / usbmonWindows/Linux不需要BLE 蓝牙连接、配对问题btmon / Android btsnoop 日志 WiresharkLinux/Android不需要空口 BLE 数据包分析nRF Sniffer 配套硬件Windows/macOS/Linux不需要这张表算不上覆盖所有工具但针对日常 90% 以上的抓包诉求照着选基本不会翻车。6.2 踩坑记录证书装了HTTPS 还是解不开这个坑我反复踩了多次第一次排查花了整整一下午最后发现是 Android 7.0 的用户证书信任策略。当时的情景是电脑上用 Fiddler 抓浏览器流量一切正常手机的浏览器也能正常解密但一打开目标 App所有的 HTTPS 请求全部显示隧道建立失败App 里直接报网络错误。我一开始以为是代理配置错了后来发现 App 的 HTTP 请求能看到只是 HTTPS 全挂说明代理本身是通的。排除了代理之后我一度怀疑是 SSL Pinning但后来检查发现这个 App 并没有做那么严格。真正的原因就是上面提到的Android 7.0 开始App 默认不信任用户安装的证书而浏览器有自己的信任逻辑所以浏览器能解密不代表 App 能解密。当时我拿了一台 Android 6.0 的旧手机测试果然一切正常这才锁定问题。如果要在调试自研 App 时解决这个问题可以在项目的res/xml/network_security_config.xml里允许 debug 包信任用户证书network-security-config debug-overrides trust-anchors certificates srcuser / /trust-anchors /debug-overrides /network-security-config还有一次在 iOS 上装完证书后也解不开原因是少了一步证书信任设置很多新手只安装了描述文件就以为完事了实际上 iOS 不会自动信任刚装好的根证书必须去设置里手动打开信任开关。这个细节如果你不知道能卡住一整天。6.3 最后一点建议先明确目的再选工具我也遇到过有朋友拿着抓包工具想抓网课视频他的想法挺直接把视频 URL 抓出来然后下载。我能理解这个诉求的来由但真要较真的话这里面有一堆版权问题和平台风控问题不是技术上能不能做到而是这样做不划算也不体面。抓包工具的正当打开方式是学习协议、调试接口、排查故障在你自己有权限或有授权的场景下使用。作为从业者我建议把抓包当成一项基础能力来培养而不是当成绕过限制的捷径。把 Wireshark 的过滤器用熟把 Fiddler 的 Composer 用顺把 mitmproxy 的脚本逻辑写明白这三样本事在任何一个做技术开发的岗位上都复用率极高远比临时找一个万能工具更值钱。