前几周接了个第三方 SDK 的接入活，对方提供了完整的技术文档和沙箱环境，App 在模拟器和真机上跑得都挺顺畅。结果一到提审前的安全验收环节，对方的生产环境开了 SSL Pinning，Charles 一挂代理直接 TLS 握手失败，连请求日志都看不到。当时跟后端排查了一下午，才发现是证书验证这层挡了路。
做 API 对接和 SDK 集成时碰到这种场景应该不陌生。今天就从实际踩坑的经历出发，聊几种 iOS HTTPS 抓包绕过 SSL Pinning 的方案，以及各自的操作门槛和适用条件。
Charles + 运行时注入 经典套路的局限
Charles 是日常用得最多的 HTTP 抓包工具，平时在手机上装个 CA 证书就能解 HTTPS 流量。但服务端做了 SSL Pinning 之后，客户端只认特定证书或者公钥 hash，Charles 的 MITM 代理证书会被直接拒绝。现象很典型------Charles 控制台刷出一片 "SSLHandshake: Received fatal alert: certificate_unknown"，App 端的所有网络请求全部失败。
解决这个问题的常规思路是用 objection 做运行时 hook，在 NSURLSession 的 didReceiveChallenge 回调里把信任逻辑改成无条件接受。具体操作分几步：找一台能越狱的设备 → 终端装好 frida 工具链 → usb 线连上设备 → objection -g com.example.app explore 进入交互模式 → 执行 ios sslpinning disable。走完这几步，Charles 就能重新正常代理并抓到流量了。
但这个套路有几个实际的限制。首先是越狱设备的获取门槛，iOS 近两三年的越狱工具覆盖率已经很低，iPadOS 的情况更不乐观，团队里专门养一台固定越狱测试机的情况越来越少。其次是每次 iOS 大版本更新后，越獄工具往往要等几个月才能跟上。如果你手头的项目在 iOS 17 上跑，而越狱只支持到 iOS 16，这条路就暂时走不通。
Proxyman + SSL Kill Switch 替代方案也有相同瓶颈
Proxyman 的 macOS 客户端界面比 Charles 现代不少，请求筛选和过滤规则的可视化配置做得更顺手。配合 iOS 端的 SSL Kill Switch 2 这个 tweak，在 Cydia 里装完就能全局禁用证书校验，不需要在代码层做额外配置。从操作体验上说，这个组合确实比 frida + objection 那一套要省事。
但问题还是卡在越狱上。SSL Kill Switch 本质上是一个 Cydia Substrate 插件，依赖越狱环境来注入进程。如果不越狱但有企业签名证书，可以走 Frida Gadget 方式重新打包 App 再侧载。流程大致是：解压 ipa 包 → 把 Frida Gadget.dylib 复制到 Frameworks 目录 → 用 install_name_tool 改依赖路径 → 重新签名整个应用 → 用 xcode 或 ios-deploy 侧载到设备。这套流程走一遍大概二十分钟，但每次提测新版本都得重新来一次，持续迭代的节奏下，每周花在重签上的时间累积起来不少。
SniffMaster 设备直连 不走代理通道的抓包方案
后来换 SniffMaster 试了试，最核心的区别在于这个工具不依赖 HTTP 代理中转。iOS 设备通过 USB 线连上 Mac，打开 SniffMaster 之后，左侧设备列表会自动识别出连接的 iPhone，勾选设备后直接点击开始抓包。不需要在手机 Wi-Fi 设置里配置代理 IP 和端口，不需要安装 HTTPS 描述文件，也不用开启 VPN 做网络桥接。流量走的是 USB 底层的通信通道，客户端是否信任某个代理 CA 都不影响最终结果，所以 SSL Pinning 在这种直连式抓包方式下不起作用。
实际操作时我勾选了"只抓指定 App"的过滤选项，避免系统后台服务和 push 通知的流量干扰。跑了五分钟左右，之前 Charles 上报错的 HTTPS 请求全部以明文形式显示出来------请求头的 Authorization 字段、URL 里带的 query 参数、JSON 格式的响应体都能正常读取，跟在 Charles 里看裸 HTTPS 请求时的体验一致。后续测试阶段，我用拦截器在请求到达服务端之前改了某个 Header 字段，验证后端是否有做参数校验。另外在 JavaScript 脚本里写了一段正则替换逻辑，把响应内容中 CDN 图片的域名指向测试环境地址，前端资源加载调试省了不少翻来覆去的打包部署时间。
数据流抓包方面，SniffMaster 也支持 TCP 和 UDP 层面的抓取。UI 里每条数据流的方向和协议类型都会自动识别标注，mdns、http、https 这些常见协议不用手动配。如果 App 用了自定义的二进制协议，可以在分析器里按偏移量标注字段含义来做解析。数据还能导出为 pcapng 格式，用 Wireshark 打开做底层分析，排查偶发的连接超时和 TCP 重传问题时能派上用场。
选择搭配的思路
日常调试 HTTP 接口和 API 参数时，Charles 或 Proxyman 配合正常的 CA 证书安装，社区文档和现成方案足够覆盖大部分场景。遇到 SSL Pinning 又没有越狱设备可用时，SniffMaster 的设备直连方案直接绕过了证书验证这个环节------不需要额外做运行时 hook，也不需要操心证书信任链。需要排查 TCP 层面的连接问题或分析自定义二进制协议时，把 Wireshark 加进来做联动分析会更全面。
我个人的做法是备两套抓包方案放在手边，代理型和非代理型各一个，根据项目当期的安全限制来灵活切换，基本能覆盖 iOS 端开发中遇到的大部分抓包需求。