先看懂链路，别靠勾选碰运气
Charles 本质是位于客户端与服务器之间的 HTTP 代理。普通 HTTP 可直接转发和记录；HTTPS 原本是客户端与服务器建立加密通道，Charles 若要展示明文，就要分别与客户端、服务器建立 TLS 连接。客户端因此必须信任 Charles 签发的本地根证书。
排错顺序应固定为：流量有没有经过代理、证书是否被系统或应用信任、目标域名是否启用 SSL Proxying、应用是否做了额外证书校验。顺序颠倒，最常见的结果就是重装三遍证书仍旧无效。
查尔斯避坑：抓不到包的底层原因
查尔斯避坑的关键不是反复重装，而是分清代理、证书、应用校验三层链路。能看到 CONNECT 却没有明文、手机完全没请求、部分 App 单独失败，背后不是同一种故障。理解 Charles 如何转发和解密流量，排查通常十分钟内就能收窄范围。
完全没流量，多半卡在代理层
手机和电脑要能互相访问。代理地址应填电脑在当前局域网中的 IP，不是 127.0.0.1；端口要与 Charles 的 Proxy Settings 一致。电脑切换 Wi-Fi、接入 VPN 或休眠唤醒后，局域网 IP 可能变化，昨天能用的配置今天便失效。
还要检查防火墙是否放行 Charles，以及首次连接时 Charles 弹出的访问授权是否被拒绝。先用手机浏览器打开一个普通网页测试；浏览器都没有记录，就别急着研究 App 的证书绑定。
有 CONNECT 没明文，问题在 TLS 层
看到 CONNECT 只说明隧道经过了 Charles，不代表 HTTPS 已解密。电脑端要安装并信任 Charles Root Certificate，移动端也要分别安装；部分系统安装后还需进入证书信任设置，手动开启完全信任。仅下载证书并不等于已信任。
随后把目标主机加入 SSL Proxying，而不是无差别添加通配符。全量解密会制造大量系统请求噪声，也会让账号、令牌等敏感信息出现在会话文件中。抓包结束应关闭代理，测试证书只留在受控设备。
只有某个 App 失败，别误判为 Charles 损坏
部分 App 使用证书绑定，即应用只接受预置公钥或证书，系统信任 Charles 根证书也会拒绝连接；Android 应用还可能默认不信任用户安装的 CA。HTTP/3 基于 QUIC 和 UDP，也不走传统 HTTP 代理路径，表现可能是请求缺失或回退。
这些限制属于应用安全设计，不应在生产设备上强行绕过。可在自有测试包中配置调试证书信任、关闭绑定或让开发提供可观测日志。查尔斯避坑的结论很简单：先定位哪一层断了，再改那一层，别把所有失败都归咎于证书。
常见问题
Charles 显示 unknown 或 SSL handshake failed 怎么办？
先确认根证书已被当前设备信任，再核对目标域名是否加入 SSL Proxying。若只有一个 App 失败，应让开发确认是否存在证书绑定或自定义网络栈。
为什么开了 Charles 后部分网站打不开？
常见原因是证书未信任、VPN 改写路由、代理端口不一致，或网站采用 Charles 当前无法正常代理的协议。关闭系统代理可快速判断是否由代理链路引起。
抓包证书可以一直留在手机里吗？
不建议留在日常或生产设备。测试结束后应关闭代理并移除不再使用的根证书，会话文件也要按敏感数据管理。