第一次做 iOS 抓包时，我以为只要装一个工具、配个证书就能解决问题。
真正开始调接口之后才意识到：抓不抓得到包，往往取决于场景，而不是工具。
不同的 App、不同的网络、不同的系统版本，都会直接影响抓包方式的选择。
iOS 抓包工具通常解决的是哪几类问题
在实际工作中，我把 iOS 抓包需求分成几类，而不是直接选工具：
- 想看 HTTPS 请求内容
- 想确认请求有没有真正发出
- 想分析 Socket / TCP 层面的通信
- 想在不改代码的情况下验证客户端逻辑
明确这一点，工具组合自然就出来了。
基于代理的抓包：依然是最常用的入口
对于大多数业务接口调试，代理模式依然是最省事的。
常见选择包括：
- Charles / Fiddler：老牌、成熟，配置稍繁琐
- 抓包大师（Sniffmaster）：代理 + 数据流模式组合，覆盖面更广
这些工具的共同点是：
都依赖 HTTPS 代理 + 证书信任。
以抓包大师为例的代理抓包实践
在 Windows 或 macOS 上，如果需要抓 iPhone 的 HTTPS 请求，我通常会这样做：
- 用 USB 连接 iPhone 与电脑
- 打开抓包大师，在设备列表中选中当前 iOS 设备
- 切换到 HTTPS 代理抓包模式
如果是首次使用，软件会提示安装描述文件和证书。
证书信任完成后，只要按照提示配置 Wi-Fi 代理即可。
这个流程和 Charles 本质一致，但少了手动导证书、拷文件的步骤。
什么时候代理抓包不够用
并不是所有 iOS App 都会乖乖走系统代理。
遇到下面几种情况时，代理工具往往会"看不见"请求：
- App 使用自定义网络库
- 走直连 Socket / TCP
- 使用了 SSL Pinning
这时，再怎么检查证书和代理配置，都不会有结果。
数据流抓包，解决的是"有没有流量"这个问题
当我怀疑请求根本没经过代理时，会直接切到数据流抓包。
这类工具关注的是：
- 设备真实发出的网络数据
- 不区分 HTTP / HTTPS / TCP / UDP
- 不依赖证书
在抓包大师Sniffmaster中，只需要：
- 通过 USB 连接 iOS 设备
- 选择"数据流抓包"功能
- 点击开始
如果只关心某个 App，可以在开始前选择 App 进行筛选。
这一层通常用来回答一个很基础的问题：
这个 App 到底有没有在联网？
多工具并行，比"换工具"更有效
在复杂场景下，我经常会并行使用工具：
- 代理抓包工具：看 HTTP 结构和参数
- 数据流抓包：确认底层通信是否存在
- 拦截器：验证客户端处理逻辑
比如：
代理抓不到包，但数据流里有 TCP 流量，基本可以判断是绕过了系统代理。
拦截器在 iOS 抓包里的实际用途
当请求已经能被代理捕获，但逻辑依然不清晰时，拦截器就派上用场了。
通过拦截并修改响应，可以直接验证：
- 客户端是否依赖某个字段
- 错误分支是否真的被触发
- UI 是否由接口数据驱动
抓包大师Sniffmaster内置的拦截器支持用 JS 修改请求和响应，这在不改代码的前提下非常实用。
iOS 抓包工具没有全能解法
在我看来，选工具这件事本身并不复杂，复杂的是场景判断。
- 能代理，就先代理
- 代理不行，就看数据流
- 数据流有了，再谈协议和逻辑
工具只是手段，判断路径才是关键。