很多人在抓包时候第一次意识到 SSL 证书认证是一堵墙
证书装了、代理配了、Wi-Fi 也确认走代理，但 iOS App 就是完全没请求。
这时候就不用浪费时间继续检查证书是否勾选"完全信任"。
问题并不在证书，而在校验位置
iOS 抓包绕不过 SSL，核心原因通常只有一个证书校验不再交给系统处理。
一旦 App 在代码里做了这些事：
- 内置服务端证书或公钥
- 校验 TLS 握手中的证书指纹
- 要求客户端证书参与握手
系统信任链的作用就被弱化，甚至完全失效。
这也是为什么代理抓包工具在这些 App 上看起来没问题，但什么都抓不到。
我一般不会直接想怎么绕过，而是直接换抓包
在实际工程中，"绕过 SSL 认证"并不总是第一步。
我更习惯先问去想，有没有不依赖系统证书的抓包方式？
这一步，决定了后续是否还要折腾证书、Hook 或反编译。
代理抓包还能做什么？不要一开始就放弃
即便 App 开启了 SSL 校验，代理抓包并非完全没用。
我通常会用 Charles 或系统代理模式做两件事：
- 验证 App 是否还会发起网络连接
- 观察 DNS、SNI、连接失败的时机
如果 TLS 连接在握手阶段直接失败，那就说明校验发生在非常早的位置，继续在代理模式上纠结意义不大。
切换到 HTTPS 暴力抓包，是我绕过 SSL 的常用方式
当确认代理模式行不通后，我会使用 抓包大师 的 HTTPS 暴力抓包 功能。
这个模式的核心差异点在于：
- 不依赖系统代理
- 不要求在 iOS 上信任抓包证书
- 请求在更贴近 App 的执行路径中被捕获
也正因为这一点，即使 App 做了 SSL 证书校验，数据依然有机会被截获。
实际操作中，我会这样启动暴力抓包
流程不复杂，但顺序很重要：
- 用 USB 连接 iPhone，保持解锁和亮屏
- 第一次连接时在手机上点击"信任此电脑"
- 按提示安装 iOS 驱动并重启抓包大师
- 在手机上安装描述文件
- 如果是较新的系统版本，根据提示开启开发者模式
这些准备完成后，在设备列表中选中 iOS 设备，确认左下角的"高级管理服务"已经正常启动，再进入 HTTPS 暴力抓包界面。
抓之前，我一定会先做 App 级筛选
这是很多人忽略的一步。
在暴力抓包界面中，我会先点「选择 App」，只勾选目标应用。
这样做的好处很直接：
- 系统流量不会淹没目标请求
- 更容易判断哪些请求是 App 主动发出的
在调试 SSL 校验相关问题时，减少干扰比"抓得多"更重要。
能抓到 ≠ 一定能看全，这是绕过 SSL 的真实边界
即使成功绕过 SSL 校验，抓包结果仍然受一个条件限制：
App 是否使用 iOS 开发证书签名。
事实上：
- 自签或重签 App：请求体和响应体可以正常查看
- App Store 原包或系统 App：通常只能看到 URL 和 Header
这不是工具问题，而是 iOS 对未签名代码的天然保护。
当 Body 看不到时，我通常会这样继续排查
即便只有 Header，我仍然会关注：
- 是否命中了正确的接口
- Header 中是否携带业务参数或状态标识
- 请求是否重复、重试、失败
这些信息在分析 SSL 校验失败、接口异常时，往往已经足够定位问题。
真正需要完整数据时，才考虑重签名
只有在以下情况下，我才会继续往下走：
- 必须确认请求体参数
- 需要验证加密前的数据结构
这时，我会准备一个已脱壳的 IPA，用开发证书重新签名，再配合 HTTPS 暴力抓包重新抓取。
多工具并行，而不是"只靠绕过"
在 SSL 证书认证场景下，我常用的组合包括：
- 抓包大师 HTTPS 暴力抓包：获取真实请求
- 数据流抓包：确认连接行为和流量方向
- 代理抓包工具：辅助判断 TLS 阶段失败位置
每个工具解决的问题不同，把它们放在一起，反而更省时间。
一些容易被忽略的事实
- 不是所有 SSL 校验都"值得绕"
- 能看到请求，不代表可以随意修改
- 安全机制越多，抓包的边界就越清晰
理解这些限制，反而能减少很多无效尝试