每一个前端、测试、移动开发，或是做接口联调的工程师，几乎都遇过这个问题：

“Charles 设置都配了，但为啥还是抓不到包？”

这类问题乍一看像是“小事”，但它背后藏着复杂的网络行为、操作系统机制、HTTPS 安全模型、SDK 封装策略等因素。一次“抓不到包”，有可能浪费整个下午的调试时间，甚至误判方向、错修逻辑。

本文我将从实战视角出发，梳理出：

1. Charles 抓不到包的典型原因排查路径；
2. 各平台（iOS、Android、macOS、Windows）配置陷阱；
3. 替代抓包工具适用场景对比；
4. 真实项目中 Sniffmaster 的解决能力。

这不是一篇工具评测文，而是一次围绕“抓不到包怎么办”展开的问题导向实践经验总结。

Step 1：Charles 配置是否确实完成？

很多抓不到包的问题，其实源于最基础的配置没搞清：

网络代理是否正确设置？

• Charles 默认监听 8888 端口，确保设备（模拟器或真机）连接的 Wi-Fi 或代理设置指向该端口。
• 手机端必须连接同一局域网，否则根本不会经过 Charles。

安装并信任 Charles 根证书？

• macOS 需在“钥匙串”中将 Charles Proxy CA 标记为“始终信任”；
• iOS 设备必须：
  1. 安装证书；
  2. 到设置 → 通用 → 关于本机 → 证书信任设置 → 启用信任；
• Android 部分厂商不允许用户根证书注入系统，需要开启“开发者证书信任”选项。

SSL Proxying 是否启用？

Charles 中必须对目标域名启用 Enable SSL Proxying（可配置为 *:* 做全局），否则即使连上，HTTPS 请求也抓不到内容。

Step 2：你的请求“真的”走代理了吗？

很多开发者以为“设置了代理=请求就能抓”，其实不然。

请求方式是否直接绕过代理？

• 使用了 fetch 配合某些第三方库（如 axios+自定义 adapter）；
• 使用系统 socket、QUIC 等低层方式发请求（不会走HTTP代理）；
• 某些APP默认启用 DNS over HTTPS，自行解析后直连 IP；

特别是原生 SDK 或三方封装组件，它们为了性能或安全，常会关闭代理跟踪，直接发包给服务端。

Charles 无法劫持这些行为，因为它拦不到。

Step 3：HTTPS Pinning 是最大障碍

如今大量移动端应用启用 SSL Pinning，尤其是：

• 金融、支付类APP；
• OAuth登录平台（如 Apple、Google、微信）；
• 企业自研 SDK；

这些机制通过比对证书公钥，拒绝任何中间人攻击——哪怕你 Charles 设置再对，它一看你证书不对劲就直接断掉连接。

表现通常为：

• 抓不到包；
• 请求失败，状态码 0；
• 控制台无报错，但界面空白或功能无响应；

Charles + 证书方式在这种场景下几乎无解。

Step 4：设备端限制是常被忽视的问题

iOS 限制：

• iOS 14+ 对中间人代理行为更加严格；
• 企业版APP + 加固方案（如 AppSealing）主动阻断代理连接；
• 无越狱环境下，封装SDK的包根本没法打日志；

Android 限制：

• Android 7+ 后系统默认不信任用户安装证书；
• 某些安全厂商（如华为/小米）会检测抓包行为并中断请求；
• 多数SDK使用 OkHttp + 自定义SocketFactory 绕过代理注入；

如果你在这些平台上依然尝试 Charles 抓包，成功率极低。

Step 5：对症下药——不同场景下替代工具推荐

实战案例：Sniffmaster 帮我们定位了三天没找出的封装Bug

项目中我们对接某三方图像识别SDK，日志没输出，请求抓不到，UI卡在“识别中”。

• Charles 设置全开：抓不到；
• mitmproxy 跳证书信任失败；
• 后端说“你请求没到我们服务”；

最终测试同事插上 iPhone 用 Sniffmaster 抓包，发现：

• 请求路径正确；
• Header中 X-Device-Token 丢失；
• 这是打包时脚本替换变量出错；

如果没有 Sniffmaster，我们会陷入死循环地调 UI、改配置，实际错在构建。

不是 Charles 不行，而是它不是全能的

**抓不到包，并不意味着没发请求。**你需要的，是能“看到包”的正确工具组合：

1. 明确是否能走代理；
2. 识别是否有HTTPS pinning；
3. 判断是模拟器or真机or封装层；
4. 引入 Sniffmaster 等物理抓包手段，在最关键时刻做突破；