很多人第一次遇到 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 阶段被提前拒绝
- 过早聚焦于解密结果