刚开始做开发时，我对“抓包工具有哪些”并没有太多概念。
浏览器有 Network 面板，iOS 有代理抓包工具，看起来已经覆盖了大多数需求。

直到有一次问题卡住，我才意识到：
并不是我不会用抓包工具，而是我一直在用同一类抓包方式。

一个促使我重新整理工具链的场景

当时排查的是一个跨端问题：
Web 页面正常，App 内 WebView 偶发异常；接口日志完整，但客户端行为不一致。

我最初的做法很直觉——换代理、换证书、换端口。
但真正起作用的，是停下来重新思考：我现在需要的是哪一类抓包工具？

浏览器级抓包：最容易被忽略的“默认工具”

对 Web 开发来说，浏览器自带的 Network 面板往往是第一个抓包工具。
它的优势很明确：贴近前端执行环境，操作成本低。

它适合回答的问题包括：

  • 请求是否由页面触发
  • 参数在发起前是否正确
  • 返回内容是否被浏览器解析
  • 是否命中缓存或发生重定向

但当问题发生在浏览器之外，比如 WebView、代理层或设备环境时，这个视角就开始显得局促。

代理抓包工具：接口层的主力

提到“抓包工具有哪些”，大多数人第一时间想到的，还是代理抓包工具。

它们的定位很清晰：
把 HTTP / HTTPS 请求放到一个可观察、可修改的位置上。

在接口联调、参数验证、状态码分析时，这类工具非常高效。
你能快速判断接口是否按预期工作，也能方便地做请求重放或返回修改。

但它们也有一个共同前提：
请求必须经过系统代理，且 HTTPS 解密链路必须成立。

一旦这两个条件不满足，工具本身并不会“报错”，只会变得沉默。

当代理抓包失效时，工具列表需要扩展

很多工程师是在代理抓包失效之后，才开始真正关心“还有哪些抓包工具”。

比如：

  • iOS App 启用了 HTTPS pin 校验
  • 某些请求绕过了系统代理
  • 只在真机环境复现的问题

这时，如果继续纠结代理配置，往往会陷入无效循环。

设备侧抓包：补齐“真实运行环境”的视角

在需要确认真实设备通信行为时，我会使用 抓包大师（Sniff Master） 这一类设备侧抓包工具。

它的作用并不是取代代理工具，而是解决一个更基础的问题：

这个请求，在真实设备上到底有没有发生？

由于不依赖系统代理，也不需要越狱或 root，它能从设备层面抓取 HTTPS、TCP、UDP 等通信数据。这在以下场景中非常关键：

  • 真机环境与模拟器行为不一致
  • HTTPS 解密失败但请求疑似存在
  • 需要排查第三方 SDK 的真实网络行为

在我的工具列表里，它更多承担的是“还原真实环境”的角色。

指定 App 抓包，让分析回到问题本身

抓包工具有哪些，并不只是功能差异，还有使用体验的差异。

在真机或复杂环境下，全局抓包往往会产生大量噪音。
如果工具支持只抓取指定 App 或指定流量，排查效率会明显提升。

当所有抓到的数据都和当前问题相关时，工程师更容易形成判断，而不是被数据淹没。

数据流抓包工具：当 HTTP 已经解释不了问题

并不是所有网络问题都发生在 HTTP 层。

在涉及以下情况时，HTTP 抓包往往不足以解释现象：

  • TCP 长连接异常
  • 心跳或状态同步失败
  • 自定义协议通信问题

这时，“抓包工具有哪些”这个问题，会自然扩展到数据流抓包工具。

抓包大师支持 TCP / UDP 数据流抓取，并可以导出数据供进一步分析。
它在这一步的意义，不是解析协议细节，而是确认连接是否建立、是否中断、是否重复。

Wireshark：工具列表里的“放大镜”

Wireshark 几乎出现在所有抓包工具列表中，但它并不适合所有阶段。

在我的使用习惯里，它更像是一个确认工具：
当我已经通过其他工具定位到某个可疑连接或时间点，再用 Wireshark 去验证细节。

如果在问题还很模糊时就直接使用，反而容易迷失在信息量里。

拦截与修改：验证理解是否正确

抓包工具的一个重要能力，是允许你改变通信行为。

通过修改请求参数、Header 或响应内容，可以快速验证客户端或服务端的处理逻辑。
这比反复改代码、重新部署要高效得多。

抓包大师支持通过脚本拦截和修改请求、响应，在这一阶段更像是实验工具，而不是单纯的抓包工具。

回到最初的问题：抓包工具有哪些？

如果只列名字，其实并不难。
但从工程实践来看，更有价值的问题是：

  • 我现在站在哪一层看网络
  • 当前工具能看到的，是否是真实发生的通信
  • 是否需要换一个视角继续判断

不同抓包工具，本来就服务于不同层级。
把它们组合起来使用，往往比单独依赖某一个工具更可靠。