iOS 如何绕过 ATS 发送请求，iOS调试-抓包大师使用教程

在调试 iOS 网络问题时，一开始并不会想到 ATS 绕过。
一般是来自一个可复现的现象，请求根本没有到达服务器，这时候我们才会去处理 ATS。

比如，当你在服务端后台看不到访问记录，而客户端手机app又没有明确报错。

先确认阻断发生在哪一层

ATS 的拦截发生在客户端网络栈内部。
在继续之前，需要先判断请求是否已经离开设备。

一个简单的验证方式是切断网络：

关闭 Wi-Fi / 蜂窝网络
触发 App 的目标操作
观察 UI 是否出现加载失败或超时提示

如果在网络关闭状态下表现一致，说明当前操作并未触发网络请求。
如果表现发生变化，说明请求确实存在，下一步才有意义。

使用代理工具确认 ATS 是否阻断在 HTTPS 建连前

当请求存在时，可以先用代理工具验证是否走系统网络。

代理验证步骤

在电脑上启动代理工具（如 Charles / Fiddler）
iPhone 与电脑处于同一局域网
在 Wi-Fi 设置中配置代理地址和端口
在 iOS 上安装并信任代理证书
用 Safari 访问一个 HTTPS 页面

如果 Safari 请求能被完整抓取，说明：

系统代理生效
HTTPS 解密可用

此时再触发 App 请求，观察代理工具中的行为。

代理中没有 App 请求，意味着什么

当 Safari 流量可见，而 App 完全没有任何记录时，可以得出一个结论：

该 App 的网络请求没有经过系统代理。

在 ATS 场景中，这种情况常见于：

App 使用自定义网络栈
SDK 内部绕过系统网络配置
ATS 直接在 App 内部阻断了请求创建

继续在代理工具中调整设置，并不会改变这个结果。

用数据流确认请求是否被 ATS 阻断

在放弃代理之前，可以使用网络层工具确认是否存在底层通信。

观察以下现象即可判断：

是否有 DNS 查询
是否有 TCP 建连
是否有 TLS ClientHello

如果这些都不存在，说明请求在创建阶段就被拦截，ATS 仍然是主要怀疑对象。

在自有 App 中处理 ATS 的实际路径

在你有 App 控制权的前提下，ATS 的处理方式并不复杂，但需要明确修改位置。

常见操作路径

打开项目的 Info.plist
检查 NSAppTransportSecurity 配置
确认是否存在以下项：
- NSAllowsArbitraryLoads
- NSExceptionDomains

修改完成后，重新构建并安装 App，再次触发网络请求。

这一步的验证标准很明确：
之前完全没有网络行为的请求，是否开始建立连接。

ATS 放开后，如何确认 HTTPS 数据是否完整

当请求开始发出后，下一步是确认是否能抓到 HTTPS 数据。

如果代理工具能看到 App 请求并成功解密，说明：

ATS 已不再阻断
HTTPS 校验允许中间人介入

如果代理仍然抓不到，但数据层出现连接，可以切换抓包路径。

设备级抓包用于绕过代理路径限制

当 ATS 已放开，但 App 仍不走系统代理时，可以使用设备抓包工具。

使用抓包大师（Sniff Master）的设备抓包

在 iOS 设备通过 USB 连接电脑的情况下：

选择对应的 iOS 设备
按提示完成驱动与描述文件安装
进入 HTTPS 暴力抓包相关模式
启动抓包并触发 App 网络请求

这一模式不依赖 Wi-Fi 代理，也不要求在手机上信任抓包证书。
选择https暴力抓包

通过 App 级筛选减少干扰

设备级抓包会包含大量系统请求。

在抓包大师中：

使用「选择 App」功能
仅保留目标应用的数据
再次触发请求

这样可以快速定位业务接口，而不是在系统流量中手动筛选。
app选择

判断数据不完整的原因

在抓包结果中，如果出现以下现象：

URL 与 Header 可见
请求体或响应体为空

说明 HTTPS 已被捕获，但 App 并未使用 iOS 开发证书签名。

这类情况需要：

获取 IPA
使用 iOS 开发证书重新签名
如 IPA 加密，先完成脱壳
安装重签后的 App
重新进行抓包

完成后，数据即可完整显示。

拦截与修改的上限

需要明确的是：

请求 / 响应拦截器仅存在于代理抓包模式
设备级 HTTPS 抓包只负责采集与解密
在需要修改请求或响应时，必须回到代理路径

将这两类能力区分清楚，可以避免在错误模式下寻找不存在的功能。

参考链接：https://www.sniffmaster.net/tutorial/zh/2/2.html