我第一次认真面对 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 请求本身没有任何异常。 真正的问题在于，App 在 HTTPS 返回后，通过 TCP 长连接同步状态。
代理抓包工具只能看到"接口成功"，但功能仍然异常。 设备侧数据流抓包却能看到连接频繁中断。
这类问题，如果只纠结 SSL Pinning，很容易走偏。
数据流分析，让问题变得"可定位"
抓包大师支持查看 TCP / UDP 数据流，并能导出原始数据。 在这个阶段，我并不急着解析协议，而是关注几个指标：
- 连接是否持续
- 数据包大小是否异常
- 是否存在规律性的断开
这些信息，可以直接指导下一步是去看客户端逻辑，还是服务端行为。
拦截和修改，更像验证假设
当我已经大致判断问题原因时，才会用到请求/响应修改。
比如：
- 模拟接口延迟
- 修改返回字段，观察客户端分支逻辑
抓包大师支持通过拦截器和脚本完成这些操作，更适合在真机环境下验证判断，而不是用来"突破安全"。、 