碰到 Fiddler 抓不到包，是常见而又恼人的一天。作为开发或测试，先别急着怀疑工具本身，按系统化流程排查通常能很快定位原因，并给出可执行的修复或替代方案。下面按“可能原因 → 逐项排查 → 替代/补抓策略”来写，既适合做工单复用，也方便在团队共享。

一、先搞清楚“抓不到”的具体表现

在开始前先回答三个简短问题，把问题范围缩小成可检验的假设：

  1. 是所有请求都抓不到，还是只有某个 App/域名/协议？
  2. 是HTTP 明文不可见，还是仅 HTTPS（加密）不可见？
  3. 是否在本机浏览器能捕获，但移动设备或模拟器上看不到？

有了答案，下面按常见原因逐一排查。

二、常见原因与快速排查步骤（按优先级）

1) Fiddler 本身没启动或监听不对

  • 确认 Fiddler 在本机启动并监听（默认端口 8888）；在 Windows 里用 netstat -an | findstr 8888 检查。
  • 检查是否启用了 “Allow remote computers to connect”（若要抓移动设备流量需要）。

2) 设备/浏览器代理未设置或指向错误

  • 桌面浏览器：确认系统代理或浏览器代理设置指向 Fiddler 的 IP:端口。
  • 手机/模拟器：Wi-Fi/代理设置必须指向运行 Fiddler 的机器 IP（在同一网段）；H/W NAT 或公司网络可能阻断局域代理。

3) HTTPS/证书问题（最常见）

  • 抓 HTTPS 需要在客户端信任 Fiddler 的根证书（FiddlerRoot）。桌面浏览器通常会自动信任，手机需要手动安装并信任证书。
  • Android 9+ 与 iOS 10+ 对用户证书与系统证书的信任限制较多：系统级应用或某些 SDK 只信任系统根证书，用户安装的 CA 可能无效。若 App 启用证书 pinning，代理将无法解密。

排查要点：在设备上打开 http://ipv4.fiddler:8888 或访问 Fiddler 提供的证书安装页面，确认证书安装与信任状态。

4) 应用使用了非系统网络栈或证书 pinning

  • 很多移动 App 为了安全会做 pinning、或使用自定义 TLS（例如 okhttp+自实现证书校验），这类流量不会自动走系统代理，Fiddler 无法捕获。
  • 判定方法：桌面浏览器可抓，但对应 App 无法抓，且 App 报 TLS 错误/直接走业务，则极可能是 pinning。

5) HTTP/2、QUIC（HTTP/3）与多路复用

  • HTTP/2 在代理链路上表现不同，某些代理配置或老版本 Fiddler 对 h2 的支持不完善。
  • QUIC（基于 UDP 的 HTTP/3）完全绕开 TCP 代理；若目标启用了 QUIC，传统 HTTP 代理无法捕获。
  • 解决：临时在服务器端关闭 QUIC/h2 测试，或使用支持 QUIC 解码的抓包方式（服务端抓包/UDP 捕获）。

6) 网络或平台限制（VPN、防火墙、企业网）

  • 公司网络、VPN 或防火墙可能会阻断局域代理流量，或对代理会话做 SSL 替换。换到手机热点或家用 Wi-Fi 做一次对比测试很有帮助。

三、逐项修复与验证清单（可直接复制执行）

  1. 在 Fiddler 上启用远程连接；记下电脑 IP 并确认防火墙放行 8888。
  2. 在手机/模拟器 Wi-Fi 设置里把 HTTP 代理改为手动，Host 填写电脑 IP，Port 填 8888。
  3. 在手机上安装并信任 FiddlerRoot（如果是 Android，要看是否需要放到系统证书存储中；iOS 从“证书信任设置”里开启全信任）。
  4. 若仍抓不到，暂时把目标服务降级为 HTTP 或在测试环境关闭 QUIC/HTTP3，再测是否能被捕获。
  5. 若 App 有 pinning，联系开发打开测试开关或在测试构建中关闭 pinning。
  6. 使用 tcpdump / Wireshark 在服务端或网关抓包，确认请求是否到达后端（用于判断问题是客户端侧未发出，还是在中间被拦截）。

四、当 Fiddler 无法工作时的替代与补抓策略

如果按上面步骤仍然无法捕获到目标流量，可以考虑下列替代方案，按场景选用：

  • Charles / Proxyman / mitmproxy：这些代理在某些平台或协议上对互操作性更好，可以作为换刀验证。

  • 服务器/网关抓包（tcpdump/Wireshark）：最可靠的“是否到达后端”证据；尤其在怀疑网络或 CDN 问题时必须抓服务端包进行对比。

  • 脚本化抓取（mitmproxy 脚本、pyshark）：适合批量或自动化测试场景。

  • 硬连接式抓取方案：当代理配置、证书或网络策略都受限时，可采用通过 USB 直连采集设备网络流量并导出 pcap 的方案（无需修改 App、无需获取 root/越狱），把流量导出为 Wireshark 兼容文件用于深入分析。

    抓包大师（Sniffmaster）在工程实践中正是为这种场景设计：它支持无需设置代理、无需越狱/无需 root 的直连抓取、按 App/域名过滤，并可导出 pcap 与单包二进制，便于与服务端抓包做逐帧对比（在合规前提下使用）。

以上替代不是“放弃 Fiddler”，而是提供补充证据与复现路径，尤其当面对证书 pinning、HTTP/3、运营商透明代理等边界问题时尤为有用。

五、实战小贴士（经验之谈）

  • 抓包前记录好时间点、设备 IP、目标域名与 request-id；这样在服务端 tcpdump 与本地代理日志中能快速对齐帧。
  • 对于 HTTPS，优先在测试环境下使用自签证书或测试 CA 做端到端验证，避免在生产环境导出会话密钥或随意信任根证书。
  • 当怀疑是 QUIC/HTTP3，先把客户端或服务端强制退回到 TCP+HTTP/2 以便代理捕获，再做问题定位。
  • 团队应把常用排查命令（openssl s_client、curl -v、tcpdump 命令行、代理证书安装步骤）写成 checklist，放进工单模板里，避免每次重复沟通。

Fiddler 抓不到包通常不是单一原因，按层次化排查能把问题快速缩小：先确认代理/证书/网络设定，再看 App 行为（pinning / 自定义栈），最后用服务端抓包或替代方案补证据。把 Fiddler、其他代理工具、server-side tcpdump 与直连抓包Sniffmaster方案组合使用，能把很多“看不到流量”的难题变成可以验证与复现的工程工单。