在移动端调试过程中，抓包工具几乎是开发者和测试工程师的“放大镜”。然而，有时候即使把 Fiddler 打开，代理也设置好了，界面却依旧空空如也，看不到任何请求。
这种情况极其常见，尤其是在 iOS 调试中，大多数问题都出在配置细节和应用安全机制上。下面我分享一次抓包失败的真实调试经历，并总结了一套应对思路。

一、常见导致无流量的原因

1. 代理设置错误
   • iPhone Wi-Fi 没有配置为电脑的局域网 IP 和 Fiddler 的监听端口（默认 8888）
   • 手机与电脑不在同一网络
2. HTTPS 解密未启用
   • Fiddler 默认不解密 HTTPS
   • 如果没在 Options → HTTPS 中勾选 “Decrypt HTTPS traffic”，只能看到 CONNECT 请求
3. 证书未信任
   • 在 iOS 上，证书安装后还需要进入“证书信任设置”开启信任
   • 否则 HTTPS 流量会被系统直接丢弃
4. App 启用了 SSL Pinning 或双向认证
   • 这是目前最常见的阻碍
   • 应用会检查服务器证书指纹，发现中间人证书会直接拒绝连接
5. 端口冲突或安全限制
   • 有时防火墙会阻止监听端口
   • 同时运行多个代理软件也可能导致抓包失败

二、排查过程

在调试一款 iOS 应用时，我遇到了这样的情况：

• Fiddler 能显示普通 HTTP 请求
• 但所有 HTTPS 请求只停留在 CONNECT 状态，没有具体数据

第一步，我检查了代理配置，确认手机的 Wi-Fi 代理已经正确设置为电脑 IP + 8888 端口。
第二步，我打开了 Fiddler 的 HTTPS 解密，并重新生成证书。
第三步，我在 iPhone 上重新安装并信任证书。

即便如此，HTTPS 流量依旧无法显示。结合经验，我判断该 App 启用了 SSL Pinning。

三、Fiddler 无法突破时的替代思路

面对 SSL Pinning，传统的代理型工具基本无解。这时我切换到了 Sniffmaster（抓包大师），它采取了不同的思路：

• USB 直连 iOS，无需代理配置
• 无需越狱或 Root，即插即用
• 可自动解密 HTTPS，支持破解双向认证
• 仅抓取目标 App，减少无关流量干扰
• 支持拦截修改请求与响应，方便测试不同业务逻辑
• 数据可导出为 PCAP，再配合 Wireshark 做更深层分析

几分钟后，我就成功捕获到该 App 的 HTTPS 流量，确认了请求头和响应数据，从而定位到了问题。

四、不同工具的分工与组合

我的体会是：抓包工具没有万能解，合理分工组合使用才是关键。

• Fiddler：适合常规调试，Windows 平台下最常用
• Charles：跨平台，界面直观，适合快速验证请求
• mitmproxy：命令行工具，适合自动化脚本化测试
• Sniffmaster：适合对抗 SSL Pinning、双向认证的高安全场景

在实际调试中，可以形成这样一条链路：

1. 先用 Charles / Fiddler 验证是否能正常抓包
2. 如果遇到 Pinning，则切换 Sniffmaster
3. 最后导出 PCAP 文件，用 Wireshark 进行协议层分析

五、经验总结

• 抓不到包时，80% 的问题出在代理和证书配置，优先检查这些基础环节
• 如果 HTTPS 握手失败，要怀疑是 SSL Pinning
• 在遇到高安全 App 时，直连抓包工具是必备补充
• 多工具协作 才能覆盖从流量获取到异常模拟的完整链路