事情起因并不复杂，一个 iOS 版本更新后，线上接口偶发失败，日志里只有模糊的错误码。代码回滚、重试都没法稳定复现，最后只能回到最原始的方式——看真实请求。

问题是，这个 App 已经上线，既不能加日志，也不能改网络层。
剩下的选择只有在真机上抓包。

在准备苹果手机抓包的时候，先别急着选工具

刚开始我也犯过一个错误，先找工具，再想怎么用。

后来发现更合理的顺序应该是反过来的——
先判断网络路径，再决定抓哪一层。

在苹果手机上，抓包需求大致会落在三个层面：

• HTTPS 请求是否正确发出
• 请求是否被系统代理接管
• 客户端对响应的处理逻辑

不同层面，用到的工具并不一样。

代理抓包仍然是最常用的一条路

在接口联调、参数校验这类场景里，HTTPS 代理抓包依然是首选。

Charles、Fiddler、Proxyman 都是这一类工具。
抓包大师的代理模式，本质上也是走系统代理，只是把证书和配置步骤做了整合。

在苹果手机上使用抓包大师做代理抓包的过程

我这次是在 Windows 上操作，流程大致如下：

• 用 USB 将 iPhone 连接电脑，保持解锁
• 打开抓包大师，在设备列表中选择当前 iOS 设备
• 切换到 HTTPS 代理抓包模式

第一次使用时，软件会引导安装描述文件和证书。
证书安装完成后，只需要在 iOS 的 Wi-Fi 设置中，把代理模式切换为手动，填入软件提示的地址和端口。

整个过程和 Charles 的原理一致，只是省掉了手动导出证书的步骤。

什么时候你会发现抓不到包

很多时候开始抓包之后就出现问题

比如这次遇到的情况是：

• 系统接口能看到
• 业务接口完全没有
• App 内请求看起来消失了

这种情况，基本可以判断的是 App 没走系统代理。

这时，继续折腾代理已经没有意义

如果请求本身绕过了系统代理，再怎么检查证书、端口，结果都不会变。

我通常会直接换思路，去看 设备层的数据流。

数据流抓包，用来确认有没有在通信

在抓包大师里，选择数据流抓包模式：

• 同样通过 USB 连接 iPhone
• 不需要配置代理
• 不依赖证书

开始抓取后，可以看到设备真实发出的 TCP、UDP 流量。

如果只关心某个 App，可以在开始前选择目标应用，过滤掉系统噪音。

这一层不关心 HTTP 结构，只回答一个问题：
这个 App 到底有没有在联网。

多工具协作，比换工具更重要

在这次问题里，我实际用的是一套组合：

• 代理抓包：确认哪些接口走系统网络
• 数据流抓包：确认隐藏请求是否存在
• 拦截器：验证客户端处理逻辑

没有哪一步是多余的。

拦截器在调试中的真实用途

当我重新在代理里捕获到部分请求后，下一步并不是马上改代码，而是先用拦截器做验证。

在抓包大师的代理界面右侧，可以打开拦截器，通过 JS 修改请求或响应。

比如：

• 强行返回错误状态码，看客户端分支
• 修改字段值，确认 UI 依赖
• 重定向请求，验证网络路径

这种方式的好处是 成本极低，几分钟就能验证一个假设。

苹果手机抓包抓不到，其实可以不断换方向

回过头来看，这次问题并不复杂。
复杂的是，一开始把抓包当成了一个动作，而不是一个过程。

• 抓不到 HTTPS，不一定是证书问题
• 看不到请求，不一定是工具问题
• 工具失效，往往是路径判断错了