很多人第一次遇到 Charles 抓不到包，反应是反复装证书、重启软件、重连 Wi-Fi。
我以前也这样做过，但后来发现，这种方式大多是在重复已经失败的经过。

真正需要先确认的不是 Charles 配没配好，而是：这个 App 的网络请求，是否还走系统代理？

Charles 能抓到什么，本身就有上限

Charles 的前提条件很明确：

  • 请求必须走系统代理
  • TLS 证书校验必须接受中间人
  • 网络栈没有绕开系统设置

在接口联调、调试自家 App 时，这个条件通常成立，但在一些线上 App 或 SDK 更新后，情况就不一定了。

我遇到过的一个典型场景

一次线上问题排查中：

  • Safari 的请求能看到
  • App 登录接口完全没有
  • Charles 状态栏显示有连接，但无数据

这类情况，已经基本可以判断为请求根本没有进入 Charles 的 HTTPS 解密路径。

这时继续尝试 Charles，意义不大

如果 TLS 握手阶段已经被 App 拒绝，Charles 能做的事情其实很有限。

我通常会换一个观察角度，不再关心“内容”，而是先确认通信有没有发生。

用数据流抓包，确认请求是否真实存在

在 iOS 场景下，我会直接使用设备侧的数据流抓包工具。

例如抓包大师的数据流抓包模式：

  • 通过 USB 连接 iPhone
  • 不依赖代理、不需要证书
  • 能看到 TCP、UDP 等真实网络流量

在这一层，我关心的只有两个问题：

  • 是否存在到目标服务器的连接
  • 连接发生在什么时间点

如果这里完全没有数据，那问题已经不在抓包工具，而在 App 本身。
数据流抓包

当数据流存在，但 HTTPS 仍不可见

这种情况通常意味着：

  • TLS 握手完成
  • 但证书校验或 Pin 校验阻断了解密

这也是 Charles 最常失效的地方。

重新回到代理抓包，但换一种方式

如果确认请求仍走系统网络，只是 Charles 无法解密，我会尝试另一种代理工具。

抓包大师的 HTTPS 代理模式，本质仍是中间人方式，但在 iOS 侧的配置更贴近系统流程：

  • 自动引导证书安装
  • 明确提示信任状态
  • 代理配置路径更直观

这并不是说它比 Charles 强，而是验证是否为工具兼容问题。

拦截，用来验证客户端假设

在代理抓包可用的前提下，我会打开拦截器：

  • 修改返回字段
  • 模拟异常状态码
  • 重定向请求地址

抓包大师的拦截器支持用 JS 直接操作请求和响应，这一步可以非常快地验证：

  • UI 是否依赖某个字段
  • 错误分支是否被正确处理
  • 重试逻辑是否生效

这比反复改代码、重新打包高效得多。

Charles 抓不到包，并不是工具问题

回顾几次真实经历，会发现问题往往出在：

  • 请求路径判断错误
  • TLS 阶段被提前拒绝
  • 过早聚焦于解密结果