Charles 抓包失败怎么办？从代理排查、TLS 分析到多工具协同的完整方案-抓包大师使用教程

在移动端开发、接口调试和线上问题定位中，Charles 是最常使用的代理抓包工具之一。但很多人用 Charles 时都会遇到一个经典问题：明明已经设置代理，也安装了证书，但 Charles 就是抓不到包。

有时还能抓到 HTTP，但 HTTPS 全部失败；有时部分域名能抓取、部分却完全不显示；甚至偶尔“今天能抓、明天突然全部抓不到”。如果只依赖代理方式，很难找到问题根源。

一、Charles 抓包失败的典型原因（按出现频率排序）

证书未被系统或 App 信任

iOS 对证书信任链限制严格，常见问题包括：

证书未在“关于本机 → 信任证书”中开启
企业 Wi-Fi 中间设备替换证书链
ATS 策略要求严格的证书验证

表现：HTTPS 全部抓不到，只有 CONNECT。

App 启用了证书 Pinning

现代 App 对安全要求高，常见情况包括：

App 校验证书哈希
内置公钥 pinning
使用自定义验证逻辑绕开系统代理

表现：Charles 完全无流量，或者请求直接失败。

QUIC / HTTP/3 绕过代理

Charles 使用 TCP 代理，而 HTTP/3 走 UDP：
→ Charles 根本看不到 QUIC 流量。

许多 App（尤其是视频类、国外 SDK）默认开启 HTTP/3。

使用 CFNetwork / NSURLSession 自定义栈绕过代理

部分 App 使用自定义网络栈导致：

部分请求进代理
部分请求完全绕过代理

多 App 抢流量、数据噪音过大

Charles 会显示全局代理流量，有时难以快速定位关键请求。

二、Charles 抓包失败的排查流程（可直接执行）

① 检查代理与证书是否生效

Wi-Fi 设置中的代理 IP、端口
证书是否已信任
Charles 是否开启 SSL Proxying

若 HTTPS 一条都解不开，多半是：

证书链问题
ATS / pinning
中间人设备拦截

② 分析是否为证书 Pinning

若 Safari 能抓到 HTTPS，但 App 抓不到 → 90% 是 pinning。

此时无需继续纠结 Charles 设置，而应切换补抓方式。

③ 判断是否为 QUIC（HTTP/3）导致抓包失败

关闭 HTTP/3 后重试：

Chrome：chrome://flags/#enable-quic
App：有些可通过配置关闭
Wi-Fi 路由器或网络策略

若关闭后能抓包 → 即为 QUIC 问题。

④ 服务器抓包确认请求是否到达

使用 tcpdump 抓取服务端流量：

sudo tcpdump -i any host <client_ip> and port 443 -s 0 -w server.pcap

检查：

是否看到 ClientHello
是否有 TLS Alert
是否存在 RST

若服务端连握手都没收到 → 请求在客户端前就失败。

三、当 Charles 抓包失败时：如何进行“补抓”？

这是工程上最关键的一步，也是很多人忽略的部分。

当代理失败、证书不被信任、App 使用 pinning 或 QUIC 时，需要使用能捕获底层 TCP/TLS 流量的工具补齐证据。

抓包大师（Sniffmaster）在补抓场景中的作用，解决 Charles 做不到的部分：

无需代理即可抓 HTTPS / TCP / UDP 流量
按 App / 域名过滤（减少噪音）
自动识别 HTTP/HTTPS/mdns 等协议
查看数据流（HEX / 文本 / 原始）
支持脚本拦截器，可修改请求/响应
支持 导出 Wireshark 兼容 pcap（用于与服务端 pcap 对比）

因此在 Charles 完全抓不到的情况下，常见流程是：

补抓流程：

用 Sniffmaster 抓取目标 App 的 HTTPS/TCP 流量
导出 pcap
再用 Wireshark 分析 TLS 握手、证书链
与服务器端 tcpdump 做“左右对照”比对
确认问题位置：客户端 / 网络链路 / 后端

这是当前最稳定、覆盖场景最完整的抓包方式。

四、真实案例演示：Charles 完全抓不到 HTTPS

某企业 App 在公司 Wi-Fi 下无法抓 HTTPS，排查流程如下：

Charles 有 CONNECT 但无 HTTPS 内容 → 证书未信任或被替换
服务器端也没有 ClientHello → 请求根本没出去
使用 Sniffmaster 抓取 TCP 流量 → 发现 TLS Alert: bad certificate
进一步检查网络 → 公司网关替换证书链
修复证书链后抓包恢复正常

这是非常典型的“网络链路替换证书导致抓包失败”的场景，仅用 Charles 是无法定位的。

五、团队可复用的抓包 SOP（适合所有 iOS/HTTPS 项目）

统一标准流程可以极大减少排查时间：

应收集的信息

App 版本、系统版本
网络信息（Wi-Fi/4G/5G）
Charles/代理设置截图
抓包时间点（秒级）

必须包含的抓包文件

Charles 会话（若能抓到）
Sniffmaster 导出的 pcap
后端服务器 tcpdump pcap
Wireshark TLS 握手截图

判断标准

TCP 连接是否正常
TLS 握手是否完成
是否存在证书链问题
是否由 QUIC 绕过代理
是否由 pinning 阻断

输出最终定位

如：

客户端 ATS 校验导致
公司 Wi-Fi 替换证书链
QUIC 导致代理失效
App 内开启 pinning
后端证书链缺失

Charles 抓包失败并不是 Charles 的问题

核心原因通常来自以下四类：

网络证书链异常
App 启用 pinning
QUIC 协议绕过代理
网络链路拦截

因此，一个成熟的抓包体系应该由：

层级	工具
应用层（代理）	Charles / Proxyman / Fiddler
网络层（TCP/TLS）	tcpdump + Wireshark
补抓（代理无法使用）	抓包大师（Sniffmaster）
自动化/脚本	mitmproxy、scapy、pyshark