在移动端开发和接口调试中，Fiddler 是很多开发者的常用工具。它轻量、功能直观，尤其在 Windows 平台应用广泛。但在调试 iOS 应用时，经常会遇到这样的问题：配置正确，界面却空白，抓不到包。

本文将结合实际经验，从问题排查到替代方案，带你系统梳理如何应对 Fiddler 抓包失败。

一、Fiddler 抓不到包的常见原因

1. 代理配置错误
   • 手机 Wi-Fi 的 HTTP 代理没有正确指向电脑的局域网 IP 和监听端口（默认 8888）。
   • 手机和电脑不在同一网络。
2. HTTPS 解密未启用
   • Fiddler 默认不解密 HTTPS，需要手动勾选 “Decrypt HTTPS traffic”。
   • 未将目标域名加入解密规则。
3. 证书未被完全信任
   • 在 iOS 中，仅安装证书还不够，还需在 “证书信任设置” 中手动打开信任。
4. SSL Pinning 或双向认证
   • 很多应用出于安全考虑，强制校验证书指纹，导致中间人代理直接失效。
5. 端口冲突或系统限制
   • 防火墙或 VPN 阻止了 Fiddler 的监听端口。
   • 电脑上同时运行其他代理软件，引发端口占用冲突。

二、逐步排查流程

1. 确认代理是否连通
   • 在 Safari 打开一个 HTTP 网站，若 Fiddler 显示请求，说明代理正常。
2. 检查 HTTPS 解密
   • 打开 Options → HTTPS，勾选 “Decrypt HTTPS traffic”。
   • 添加目标域名，或使用 * 捕获全部域名。
3. 确认证书信任
   • 安装证书后，在 iOS “设置 → 通用 → 关于本机 → 证书信任设置” 中打开信任。
4. 判断是否遇到 SSL Pinning
   • 如果只有特定 App 无法抓包，且表现为 HTTPS 握手失败，多半是 Pinning。

三、替代工具与解决方案

当确认 Fiddler 无法突破时，可以考虑以下替代工具：

1. Sniffmaster（抓包大师）

• USB 直连 iOS，无需 Wi-Fi 代理或证书安装。
• 自动解密 HTTPS，可绕过 SSL Pinning 和双向认证。
• 支持仅抓取指定 App，避免系统流量干扰。
• 拦截器可用 JavaScript 修改请求与响应。
• 支持导出 PCAP 文件，结合 Wireshark 深度分析。

2. Charles

• 跨平台支持好，界面友好。
• 在 iOS 上操作更直观，配置简单。
• 不足之处是遇到 SSL Pinning 时依然受限。

3. mitmproxy

• 命令行抓包工具，支持 Python 脚本扩展。
• 能模拟接口异常、延迟、错误响应，适合自动化测试。
• 对 Pinning 的支持有限，但在测试 Mock 场景中很强大。

4. Proxyman

• 专为 macOS 设计，界面类似 Charles。
• 支持 HTTPS 解密、规则配置和过滤。
• 对 SSL Pinning 仍然无能为力，但体验简洁流畅。

5. Wireshark

• 专注于底层网络分析，能捕获 TCP、UDP、TLS 握手等。
• 无法直接解密 HTTPS，但可确认握手是否成功、连接是否被中断。
• 与 Sniffmaster 搭配使用效果更佳，能还原完整抓包链路。

四、工具组合的最佳实践

在不同场景下，可以根据需求组合使用工具：

五、实战经验总结

• 代理和证书配置问题最常见：八成的抓不到包问题都出在这一步。
• SSL Pinning 是拦路虎：传统代理型工具在这里普遍失效。
• 直连型工具是关键补充：Sniffmaster 可以无视 Pinning，解决高安全场景的抓包需求。
• 多工具协作更高效：抓包 → 解密 → 修改 → 分析，形成完整链路。

Fiddler 作为常见的抓包工具，在大多数情况下足够好用。但一旦遇到 SSL Pinning 或双向认证，就会束手无策。
解决的思路应该是：先排查基础配置 → 确认是否为 Pinning → 根据场景切换合适的替代工具。
其中，Sniffmaster 可以快速测试，而 Charles、mitmproxy、Proxyman、Wireshark 则在不同场景下各有用武之地。