在调试接口时，我第一次发现 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 不走代理的通信场景