很多 iOS 抓包问题，表面看是抓不到包，但真正定位下来，问题往往出在对 HTTPS 协议本身的理解不够细。
我第一次意识到这一点，是在一次接口调试中，代理已配、证书已装、App 正常联网，但抓包工具里什么都没有。
当时我还在反复检查证书是否信任，后来才发现，请求根本没有进入我以为的那次 TLS 会话。
TLS 握手不是一行日志，而是一段过程
在抓包之前，我现在都会先画一条简单的路径：
- TCP 是否建立
- TLS ClientHello 是否发出
- ServerHello 是否返回
- 证书是否被客户端接受
如果你抓不到 HTTPS 内容，通常不是HTTPS 被加密了，而是你没抓到在 TLS 的位置上的包。
用 Wireshark，看握手是否真实发生
在 Windows 或 Mac 上，我会先用 Wireshark 抓一小段流量，只看三个点：
- 是否有对应 IP 的 TCP 三次握手
- 是否出现 ClientHello
- 握手是否在 ServerHello 后被中断
这一步不解密内容，只确认：TLS 有没有真正跑起来。
如果这里都没有，说明问题不在证书，而在网络路径。
iOS 上的 HTTPS，为什么代理有时完全无效
在 iOS 上，HTTPS 是否走系统代理，取决于几个现实条件：
- 使用的网络栈是否遵循系统设置
- 是否启用了证书绑定（SSL Pinning）
- 是否使用了自定义 TLS 实现
这也是为什么同一个 App：
- 系统接口能抓到
- 业务接口完全不可见
代理抓包，验证是否走系统信任链
在可以走系统代理的场景下，代理抓包依然是效率最高的方式。
无论是 Charles、Proxyman，还是抓包大师的 HTTPS 代理模式，本质都是：
- 中间人证书插入系统信任链
- 客户端接受该证书
- TLS 会话在代理处被解密
使用抓包大师做代理抓包时，我关注的不是界面
我更关心三个结果：
- ClientHello 是否被代理截获
- 服务器证书是否被替换
- App 是否继续发送应用层数据
抓包大师在这一步的优势，是减少了证书和代理配置的手动步骤，但判断逻辑并没有变化。
如果在这里 HTTPS 请求能完整出现，问题基本已经解决一半。
当 TLS 握手成功，但数据仍不可读
有时你会看到一个很“迷惑”的现象：
- TLS 握手完成
- 证书校验通过
- 请求存在，但内容不可读或异常
这类问题，往往和 TLS 双向验证、Pin 校验、应用层二次加密 有关。
这时候，再纠结代理已经没有意义。
数据流抓包，用来确认加密前发生了什么
在 iOS 上，我会切换到设备级的数据流抓包。
抓包大师的数据流抓包模式，不依赖证书，也不要求代理：
- 通过 USB 直接获取设备网络流
- 能看到 TCP、UDP、部分协议特征
- 可筛选到指定 App
这一层的目标只有一个：确认通信是否真实存在，以及发生在什么时间点。
TLS 之后，调试的重点反而回到客户端
当你已经确认：
- TCP 建立
- TLS 成功
- 请求确实发出
但业务仍异常，那就不再是“抓包问题”，而是客户端逻辑问题。
拦截器，验证假设比改代码更快
在代理可用的前提下，我通常会用拦截器做一件事，人为制造一个异常响应。
例如：
- 修改响应状态码
- 改写返回字段
- 延迟响应
抓包大师的拦截器支持用 JS 直接改请求和响应，这一步的价值不在“修改数据”，而在于验证客户端对 TLS 之后数据的处理逻辑。
HTTPS、TLS、证书，其实是一条连续流程中的
HTTPS 抓包调试并不是某个工具的技巧，而是对一整条流程的判断能力：
- 握手有没有发生
- 证书是否被接受
- 数据在哪一层消失
工具只是方向不同，解决的都是不同阶段的问题。