简介：Fiddler Web Debugger V4.6.20171.7553中文最终纪念版，专为前端开发者、测试工程师及网络调试人员设计，解决HTTP/HTTPS流量捕获、分析、修改与性能诊断等核心问题，尤其适用于接口联调、安全测试及HTTPS证书调试场景。资源包共92个文件，含13个可执行程序（如Fiddler.exe、TrustCert.exe、EnableLoopback.exe）、43个核心DLL组件（支撑协议解析、脚本编辑、证书生成等功能）、14个数据模板文件（如200_SimpleHTML.dat、404_Plain.dat等用于模拟响应）、8个调试符号PDB文件及配套配置、图标、音效与C#/JS脚本，整体体积仅5.67MB，轻量易部署。已有279人学习下载，是当前中文社区稀缺的完整汉化+HTTPS插件一体化方案——开箱即用支持HTTPS解密（CertMaker.dll+BCMakeCert.dll已集成），附带使用说明与证书配置工具，无需额外配置即可深度调试加密流量，显著降低初学者入门门槛。
1. Fiddler 4.6.20171.7553 中文纪念版：别急着点安装包，先搞清它为什么还在被大量复用
你是不是也遇到过：新项目要求抓 HTTPS 流量，团队里老同事甩来一个「Fiddler 中文纪念版」压缩包，双击 setup.exe 却卡在 .NET Framework 4.5.2 检测失败？或者装完打开就弹“证书不可信”，浏览器死活不放行 localhost 的 HTTPS 请求？这不是玄学——Fiddler 4.6.20171.7553 这个版本，是 Windows 平台下最后一版原生支持完整 HTTPS 解密流程、自带中文界面、且无需额外编译插件就能直连 Chrome/Firefox/Edge（旧版）的稳定基线。它不依赖 .NET Core，不强制联网校验授权，也不吃新版 Windows 的 TLS 1.3 兼容性坑。对某高校网络协议分析课、某公司遗留系统接口调试、某跨平台系统 WebService 调试场景来说，它比 Fiddler Everywhere 更轻、比 Charles 更省证书配置步骤。但正因年代较久，它和 Win11 22H2+、Chrome 115+、Edge 120+ 存在三处隐性冲突：TLS 握手降级失败、证书链信任路径错位、UI 缩放适配异常。这篇笔记不讲功能菜单，只带你从零拉起一套能真正在 Win10/Win11 上跑通 HTTPS 抓包的 Fiddler 4.6 环境——包括那个关键的「https证书插件」怎么嵌进主程序、证书怎么导出到系统信任库、以及为什么你反复点击“Decrypt HTTPS traffic”却始终看不到绿色锁图标。
2. 环境准备与安装：不是双击 setup.exe 就完事，得先给系统打补丁
Fiddler 4.6.20171.7553 表面是个独立安装包，实则深度绑定 Windows .NET 运行时栈。跳过环境预检直接安装，90% 的失败都发生在第 3 步——启动时报错 “无法加载 System.Net.Http”。这不是软件坏了，是你系统缺了它赖以为生的“氧气”。
2.1 确认并安装必需的 .NET Framework 版本
Fiddler 4.6 系列明确要求 .NET Framework 4.5.2 或更高（推荐 4.7.2）。注意：Windows 10 1809 及以后版本默认带 4.7.2，但可能被禁用；Windows 11 默认启用 4.8，但 Fiddler 4.6 未做兼容性声明，强行运行易触发反射调用异常。
验证当前启用状态：
# 以管理员身份运行 PowerShell Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release | ForEach-Object { switch ($_.Release) { { $_ -ge 378389 } { Write-Host "已安装 .NET Framework 4.7.1 或更高" } { $_ -ge 378389 -and $_ -lt 460798 } { Write-Host "建议升级至 4.7.2（对应 Release 值 461308）" } default { Write-Host "版本过低，请手动安装 .NET Framework 4.7.2" } } }提示：Release 值是判断依据，不是版本号。
461308= .NET Framework 4.7.2；461808= 4.7.2 with April 2018 Security Update。不要只看控制面板里显示的“4.8”，要查注册表值。
若需安装 4.7.2：
- 下载离线安装包
ndp472-kb4054530-x86-x64-allos-enu.exe（微软官方存档，非第三方镜像） - 必须以管理员身份运行，安装过程约 3–5 分钟，期间 Explorer.exe 可能短暂无响应，属正常现象
- 安装完成后重启系统，否则 Fiddler 启动时仍会读取旧运行时缓存
2.2 关闭 Windows Defender 实时防护（临时）
Fiddler 的 HTTPS 解密本质是中间人代理（MITM），它会动态生成域名证书并注入系统证书存储。Windows Defender 在 2020 年后将此类行为列为“潜在不需要的应用”（PUA），尤其当证书由非 Microsoft 根签发时，会静默拦截 FiddlerCertMaker.dll 的加载。
临时关闭步骤（仅限安装及首次配置阶段）：
# 管理员 PowerShell 执行 Set-MpPreference -DisableRealtimeMonitoring $true # 验证是否生效 Get-MpComputerStatus | Select-Object RealtimeProtectionEnabled注意：这不是永久关闭，而是为绕过安装期的证书注入阻断。配置完成后可立即恢复：
Set-MpPreference -DisableRealtimeMonitoring $false。若跳过此步，你会在 Fiddler 日志中看到Failed to load CertMaker，且“HTTPS Decrypt”开关灰显。
2.3 解压并执行定制化安装流程
资源包名为Fiddler Web Debugger (V4.6.20171.7553)中文最终纪念版+https证书插件.zip，内含 3 个核心目录：
/Fiddler/：主程序文件（含Fiddler.exe,FiddlerCertMaker.dll,FiddlerOptions.xml）/CertPlugin/：增强型 HTTPS 证书插件（含CertMaker.dll,BouncyCastle.Crypto.dll,RootCertificate.cer）/Docs/：中文使用说明（PDF，含证书导入截图）
严禁直接运行/Fiddler/setup.exe—— 该安装器会覆盖你手动准备的证书插件，且默认不勾选中文语言包。
正确流程：
- 新建空目录，例如
C:\Tools\Fiddler46 - 将
/Fiddler/全部内容复制到该目录 - 将
/CertPlugin/CertMaker.dll和/CertPlugin/BouncyCastle.Crypto.dll覆盖到C:\Tools\Fiddler46\下同名文件（保留原FiddlerCertMaker.dll不动，这是主程序调用入口） - 将
/CertPlugin/RootCertificate.cer复制到C:\Tools\Fiddler46\根目录（供后续手动导入用） - 双击
C:\Tools\Fiddler46\Fiddler.exe启动（首次启动会弹出语言选择，选「简体中文」）
此时界面应为完整中文，左下角状态栏显示Ready，无报错弹窗。若出现Could not load file or assembly 'BouncyCastle.Crypto'，说明第 3 步覆盖失败或 DLL 架构不匹配（必须为 x64，32 位系统请确认下载的是 x86 版本）。
3. HTTPS 证书配置：不是点一下“Decrypt HTTPS traffic”就自动生效
Fiddler 的 HTTPS 解密能力，90% 的问题出在证书环节。它不像现代工具（如 Charles）自动完成系统级证书信任，而是分三步走：① Fiddler 自签根证书 → ② 导入 Windows 本地机器根证书存储 → ③ 浏览器/应用信任该根证书。漏掉任一环，“绿色锁”永远不亮。
3.1 生成并导出 Fiddler 根证书
启动 Fiddler 后，依次点击菜单：Tools→Options→HTTPS选项卡
勾选 ✅Decrypt HTTPS traffic
勾选 ✅Ignore server certificate errors (unsafe)（仅调试期启用，生产勿开）
点击Actions→Export Root Certificate to Desktop
此时桌面上会生成FiddlerRoot.cer文件。注意：这个文件不是最终可用证书——它是 Fiddler 运行时动态生成的，每次重置证书都会变化。而资源包里的/CertPlugin/RootCertificate.cer是预生成的、已适配 Win10/Win11 证书策略的稳定版，应优先使用它。
为什么不用自动生成的？因为 Fiddler 4.6 默认生成的证书使用 SHA-1 签名算法，在 Win10 1809+ 和 Win11 中被系统策略默认拒绝。
/CertPlugin/RootCertificate.cer已升级为 SHA-256 + RSA 2048，且 Subject Name 符合CN=DO_NOT_TRUST_FiddlerRoot规范，能通过系统证书链校验。
3.2 手动导入根证书到“受信任的根证书颁发机构”
双击C:\Tools\Fiddler46\RootCertificate.cer→ 点击「安装证书…」→ 选择「本地计算机」→ 下一步 → 选择「将所有的证书放入下列存储」→ 点击「浏览」→ 选中「受信任的根证书颁发机构」→ 完成。
关键验证点：
# 管理员 PowerShell 执行，检查证书是否真正落库 Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*DO_NOT_TRUST_FiddlerRoot*" } | Format-List Thumbprint,Subject,NotAfter应返回一条记录，NotAfter时间为 2030 年以后，Thumbprint为 40 位十六进制字符串。若无输出，说明导入失败（常见于未选“本地计算机”或存储位置错误）。
3.3 配置浏览器信任（以 Chrome/Edge 为例）
Chrome/Edge 基于 Windows 证书存储，但存在缓存机制。即使证书已导入系统，浏览器仍可能沿用旧证书缓存。
强制刷新步骤：
- 在 Chrome 地址栏输入：
chrome://restart（重启整个浏览器进程） - 访问任意 HTTPS 网站（如
https://httpbin.org/get），Fiddler 应在会话列表中捕获到CONNECT请求 - 若仍显示红色
X（证书错误），在地址栏点击锁图标 → 「连接不安全」→ 「证书」→ 查看「证书路径」，确认最顶层为DO_NOT_TRUST_FiddlerRoot
补充：Firefox 使用独立证书库，需单独导入。在 Firefox 地址栏输入
about:preferences#privacy→ 「查看证书」→ 「权威机构」→ 「导入」→ 选择RootCertificate.cer→ 勾选「信任此 CA 根证书用于标识网站」。
4. 避坑指南：那些让你怀疑人生、但其实有标准解法的 5 个高频问题
Fiddler 4.6 的“纪念版”属性，决定了它和现代系统存在天然摩擦。以下问题我已在某实验室 12 套 Win11 调试机上复现并固化解决方案，不是网上零散的“试试重启”，而是可批量执行的修复逻辑。
4.1 现象：启动 Fiddler 后状态栏显示Offline，无法捕获任何流量
原因：Fiddler 默认监听127.0.0.1:8888，但某些安全软件（如某国产卫士）会劫持本地回环端口，或 Windows Hyper-V 虚拟交换机占用了 8888。
解决：
- 打开
Tools→Options→Connections - 取消勾选 ✅
Act as system proxy on startup - 修改
Fiddler listens on port:为8889（或其他未被占用端口） - 勾选 ✅
Allow remote computers to connect（启用后需在 Windows 防火墙放行该端口） - 点击
OK，重启 Fiddler
验证命令（管理员 PowerShell）：
netstat -ano | findstr :8889 # 应返回包含 Fiddler.exe PID 的监听行4.2 现象：勾选Decrypt HTTPS traffic后，Chrome 访问 HTTPS 网站直接空白页，Fiddler 日志显示Tunnel to xxx:443 returned 502
原因：Chrome 115+ 默认启用 TLS 1.3，而 Fiddler 4.6 的 CertMaker 插件未实现 TLS 1.3 的密钥交换模拟，导致隧道建立失败。
解决：强制 Chrome 降级 TLS 版本（仅调试用）：
- Chrome 启动快捷方式目标末尾添加参数：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --ssl-version-min=tls1.2 - 或在 Chrome 地址栏输入
chrome://flags/#tls13-variant→ 设为Disabled→ 重启
注意：此设置仅影响当前 Chrome 实例，不影响系统全局 TLS 策略。
4.3 现象：Fiddler 能抓 HTTP，但所有 HTTPS 请求显示Tunnel to domain:443后无后续请求，状态码为200
原因：Fiddler 成功建立了 TLS 隧道，但未触发实际解密——根本原因是CertMaker.dll加载失败，导致无法生成域名证书。
解决：
- 确认
C:\Tools\Fiddler46\目录下存在CertMaker.dll和BouncyCastle.Crypto.dll，且二者均为 x64 架构（用file命令或sigcheck -a CertMaker.dll验证） - 在
Tools→Options→HTTPS中，点击Actions→Reset All Certificates - 再次点击
Export Root Certificate to Desktop，用导出的新证书覆盖RootCertificate.cer - 重新导入证书（按 3.2 节步骤）
4.4 现象：Fiddler 界面文字乱码（如菜单显示方块、中文提示为问号）
原因：Fiddler 4.6 中文版使用 GB2312 编码渲染 UI，而 Win10/Win11 默认区域设置为 UTF-8，导致字体映射失败。
解决：
- 控制面板 → 「区域」→ 「管理」选项卡 → 「更改系统区域设置」
- 勾选 ✅
Beta 版：使用 Unicode UTF-8 提供全球语言支持→取消勾选 - 重启系统
- 启动 Fiddler，乱码消失
血泪经验：此设置会影响部分老旧 C++ 编译程序，但对 Fiddler 是必要妥协。若必须开启 UTF-8 全局支持，则需用 Resource Hacker 替换 Fiddler.exe 的字体资源，操作复杂且易破坏签名，不推荐。
4.5 现象：Fiddler 抓到请求，但 Response Body 显示This request is not viewable because it was not captured by Fiddler.
原因：该请求由非浏览器进程发出（如 Electron 应用、.NET HttpClient、Java 应用），未配置代理，或应用自身实现了证书固定（Certificate Pinning）。
解决：
- 对于 .NET 应用：在代码中显式设置代理
var handler = new HttpClientHandler(); handler.Proxy = new WebProxy("127.0.0.1", 8889); handler.UseProxy = true; var client = new HttpClient(handler); - 对于 Java 应用：启动参数添加
-Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=8889 - 对于证书固定应用：需反编译修改
TrustManager，超出本文范围，建议改用 Fiddler Everywhere 或 Frida 动态 Hook。
5. 验证与实战技巧：用一个真实接口跑通全流程，确认你的环境真正可用
光看状态栏Ready和绿色锁图标还不够。真正的验证，是让一个带登录态、含 HTTPS 重定向、返回 JSON 数据的真实接口，在 Fiddler 里完整呈现请求头、响应体、时间轴、甚至 WebSocket 帧。下面以https://httpbin.org/delay/1（延迟 1 秒响应）为例，走一遍端到端验证。
5.1 基础连通性验证：HTTP + HTTPS 双通道确认
- 在 Fiddler 中确保
File→Capture Traffic已勾选（左上角红色录制按钮亮起） - 打开 Chrome，访问
http://httpbin.org/get→ Fiddler 应捕获到200 OK，Inspectors → TextView 中可见原始 JSON - 访问
https://httpbin.org/get→ 应同样捕获，且 Session 列表中 Protocol 列显示HTTPS，Result 列为200 - 点击该会话 → Inspectors → TextView → 查看响应体，确认为 JSON 格式，非 HTML 错误页
关键指标：HTTPS 会话的
Result必须是200，而非502或407；Protocol列必须显示HTTPS，而非HTTP（后者说明未走隧道）。
5.2 证书解密验证：确认你看到的是明文，不是加密隧道
HTTPS 会话点击后，切换到Inspectors→TextView选项卡：
- 若能看到
{"args": {}, "headers": {...}, "url": "https://httpbin.org/get"}等明文 JSON，则解密成功 - 若显示
Encrypted Content或This session is encrypted and cannot be viewed，说明证书未生效
此时检查：
File→Properties→HTTPS选项卡中Decrypt HTTPS traffic是否仍为勾选状态（有时会意外取消）- Windows 证书管理器中
Cert:\LocalMachine\Root是否仍存在DO_NOT_TRUST_FiddlerRoot（有时被杀软清理） - Chrome 地址栏锁图标 → 「证书」→ 「证书路径」是否完整指向该根证书
5.3 复杂场景验证：带 Cookie 和重定向的登录流
很多开发者卡在「能抓 GET，不能抓 POST 登录」。我们用 httpbin 的/cookies/set模拟：
- 在 Chrome 访问
https://httpbin.org/cookies/set?k1=v1&k2=v2（设置两个 Cookie） - 立即访问
https://httpbin.org/cookies（读取 Cookie） - 在 Fiddler 中筛选
httpbin.org，找到/cookies/set会话 → 查看Inspectors→WebForms→ 确认 QueryString 中k1=v1&k2=v2 - 找到
/cookies会话 →Inspectors→TextView→ 响应体应为{"cookies": {"k1": "v1", "k2": "v2"}} - 切换到
Inspectors→Headers→Request Headers→ 查看Cookie字段是否包含k1=v1; k2=v2
这一步验证了 Fiddler 不仅能解密，还能正确解析并展示应用层 Cookie 传递逻辑。若
Cookie字段为空，说明浏览器未将 Cookie 发送给服务器，大概率是httpbin.org的 Cookie 属性（如Secure、SameSite）与本地调试环境不匹配，需在 Fiddler 中右键会话 →Replay→Reissue Requests并手动添加 Header 测试。
5.4 性能与稳定性验证：长时间运行不崩溃
Fiddler 4.6 在 Win11 上存在内存泄漏风险（尤其开启 HTTPS 解密时）。验证方法：
- 启动 Fiddler，开启捕获
- 用脚本循环请求
https://httpbin.org/delay/1100 次（Python 示例）：import requests for i in range(100): r = requests.get("https://httpbin.org/delay/1", proxies={"https": "http://127.0.0.1:8889"}) print(f"Request {i+1}: {r.status_code}") - 观察 Fiddler 进程内存占用（任务管理器 → 详细信息 → Fiddler.exe 的内存列）
- 正常表现：内存波动在 150–300 MB 区间，无持续上涨趋势
- 异常表现：内存突破 500 MB 且不回落，此时需点击
File→Exit彻底退出，而非最小化
从那以后我每次部署 Fiddler 4.6 环境，都强制走一遍这四步验证：HTTP/HTTPS 基础连通 → 证书明文解密 → Cookie/重定向链路 → 长周期稳定性。少走一步，后面三天都在查为什么某个特定接口抓不到。这套流程已在某公司 3 个遗留系统联调项目、某高校 5 门网络课程实验中稳定复用，没再出现过“明明装好了却抓不到 HTTPS”的返工。希望帮到你。
本文还有配套的精品资源，点击获取
