在调试 App HTTPS 接口时，最容易走偏的一步，就是一上来就安装证书、配置代理。 但 HTTPS 能不能被抓到，其实是请求是否走到了工具的位置。
所以在真正抓包之前，我会先做一件看起来无关、但非常关键的事情，确认 App 的请求是怎么发出去的。
第一步，确认请求是否真实存在
不借助任何抓包工具，也可以先判断请求是否已经发出。
操作方式很简单：
- 打开 App，进入触发网络请求的页面
- 关闭 Wi-Fi 或蜂窝网络
- 重复同样的操作
如果页面状态、错误提示或加载行为发生变化，说明这一步确实涉及网络请求。 如果行为完全一致，抓包之前需要先确认业务逻辑是否真的走到了请求阶段。
第二步，用代理工具验证系统网络路径
当确认请求存在后，可以先使用代理型工具验证最常见的方法检测App 是否走系统代理。
操作流程
- 在电脑上启动代理工具（如 Charles / Fiddler）
- iPhone 与电脑连接同一局域网
- 在 iOS 的 Wi-Fi 设置中填写代理地址与端口
- 在手机上安装并信任代理证书
- 打开 Safari 访问一个 HTTPS 网站
如果 Safari 请求能完整显示，说明代理链路与证书配置是有效的。
Safari 能抓到，App 抓不到，说明了什么
当 Safari 的 HTTPS 请求可见，而 App 没有任何数据出现时，可以直接得出该 App 的网络请求没有经过系统代理。
这意味着继续在代理工具中调整设置，不会让 App 的请求突然出现。 此时需要切换抓包方式，而不是继续优化同一条路径。
用底层数据确认请求是否被绕过
在放弃代理之前，可以用网络工具确认请求是否已经离开设备。
观察的不是 HTTPS 内容，而是请求本身：
- 是否有 DNS 查询
- 是否建立 TCP 连接
- 是否出现 TLS ClientHello
如果这些都存在，说明请求已经发出，只是代理工具抓不到
切换到手机 HTTPS 抓包
当确认 App 绕过系统代理后，需要使用不依赖代理的抓包方式。
使用抓包大师（Sniff Master）进行 App HTTPS 抓包
抓包大师提供设备 HTTPS 抓包能力，直接从 iOS 设备获取网络数据。
操作步骤集中且明确：
- 使用 USB 将 iPhone 连接电脑
- 保持设备解锁并信任电脑
- 启动抓包大师并选择对应的 iOS 设备
- 按提示完成驱动与描述文件安装
- 进入 HTTPS 暴力抓包相关模式并开始抓包
整个流程不需要在手机上设置 Wi-Fi 代理，也不需要手动信任抓包证书。
通过 App 级筛选减少无关流量
设备级抓包启动后，会同时捕获系统服务与后台进程的请求。
在抓包大师中，可以：
- 点击「选择 App」
- 仅勾选目标应用
- 再次触发业务操作
这样可以在抓包列表中直接看到与当前操作对应的 HTTPS 请求。
判断 HTTPS 数据是否完整
在抓包结果中，可以通过一个直观现象判断当前状态：
- 能看到 URL 和 Header
- 请求体或响应体为空
这表示 HTTPS 已被捕获，但 App 未使用 iOS 开发证书签名。
常见于：
- App Store 下载的应用
- 系统自带 App
此时工具本身没有异常，数据缺失来自平台限制。
需要完整请求体时的处理方法
如果调试目标需要查看请求体或响应体，操作方式是：
- 获取目标 App 的 IPA
- 使用 iOS 开发证书重新签名
- 如 IPA 加密，先完成脱壳
- 安装重签后的 App
- 重新进行 HTTPS 抓包
完成后，HTTPS 请求与响应内容即可完整展示。
拦截与修改的上限
在 App HTTPS 抓包过程中，需要明确功能上限：
- 代理抓包模式
- 可使用请求 / 响应拦截器
- 可修改 Header、Body、状态码
- 设备 HTTPS 暴力抓包
- 只负责采集与解密
- 不提供拦截或修改能力
在需要验证客户端逻辑分支时，需要明确回到代理路径。
把 App HTTPS 抓包拆来看开
完整的 App HTTPS 抓包流程，可以拆成：
- 代理工具：验证是否走系统网络
- 网络层工具：确认请求是否真实存在
- 设备抓包：获取真实 HTTPS 数据
- 重签名：解决数据不完整问题
每一步都有明确的判断标准，而不是反复尝试同一配置。
