第一次遇到这个问题时，我其实挺笃定的。
证书装了、信任也点了、代理设置没问题，按经验来看，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，往往不是证书的问题
- 抓包路径是否成立，比证书是否安装更关键
- 多工具协作，才能避免误判