在调试 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配置 - 确认是否存在以下项：
NSAllowsArbitraryLoadsNSExceptionDomains
修改完成后，重新构建并安装 App，再次触发网络请求。
这一步的验证标准很明确：
之前完全没有网络行为的请求，是否开始建立连接。
ATS 放开后，如何确认 HTTPS 数据是否完整
当请求开始发出后，下一步是确认是否能抓到 HTTPS 数据。
如果代理工具能看到 App 请求并成功解密，说明：
- ATS 已不再阻断
- HTTPS 校验允许中间人介入
如果代理仍然抓不到，但数据层出现连接，可以切换抓包路径。
设备级抓包用于绕过代理路径限制
当 ATS 已放开，但 App 仍不走系统代理时，可以使用设备抓包工具。
使用抓包大师（Sniff Master）的设备抓包
在 iOS 设备通过 USB 连接电脑的情况下：
- 选择对应的 iOS 设备
- 按提示完成驱动与描述文件安装
- 进入 HTTPS 暴力抓包相关模式
- 启动抓包并触发 App 网络请求
这一模式不依赖 Wi-Fi 代理，也不要求在手机上信任抓包证书。
通过 App 级筛选减少干扰
设备级抓包会包含大量系统请求。
在抓包大师中：
- 使用「选择 App」功能
- 仅保留目标应用的数据
- 再次触发请求
这样可以快速定位业务接口，而不是在系统流量中手动筛选。
判断数据不完整的原因
在抓包结果中，如果出现以下现象：
- URL 与 Header 可见
- 请求体或响应体为空
说明 HTTPS 已被捕获，但 App 并未使用 iOS 开发证书签名。
这类情况需要：
- 获取 IPA
- 使用 iOS 开发证书重新签名
- 如 IPA 加密，先完成脱壳
- 安装重签后的 App
- 重新进行抓包
完成后，数据即可完整显示。
拦截与修改的上限
需要明确的是：
- 请求 / 响应拦截器仅存在于代理抓包模式
- 设备级 HTTPS 抓包只负责采集与解密
- 在需要修改请求或响应时，必须回到代理路径
将这两类能力区分清楚，可以避免在错误模式下寻找不存在的功能。