第一次遇到这个问题时，我其实挺笃定的。
证书装了、信任也点了、代理设置没问题，按经验来看，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