Fiddler抓包无法捕获HTTPS下载内容？

Question

问题：Fiddler无法捕获HTTPS下载内容，提示TLS解密失败。 现象表现为HTTP流量正常捕获，但HTTPS请求的响应体为空或显示“Tunnel to”记录，尤其在抓取大文件下载（如PDF、安装包）时更为明显。常见原因包括未正确安装Fiddler根证书、系统或浏览器不信任该证书、目标站点启用HSTS或使用证书绑定（Certificate Pinning），以及Fiddler未开启“Decrypt HTTPS traffic”选项。此外，某些现代应用（如Edge、Chrome更新后）默认启用加密SNI或使用独立SSL/TLS栈，也可能导致解密失败。需检查Fiddler证书配置、操作系统信任设置，并确认客户端是否绕过系统代理。

Answer 1

1. 问题现象与初步诊断

Fiddler作为经典的HTTP调试代理工具，在日常开发和测试中被广泛用于流量监控。然而，许多用户在尝试捕获HTTPS请求时遇到“TLS解密失败”错误，表现为响应体为空或仅显示 Tunnel to host:443 的隧道记录，尤其在下载大文件（如PDF、安装包）时更为显著。

• HTTP流量可正常捕获，说明Fiddler代理基本功能正常。
• HTTPS请求虽建立连接，但无法解密内容，表明TLS中间人（MITM）机制未生效。
• 常见提示包括“Response is encoded and not supported”或“Failed to decrypt HTTPS traffic”。

该问题本质是Fiddler作为TLS中间人未能成功完成SSL/TLS握手解密流程。

2. 基础配置检查：确保解密功能启用

检查项	正确配置值
Decrypt HTTPS traffic	勾选（Options → HTTPS）
Capture HTTPS CONNECTs	建议启用
Ignore server certificate errors	根据需要启用
Use Browser-Specific UA	可选，避免UA检测干扰

若未开启“Decrypt HTTPS traffic”，Fiddler将仅创建隧道而不尝试解密，导致所有HTTPS流量表现为“Tunnel to”。务必在 Fiddler Options → HTTPS 标签页中确认此选项已启用，并点击“Actions”重新生成本地证书。

3. Fiddler根证书的信任配置

Fiddler通过生成自签名CA证书实现HTTPS解密。系统及应用必须信任该证书，否则TLS握手将失败。

1. 进入 Fiddler → Tools → Options → HTTPS → Actions → "Trust Root Certificate"
2. Windows系统会弹出证书安装向导，选择“本地计算机”存储位置
3. 将证书安装至“受信任的根证书颁发机构”
4. 对于Chrome/Edge浏览器，还需额外在 chrome://settings/security 中确认系统证书被使用
5. macOS用户需通过“钥匙串访问”手动将Fiddler证书标记为“始终信任”
6. Android设备需将Fiddler证书导出并安装至“受信凭据”
7. Java应用（如JVM后台服务）可能需导入证书到cacerts库：
   keytool -importcert -file fiddler.cer -keystore $JAVA_HOME/lib/security/cacerts

可通过访问 https://www.baidu.com 测试是否能正常解密，查看证书链中是否包含“DO_NOT_TRUST_FiddlerRoot”。

4. 高级障碍：HSTS与证书绑定（Certificate Pinning）

某些网站（如银行、Google、GitHub）启用HSTS（HTTP Strict Transport Security），强制使用预载列表中的证书，绕过本地CA信任设置。此外，移动App或桌面客户端常采用证书固定（Pinning），直接校验服务器公钥指纹，导致Fiddler中间人攻击失效。

// 示例：OkHttp中证书固定配置
new CertificatePinner.Builder()
    .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .build();

此类场景下，即使Fiddler证书被系统信任，应用仍会拒绝连接。解决方案包括：

• 使用Xposed框架（Android）或Frida动态脱钩证书校验逻辑
• 在可控环境中关闭Pinning代码（仅限测试）
• 改用支持透明代理的工具如Charles Proxy + SSL Proxying Location配置

5. 现代浏览器与加密SNI（ESNI/Encrypted Client Hello）

自Chrome 85+、Edge 90+起，默认启用加密SNI（ECH），阻止Fiddler获取目标主机名，从而无法动态生成对应域名的伪造证书。

graph TD
    A[Client] -->|Encrypted SNI| B(Fiddler)
    B -->|无法解析SNI| C[无法生成匹配证书]
    C --> D[TLS handshake failure]
    D --> E[Decryption failed]

解决方式：

• 临时禁用加密SNI：启动参数添加 --disable-features=EncryptedServerNameIndication
• 在Fiddler中预先配置SSL解密域名（HTTPS → SSL Pass-through Hostnames）
• 使用企业级抓包方案如BrowserMob Proxy配合定制化WebDriver

6. 应用绕过系统代理的检测与应对

部分现代应用（如Electron应用、.NET Core服务、独立Node.js进程）不使用系统代理，而是内置HTTP客户端栈，导致Fiddler无法拦截。

应用类型	是否默认走系统代理	解决方案
传统Win32程序	是	无需特殊处理
Chrome/Edge（新版）	部分绕过	命令行指定proxy-server
Electron应用	否	注入proxy设置或使用环境变量
.NET Core HttpClient	否	代码中显式设置Proxy
Java Spring Boot	否	JVM参数：-Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=8888

例如，启动Chrome时应使用：
chrome.exe --proxy-server=127.0.0.1:8888 --ignore-certificate-errors