如果只是想“看一下请求”，Mac 上的选择其实很多。
但当需求开始变得具体，比如要抓 iOS App、要看 HTTPS、要改请求内容，工具之间的差异才真正显现出来。

我自己在 Mac 上抓包，往往不是一开始就决定用哪个软件，而是先想清楚几个问题：
是抓浏览器流量，还是抓本机程序？
是调接口，还是分析异常？
有没有 iOS 设备参与？

这些问题，直接决定了工具是否合适。

Charles：最容易上手，但也最容易卡住

在 Mac 上，Charles 往往是很多人的第一站。

如果只是抓浏览器或者普通 App：

  • 安装后启动
  • 打开 macOS 的网络代理
  • 访问目标页面

HTTP 请求几乎立刻就能看到。

但一旦涉及 HTTPS，或者抓 iOS App，步骤就会明显变多：

  • 安装 Charles 根证书
  • 在 macOS 钥匙串里设为信任
  • iOS 设备上再装一份证书
  • Wi-Fi 代理手动配置

只要其中一步没做对，表现通常就是“什么都抓不到”。
这不是 Charles 的问题，而是代理模式本身的复杂度决定的。

mitmproxy：更偏向开发者的命令行方案

如果你更习惯终端环境，mitmproxy 是 Mac 上非常值得一试的工具。

它的优势在于：

  • 可脚本化
  • 请求和响应可以用 Python 直接处理
  • 适合自动化调试或测试场景

但现实是，mitmproxy 对新手并不友好。
证书、代理、脚本三件事，只要有一项不熟，体验就会明显下降。

我一般只在需要“批量处理请求逻辑”时才会选它，而不是日常抓包。

Wireshark：不是替代品，而是补充

严格来说，Wireshark 并不是抓“HTTP 接口”的工具。

在 Mac 上用 Wireshark，更像是在看：

  • TCP / UDP 连接
  • DNS 请求
  • TLS 握手是否成功

它非常适合回答一些代理工具回答不了的问题，比如：

请求有没有真正发出去？
是 DNS 失败，还是 TCP 被拒绝？

但如果你想直接看 HTTPS 内容，Wireshark 并不合适，除非你已经能解密 TLS。

当抓包对象变成 iOS 设备，工具选择会明显收缩

一旦需求变成：

  • Mac + iPhone
  • 抓 App 内请求
  • HTTPS 是默认

很多 Mac 抓包软件就开始显得力不从心。

代理模式可以继续用，但配置成本会迅速上升，尤其是面对证书校验、双向验证时。

抓包大师在 Mac 上的定位，其实很清晰

我第一次在 Mac 上用 抓包大师，并不是为了替代 Charles，而是因为代理模式已经走不通。

在 Mac 环境下，抓包大师更像是一个底层抓包工具，尤其是在抓 iOS 设备时。

它在 Mac 上常用的几种功能包括：

  • HTTPS 代理抓包（传统方式）
  • HTTPS 暴力抓包（无需证书信任）
  • 数据流抓包（查看所有网络数据）

这些功能解决的是不同层级的问题，而不是互相替代。

如何在 Mac 上用抓包大师抓 iOS App

如果目标是 iPhone App：

  • 用 USB 连接 iPhone 到 Mac
  • 保持设备解锁并信任电脑
  • 按提示安装描述文件
  • 选择 iOS 设备而不是“本机”
  • 根据需求进入 HTTPS 代理抓包或 HTTPS 暴力抓包

如果只是接口调试，我会先试代理模式；
如果代理抓不到，再切换暴力抓包。

这种按成本递增的方式，比一上来就搞复杂方案要省时间。

本机抓包与设备抓包，是两条完全不同的路

在 Mac 上抓包，经常会混淆两个概念：

  • 抓 Mac 本机流量
  • 抓 iOS 设备流量

前者更适合用 Charles、mitmproxy；
后者才是抓包大师发挥优势的地方。

抓包大师在 Mac 上第一次运行本机抓包时，会要求输入系统密码，这是 macOS 权限模型决定的，属于正常行为。

工具多，并不意味着要全用

实际工作中，我很少只用一个抓包工具：

  • Charles：快速看接口
  • Wireshark：排查连接问题
  • 抓包大师：处理 iOS、证书校验、复杂 HTTPS

它们之间不是竞争关系，而是覆盖不同问题空间。

Mac 抓包软件确实不少，但真正好用的，往往取决于场景而不是功能列表。