在调试接口时，我第一次发现 Fiddler抓不到包这个问题，并不是在 iOS App 上，而是在一台 Windows 电脑上。
Fiddler 已经启动，左下角显示 Capturing，但请求列表始终是空的。这个状态代表着当前流量没有进入 Fiddler 的代理通道。
从最简单的流量开始验证
我做的第一件事是打开浏览器，访问一个普通的 HTTP 网站。
- 页面可以正常加载
- Fiddler 列表仍然没有任何请求
这一步的结果可以告诉我们系统代理并没有被 Fiddler 接管。
在这种状态下，继续配置 HTTPS 证书不会改变抓包结果，因为流量根本没有经过 Fiddler。
代理路线被谁占用了
接下来检查的是系统环境本身：
- 是否存在 VPN
- 是否启动过 Clash、Surge、v2rayN
- 是否有开发工具修改过全局代理
在关闭这些程序后，重新启动 Fiddler，并以管理员权限运行，再次访问 HTTP 网站，请求开始出现在列表中。
到这里，Fiddler 的基本工作路径已经成立。
HTTPS 能看到域名，但没有内容
代理恢复后，HTTPS 请求开始出现，但点开后只有 CONNECT，或者只显示域名，没有请求体。
这时进入证书相关的排查阶段：
- Fiddler 是否成功生成 Root 证书
- 证书是否被系统标记为“受信任”
- 浏览器是否使用系统证书存储
在 Windows 上，可以直接在证书管理器中确认证书状态，而不是反复点击 Fiddler 的“Install Certificate”。
当目标从 Web 变成 iOS App
将同样的 Fiddler 用在 iPhone 上时，问题出现了变化。
- Safari 访问 HTTPS 网站可以被完整抓取
- iOS App 完全没有任何请求
这两个现象同时存在，说明：
- Wi-Fi 代理设置是生效的
- 证书链路是可用的
- App 的网络请求并未走系统代理
继续在 Fiddler 上调整设置，并不会让 App 的请求突然出现。
切换工具验证通信是否真实存在
为了确认 App 是否真的在发起请求，我改用 Wireshark 抓取同一时间段的 TCP 流量。
在 Wireshark 中可以看到：
- DNS 查询
- TCP 建连
- TLS ClientHello
说明 App 的网络通信确实存在，只是绕过了代理。
在 iOS 设备上抓包
这个阶段，代理型工具已经无法覆盖需求，于是我改用 抓包大师（Sniff Master） 直接对 iOS 设备进行抓包。
设备通过 USB 连接电脑，在抓包大师中选择对应的 iOS 设备后，可以直接进行 HTTPS 抓包，而不需要在手机上配置代理或手动安装证书。
在这种模式下，请求数据开始完整出现，包括请求体和响应内容。
多工具并行，而不是互相替代
最终这次排查中，各个工具承担的角色非常清晰：
- Fiddler：验证代理是否生效、调试 Web 请求
- Wireshark：确认底层网络通信是否真实发生
- 抓包大师（Sniff Master）：处理 iOS App 不走代理的通信场景