在一次 iOS 应用调试中，我遇到过这样一个状况：明明 Charles 已经开着，代理也配了，但界面空空如也，连一个请求都没有抓到。这个问题一旦出现在关键调试阶段，非常容易打断开发节奏。
这篇文章就是我当时的完整排查过程，以及最终的解决方法，供你参考。
一、初步判断：是代理链路的问题还是 App 自身的限制？
第一反应是先排除网络层面的配置问题，因为大多数"抓不到包"都发生在这里。 我的判断顺序是：
- 确认 Charles 正在监听
- Recording 状态必须开启
- 允许远程连接（Allow remote connections）已勾选
- 检查手机代理配置
- 在 iPhone 的 Wi-Fi 高级设置中，HTTP 代理设为电脑 IP + 端口（通常 8888）
- 确认手机和电脑在同一个局域网下
- 测试能否访问 Charles 证书页面
- 在 Safari 打开
http://charlesproxy.com/getssl，如果打不开，说明网络代理没生效
- 在 Safari 打开
二、深入排查：HTTPS 解密与证书信任
代理配置没问题后，就要考虑 HTTPS 解密：
- 启用 SSL Proxying
- Charles → Preferences → SSL Proxying → 勾选 "Enable SSL Proxying"
- 添加需要解密的域名，或者直接用
*
- 安装并信任证书
- 下载证书后，进入 iOS 设置 → 通用 → 关于本机 → 证书信任设置，打开信任开关
- 这一点经常被忽略，没打开的话 HTTPS 内容依旧不可见
三、遇到硬防护：SSL Pinning
当我抓某个业务 App 时，发现 HTTPS 握手直接失败，这就高度怀疑是 SSL Pinning 或双向认证。 这种情况下，Charles、Fiddler、Proxyman 等代理型工具都无能为力，因为应用会拒绝中间人证书。
四、切换方案：USB 直连抓包
为了绕过 Pin，我直接换了 Sniffmaster（抓包大师）：
- iPhone 用数据线连接电脑
- 无需设置 Wi-Fi 代理，也不需要安装证书
- 能直接看到 HTTPS 明文，并且支持双向认证破解
- 还能只抓取指定 App 流量，避免系统噪声干扰
抓包成功后，我还用它的 拦截器 功能改了一个请求参数，用于验证后端逻辑，非常高效。
五、多工具协作：完整调试链路
在整个过程中，我发现单一工具的能力是有限的，组合使用效果更好：
| 调试环节 | 使用工具 |
|---|---|
| 基础代理抓包、接口验证 | Charles |
| 绕过 Pin、解密双向认证 | Sniffmaster（USB 直连抓包） |
| 模拟错误响应、接口延迟 | mitmproxy + Python 脚本 |
| 分析 TCP 握手失败、网络延迟 | Sniffmaster 导出 PCAP + Wireshark 分析 |
六、经验总结
- 先排除代理和证书问题，这是 80% 抓不到包的原因
- 碰到 Pin 时，直接切换 USB 直连型抓包工具，不要死磕代理
- 构建多工具链路，抓包只是第一步，数据分析与行为复现同样重要
- 留存原始流量文件（如 PCAP），方便后续复盘或安全测试
Charles 抓不到包时，不要盲目重装或多次刷新，应该从网络配置、证书信任、HTTPS 解密到应用安全机制逐步定位问题。必要时，用 其他工具作为替补，可以直接跨过代理层限制，把真实流量拿到手。