在很长一段时间里，Charles 都是我最信任的抓包工具之一。
配置简单、界面直观、对 HTTP/HTTPS 的支持也足够成熟。直到有一次，它突然在真机环境里“什么都抓不到”，我才意识到这个问题本身值得被认真对待。
有意思的是，那次排查真正解决问题的，并不是“把 Charles 配得更复杂”，而是承认它可能已经不在合适的位置上了。
一个看起来很像“配置错误”的场景
那次的现象其实非常典型：
- Mac 上 Charles 正常运行
- iPhone 已经连上代理
- Charles 证书也已安装并信任
- HTTPS 解密已开启
但 iOS App 发起请求时，Charles 面板里一片安静。
如果只看表象，几乎所有人都会得出同一个判断：是不是还有哪个配置没点对？
Charles 擅长的，其实一直都很明确
冷静下来之后，我重新审视了一下 Charles 的工作方式。
Charles 本质上是一个基于代理的抓包工具。
它非常擅长的事情包括：
- 拦截通过系统代理的 HTTP / HTTPS 请求
- 解密标准 TLS 链路
- 清晰展示请求结构并支持修改和重放
只要请求走的是“标准代理路径”，Charles 通常都很可靠。
问题在于，不是所有 iOS App 都会这么走。
当抓不到包开始变得可重复
如果只是某一次抓不到，还可以归咎于网络或操作失误。
但当以下现象开始反复出现时，我会停止继续折腾 Charles 本身：
- 模拟器可以，真机完全不行
- 同一接口，有时能抓到，有时完全消失
- App 升级后突然抓不到
- HTTPS 连接存在，但内容始终不可读
这类情况，往往说明：
App 的网络行为已经超出了代理抓包的假设前提。
HTTPS Pinning，常见却不显眼
在 iOS 项目中，HTTPS pin 校验几乎已经成了“默认配置”。
一旦启用，Charles 的处境就会变得微妙。
有的 App 会直接拒绝连接；
有的 App 会继续通信，但 Charles 再也解不了密。
表现出来的结果，很容易被误解为“Charles 抓不到包”。
换个问题，比换配置更重要
在那次排查中，我做的第一件事并不是换抓包工具，而是换问题。
不再想为什么 Charles 抓不到包？
而是这个 iOS App，在真机上到底有没有正常发起这些请求？
为了回答这个问题，我引入了抓包大师（Sniff Master）这种设备侧抓包工具。
设备侧抓包，让是否真的有请求变得可确认
抓包大师不依赖系统代理，也不要求在 iPhone 上反复切换配置，更不需要越狱或 root。
它的价值在于：从设备层面直接观察真实通信。
在这个阶段，它并不是“替代 Charles”，而是用来验证一个前提：
请求是否真实存在，是否真的发生过。
当我在设备侧看到稳定的 HTTPS 请求时，之前 Charles 的“沉默”就有了合理解释。
只抓目标 App，避免误判“什么都没发生”
真机抓包时，一个很容易被忽略的问题是噪音。
系统服务、后台同步、其他 App 的请求，可能会让你误以为目标 App 没有任何网络行为。
支持只抓取指定 App 的工具，在这种情况下尤为重要。
当所有数据都来自同一个 App，判断会简单得多：
到底是 Charles 看不到，还是请求根本没走代理。
Charles 看不到的，未必是 HTTP
在进一步分析时，我发现问题并不仅限于 HTTPS 接口。
部分状态同步逻辑使用的是 TCP 长连接，这些通信行为本来就不会出现在 Charles 里。
如果只盯着 HTTP 抓包工具，很容易得出“接口正常但功能异常”的结论。
抓包大师支持 TCP / UDP 数据流抓取，这一步让我确认：
问题并不发生在 HTTP 层，而是在连接层。
Wireshark 的位置，并不在第一步
很多人在遇到 Charles 抓不到包时，会直接建议“上 Wireshark”。
但从工程实践来看，Wireshark 更适合用来确认细节，而不是作为排查起点。
在问题尚不清晰时，面对大量底层数据，反而会增加理解成本。
我更倾向于在抓包路径已经明确之后，再用它做补充验证。
拦截和修改，用来验证判断是否成立
在定位到问题原因后，我通常会通过修改请求或响应，验证客户端行为。
比如模拟异常返回、缺失字段或延迟响应，观察 App 的反应。
这种方式比反复打包测试更直接。
抓包大师支持通过脚本拦截和修改请求、响应，在这个阶段更像是一个实验工具，而不是单纯的抓包工具。
对Charles 抓不到包怎么办的理解
经历过几次类似排查之后，我对这个问题的看法变得更现实：
- Charles 抓不到包，并不等于请求不存在
- 很多时候，是抓包路径已经不适用
- 多工具组合，比单一工具更可靠
Charles 依然是一个非常优秀的抓包工具，只是它并不覆盖所有 iOS 网络场景。
