很多 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 抓包调试并不是某个工具的技巧，而是对一整条流程的判断能力：

• 握手有没有发生
• 证书是否被接受
• 数据在哪一层消失

工具只是方向不同，解决的都是不同阶段的问题。