在接口调试和网络分析中，Fiddler 一直是开发者常用的抓包工具，尤其是在 Windows 平台上。但如果你也和我一样，遇到过 “明明配置了代理，Fiddler 却抓不到包” 的情况，那你一定明白这种无力感。

本文结合实战经验，从常见排查方法到替代方案，完整梳理当 Fiddler 抓包失败时的处理思路。

一、为什么 Fiddler 会抓包失败？

1. 代理配置错误 很多开发者第一次使用 Fiddler 时，忘记勾选 Allow remote computers to connect，或者没有把手机 Wi-Fi 的 HTTP 代理指向电脑 IP 和端口（默认 8888）。这会直接导致流量无法进入 Fiddler。

2. HTTPS 解密未启用 默认情况下，Fiddler 并不会解密 HTTPS。如果没有在 Tools → Options → HTTPS 中勾选 “Decrypt HTTPS traffic”，你会发现只能看到 CONNECT 请求，看不到具体业务数据。

3. iOS 证书未信任 在 iPhone 或 iPad 上安装 Fiddler 证书后，还需要进入 设置 → 通用 → 关于本机 → 证书信任设置手动开启信任，否则 HTTPS 流量依旧会被系统丢弃。

4. 应用启用了 SSL Pinning 很多金融类、视频类 App，为了防止流量被拦截，都会启用 SSL Pinning。此时即便证书安装正确，Fiddler 依然无法解密流量。

5. 端口冲突或系统限制 某些时候，Fiddler 的监听端口会被防火墙或其他代理软件占用，导致抓包失败。

二、常见排查思路

1. 确认代理是否连通
   • 在手机 Safari 里访问一个 HTTP 网站，看 Fiddler 是否有流量显示
   • 如果没有，优先检查 IP 和端口
2. 确认 HTTPS 解密是否开启
   • 勾选 “Decrypt HTTPS traffic”，并把目标域名加入解密列表
   • 如果只勾选了部分域名，可能导致其他请求依旧无法解密
3. 确认证书是否被信任
   • iOS 系统较为严格，证书必须手动信任
   • 如果只安装不信任，HTTPS 数据包仍旧无法显示
4. 判断是否遇到 SSL Pinning
   • 如果是 App 层面限制（比如支付宝、银行 App），Fiddler 基本无解
   • 此时需要借助其他方式来绕过

三、当 Fiddler 无法突破时的解决方案

在我调试一款带有强制 HTTPS 验证的应用时，Fiddler 的配置全部正确，但依旧只能看到 CONNECT 请求。排查后发现，应用启用了 SSL Pinning。

最终，我尝试借助 Sniffmaster（抓包大师） ：

• USB 直连 iOS 设备，不需要 Wi-Fi 代理配置
• 无需安装证书或越狱，直接解密 HTTPS 流量
• 支持破解双向 SSL 验证（即常见的 HTTPS Pin）
• 仅抓取指定 App，避免被系统无关流量淹没
• 内置拦截器，可以用 JavaScript 修改请求与响应内容
• 导出 PCAP 文件，方便进一步用 Wireshark 分析

四、不同工具的分工

在实际开发中，我的经验是： 没有单一工具能应对所有场景。合理组合工具，才能构建完整的调试链路。

• Fiddler：适合快速调试 Web 请求、桌面应用流量
• Charles：跨平台支持好，适合 Mac 用户，界面友好
• mitmproxy：脚本化能力强，适合自动化测试和定制场景
• Sniffmaster：解决 iOS 上的高安全场景，尤其是 SSL Pinning 和双向认证

五、经验总结

• 基础配置是第一步：大部分“抓不到包”的问题，都来自代理和证书配置错误
• 要识别限制来源：若流量加密层级更高（Pinning），传统代理工具几乎无解
• 要有替代方案：Sniffmaster 提供了直连抓包思路，适合和 Fiddler 互补
• 工具组合更高效：在团队协作中，可以把流量导出为 PCAP，用 Wireshark 二次分析，形成完整的调试闭环

当 Fiddler 抓包失败时，不要一味纠结在代理配置上，而是应该逐步排查，确认是否遇到 SSL Pinning 等更高级别的防护。如果是后者，那就需要借助其他工具来突破限制，保证调试工作不中断。