这种情况我之前帮不少开发者排查过，别慌，咱们一步步来定位和解决问题：

1. 确认SSL代理规则是否精准配置 #

你可能以为全局开启SSL代理就万事大吉，但Charles经常需要针对特定域名单独设置规则，这是最容易忽略的点：

• 打开Charles，顶部菜单选「Proxy」→「SSL Proxying Settings」
• 检查「SSL Proxying」列表里是否包含你要抓包的目标域名，如果没有，点击「Add」：
  • 在「Host」栏填写目标域名（比如api.yourdomain.com，或者用*匹配所有域名）
  • 「Port」栏固定填443（HTTPS默认端口）
  • 保存后再尝试抓包
• 注意：如果用了通配符*，要确保没有被其他更严格的域名规则覆盖

2. 彻底验证设备端证书的生效状态 #

很多时候证书看似安装并信任了，但系统层面其实没完全激活：

• iOS设备：
  安装证书后，必须进入「设置」→「通用」→「关于本机」→「证书信任设置」，找到Charles的根证书，把对应的开关打开（iOS 10及以上版本强制要求这一步，仅安装证书无效）
• Android设备：
  • Android 7+系统：除了安装用户证书，还要给你的App添加网络安全配置：
    在AndroidManifest.xml的<application>标签里添加：

    android:networkSecurityConfig="@xml/network_security_config"
    

    然后在res/xml目录下创建network_security_config.xml，写入：

    <?xml version="1.0" encoding="utf-8"?>
    <network-security-config>
        <base-config cleartextTrafficPermitted="true">
            <trust-anchors>
                <certificates src="system" />
                <certificates src="user" />
            </trust-anchors>
        </base-config>
    </network-security-config>
    

  • Android 11+系统：部分机型需要将Charles证书移至系统证书目录（可尝试用Charles自带的「Install Root Certificate on Mobile Device」工具重新安装，或在设备端手动移动）

3. 重启相关进程/设备清除缓存 #

别小看重启，很多时候进程残留或缓存会导致规则不生效：

• 完全关闭Charles（包括后台进程），再重新打开
• 重启测试设备，或者至少杀掉要抓包的App，重新启动后再尝试抓包

4. 检查Charles代理的基础状态 #

• 确保Charles顶部菜单「Proxy」下的「Mac OS X Proxy」（对应你的笔记本系统，Windows是「Windows Proxy」）处于勾选状态
• 验证设备WiFi代理是否正确：打开Charles的「Help」→「Local IP Address」查看你的笔记本本地IP，确认设备WiFi代理的IP和端口（默认8888）与之一致

5. 排查证书过期或冲突问题 #

• 打开Charles的「Help」→「SSL Proxying」→「Install Charles Root Certificate」，检查证书有效期，若过期则重新安装
• 在系统证书管理器（Mac是钥匙串访问，Windows是证书管理器）中，删除旧的或同名的Charles证书，只保留最新的有效证书
• Mac用户额外注意：在钥匙串中找到Charles证书，右键选「显示简介」，在「信任」选项卡中设置「使用此证书时」为「始终信任」

6. 特殊场景：目标App启用了证书钉扎（Certificate Pinning） #

如果你的App使用了证书钉扎技术，它会只信任预先配置的特定证书，Charles的根证书会被直接拒绝：

• 最简单的解决方式是在Debug版本中临时注释掉证书钉扎的相关代码
• 也可以尝试用Charles的「Map Remote」或「Rewrite」功能绕过，但这需要你对App的代码逻辑有一定了解

如果以上步骤都试过还是没解决，建议查看Charles的日志（顶部菜单「Window」→「Log」），里面会有更详细的错误提示，比如证书验证失败的具体原因，能帮你进一步定位问题。

内容的提问来源于stack exchange，提问作者TeriA