第一次遇到这个问题时，我其实挺笃定的。
证书装了、信任也点了、代理设置没问题，按经验来看，HTTPS 理应可以被解密。

但现实是，请求能看到，连接能建立，唯独内容始终是空的，或者直接什么都没有。

如果你也遇到过这种情况，大概会和我当时一样，下意识认为自己漏了某个步骤。

证书这一步，其实并没有想象中关键

在 iOS 抓包过程中，安装并信任证书几乎是每个教程都会强调的关键步骤。
但在真正场景里，这一步往往只是必要条件之一，而不是充分条件。

我后来意识到我们太容易把证书已安装当成问题已经解决的标志。

代理抓包工具看到的，只是它能看到的那部分

当 iOS 安装证书后依然抓不到 HTTPS，我通常会先回到代理抓包工具本身。

代理工具擅长的事情其实很明确：

  • 拦截通过系统代理的 HTTPS 请求
  • 在 TLS 握手可控的前提下进行解密
  • 展示请求结构并支持修改和重放

只要 App 的网络行为符合这些前提条件，证书确实能解决大部分问题。

问题在于，不少 iOS App 并不完全遵循这个前提。

HTTPS Pinning，很多时候不是显式失败

在一些项目中，HTTPS pin 校验已经成为默认配置。
它并不会在抓包工具中报错，也不会在 App 中弹出异常提示。

表现出来的效果往往只有安装了证书，HTTPS 还是抓不到。

如果不考虑这个背景，很容易在证书和代理配置上来回折腾。

当一直抓不到包的时候我就会换一种方式

我通常会在以下情况下，停止继续怀疑证书问题：

  • 不同证书重复安装，结果一致
  • 模拟器可解密，真机不可
  • 同一网络环境下，部分 App 能抓，目标 App 完全不行

这时问题往往不在证书有没有装好，而在于抓包方式是否正确。

换一个方向，比继续换证书更有用

在一次排查中，我决定不再纠结 HTTPS 解密是否成功，而是换了一个更基础的问题：这个 iOS App，在真机上到底有没有完成 HTTPS 通信？

为了确认这一点，我使用了 抓包大师（Sniff Master） 进行设备侧抓包。

设备侧抓包，让证书问题退居二线

抓包大师不依赖系统代理，也不要求 iOS 设备安装或信任任何证书。
它的抓包位置更靠近设备网络层，因此并不受代理证书信任链的影响。

在这个阶段，它的作用非常清晰：验证 HTTPS 请求是否真实发生，而不是是否被代理解密。

当我在设备侧看到稳定的 HTTPS 流量时，之前围绕证书的纠结反而显得多余。

只抓目标 App，避免被系统流量误导

在 iOS 真机上抓包，一个容易被忽略的问题是系统噪音。

系统服务、推送通道、后台同步都会产生 HTTPS 请求。
Sniffmaster 支持只抓取指定 App，判断会清晰很多。

有些问题，根本不在 HTTPS 这一层

继续排查后，我发现部分功能异常并不发生在 HTTPS 请求阶段。

例如：

  • 登录完成后通过 TCP 长连接同步状态
  • 心跳和控制信息不经过 HTTP
  • HTTPS 返回正常，但数据流后续中断

如果只盯着 HTTPS 抓包工具，很容易误判问题位置。

数据流抓包，解释了 HTTPS 看不到的异常

在确认 HTTPS 本身没有明显异常后，我开始关注 TCP 数据流。

抓取数据流的目的，并不是立即解析协议，而是确认：

  • 连接是否成功建立
  • 是否频繁断开
  • 是否存在异常时序

Sniffmaster抓包大师支持 TCP / UDP 数据流抓包，并可导出数据进一步分析。这一步让我意识到：
问题并不发生在证书或 HTTPS 解密上，而是在连接层。

证书失败之后并不适合直接用Wireshark

很多人在遇到证书装了也抓不到 HTTPS 时，会直接建议用 Wireshark。

但从工程实践来看，它更适合在方向已经明确之后使用。
如果问题还停留在“请求到底有没有发出”，直接上 Wireshark 反而会增加判断成本。

拦截和修改，用来验证而不是猜测

当我认为自己已经理解问题发生的位置时，通常会通过修改请求或响应来验证。

例如模拟异常返回、延迟响应，观察 App 的行为变化。
这比反复调整证书或代理配置要直接得多。

Sniffmaster（抓包大师）支持拦截请求、修改请求和响应，并通过脚本处理。
拦截器

经历过几次类似排查之后，我对这个安装证书也抓不到https的看法发生了变化：

  • 证书只是抓包成立的条件之一
  • 抓不到 HTTPS，往往不是证书的问题
  • 抓包路径是否成立，比证书是否安装更关键
  • 多工具协作，才能避免误判

参考教程：https://www.sniffmaster.net/tutorial/zh/1/1.html