我第一次认真面对 SSL Pinning，并不是因为想研究安全，而是因为一个接口问题卡了两天。

App 在测试环境一切正常，到了准生产环境，功能偶尔失效。日志没报错，接口返回码是 200，但页面状态明显不对。
习惯性打开抓包工具，却发现 HTTPS 请求连内容都看不到。

证书装了，信任也点了，该做的都做了。
这时候再说抓不到包，已经有点不准确了，更像是抓包路径本身被绕开了。

先确认一件事：你面对的是 Pinning，还是别的问题

在很多案例里，SSL Pinning 绕过这个判断来得太早。

我通常会先做三件很具体的事：

  • 在模拟器上跑一遍，看同一接口是否可抓
  • 在真机上切不同网络环境（Wi-Fi / 热点），观察行为是否变化
  • 打开最基础的网络日志，确认请求是否真的发出

如果这些信息彼此矛盾，问题往往还没到 Pinning 这一层。

代理抓包失败，其实已经给了线索

当 Charles、Fiddler 这类代理工具表现为：

  • 只能看到 CONNECT
  • TLS 握手直接失败
  • 或者请求完全不出现

而 App 本身又能正常工作时，基本可以确认客户端对证书链有额外校验逻辑。

这时继续折腾代理设置，意义不大。

换一个问题问法：不解密，能不能继续查

在这个节点，我会刻意放弃“马上看到明文”的目标，而是转向更基础的问题：

这个请求在什么时间发出？
发了几次？
是否存在重试或异常断开？

这类问题，不依赖 HTTPS 解密。

设备侧抓包，是继续推进的第一步

我在这一步使用 **抓包大师（Sniff Master）**的其中暴力抓取HTTPS，这并不是为了破解什么，而是为了确认通信行为是否存在。

暴力抓取HTTPS无需设置代理即可获取iOS设备上的HTTPS请求，并且能够自动解密HTTPS请求。要求被抓取的App必须使用iOS开发证书签名；

对于未重签名的应用（如iOS系统应用或部分第三方应用），只能看到请求地址和请求头，无法查看请求和返回的body部分。

软件的PIN码检测和双向证书验证无法阻止暴力抓包，也无法感知暴力抓包的使用。

具体做法很简单：

  • iOS设备通过USB连接电脑，选择要抓包的设备后，在功能选择区选择HTTPS暴力抓包，然后在暴力抓包界面点击开始按钮。

  • 如果只关注某个App，可以点击选择App按钮进行过滤。更多关于暴力抓包的设置与使用查看暴力抓包详细教程

不需要设置代理，也不需要让系统信任任何证书。

如果在这里能看到稳定的数据流，至少可以确认：Pinning 没有阻断通信，只是阻断了中间人解密。
https暴力抓包

只看 HTTPS 层，很容易误判问题位置

有一次问题中，HTTPS 请求本身没有任何异常。
真正的问题在于，App 在 HTTPS 返回后，通过 TCP 长连接同步状态。

代理抓包工具只能看到“接口成功”，但功能仍然异常。
设备侧数据流抓包却能看到连接频繁中断。

这类问题，如果只纠结 SSL Pinning，很容易走偏。

数据流分析，让问题变得“可定位”

抓包大师支持查看 TCP / UDP 数据流，并能导出原始数据。
在这个阶段，我并不急着解析协议，而是关注几个指标：

  • 连接是否持续
  • 数据包大小是否异常
  • 是否存在规律性的断开

这些信息，可以直接指导下一步是去看客户端逻辑，还是服务端行为。

拦截和修改，更像验证假设

当我已经大致判断问题原因时，才会用到请求/响应修改。

比如：

  • 模拟接口延迟
  • 修改返回字段，观察客户端分支逻辑

抓包大师支持通过拦截器和脚本完成这些操作，更适合在真机环境下验证判断，而不是用来“突破安全”。、
拦截器