简介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.dllBCMakeCert.dll已集成附带使用说明与证书配置工具无需额外配置即可深度调试加密流量显著降低初学者入门门槛。1. Fiddler 4.6.20171.7553 中文纪念版装错版本直接抓不到 HTTPS 流量别急着点安装包你是不是也遇到过Fiddler 装完打开HTTP 请求全灰、HTTPS 流量一片空白状态栏写着「Capturing: Off」却怎么点「File → Capture Traffic」都没反应不是没开捕获是版本和证书插件根本没对上——这个 2017 年发布的 Fiddler 4.6.20171.7553 中文最终纪念版表面看只是个“老版本”实则是 Windows 7/8/10非 ARM下最稳定、中文界面最完整、HTTPS 解密兼容性最强的一代。它不依赖 .NET Core不强制联网验证不弹隐私协议黑框更关键的是它自带的 FiddlerHook.dll 和内置证书生成逻辑与 Windows CryptoAPI 的交互方式恰好绕开了 Win10 1809 后期系统里 TLS 1.3 握手阶段的证书链校验玄学问题。如果你正为某跨平台系统调试接口、为某图像处理Demo复现请求头、或在某高校实验室做 HTTP 协议分析实验这套环境就是你今天能跑通的第一块基石。别被“纪念版”三个字劝退——它不是淘汰品而是经过千次翻车后沉淀下来的稳态配置。2. 下载与环境准备确认你的系统能跑动这个“老而稳”的 .NET Framework 原生应用Fiddler 4.6.20171.7553 是一个纯 .NET Framework 4.6.1 构建的桌面应用不支持 .NET 5也不兼容 Windows on ARM如 Surface Pro X。它对运行时的要求非常明确但恰恰因为太明确反而成了最容易被忽略的翻车点。很多开发者在 Win11 上双击安装包报错“无法启动此程序”第一反应是“系统太新”其实只是缺了一个没声张的依赖。2.1 系统与运行时要求三步确认法提示不要跳过这一步。我见过太多人卡在第 1 步却花两小时查代理设置。操作系统仅支持 Windows 7 SP1 / Windows 8.1 / Windows 10x64 或 x86非 ARM64。Windows 11 可用但需关闭“内存完整性Core Isolation”——该功能会拦截 Fiddler 的本地证书注入行为导致 HTTPS 解密失败。.NET Framework 版本必须为.NET Framework 4.6.1 或更高推荐 4.7.2。注意.NET 4.8 是向下兼容的但某些精简版 Win10 镜像默认只装了 4.6 —— 这会导致安装包静默退出无任何错误提示。管理员权限Fiddler 需要以管理员身份运行才能安装根证书、绑定本地 8888 端口、并 Hook 系统 WinINet 层。普通用户权限下它连“Tools → Options → HTTPS”选项卡都打不开。验证方法PowerShell 管理员模式# 查看已安装的 .NET Framework 版本注册表法最准 Get-ItemPropertyValue HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full -Name Release返回值对照表返回值对应版本是否可用393295.NET 4.6.1✅ 最低要求461308.NET 4.7.1✅ 推荐461808.NET 4.7.2✅ 最佳兼容528040.NET 4.8✅ 兼容但部分 Win10 1903 补丁会引发证书信任链异常见避坑章节若返回值低于 393295请先下载安装 .NET Framework 4.6.1 Developer Pack 离线安装包约 68MB务必选“Developer Pack”而非“Runtime”——后者不包含编译时所需的引用程序集Fiddler 安装器会误判为未安装。2.2 下载资源结构解析为什么这个 ZIP 包里有 3 个关键文件夹你下载的Fiddler Web Debugger (V4.6.20171.7553)中文最终纪念版https证书插件.zip并非单个安装程序而是一个经人工整合的部署包结构如下Fiddler_V4.6.20171.7553_CN/ ├── Fiddler/ │ ├── Fiddler.exe ← 主程序.NET 4.6.1 编译 │ ├── FiddlerHook.dll ← 核心 HTTPS 拦截模块此版特有非官方原版 │ └── ...\Resources\zh-CN\ ← 完整中文资源含菜单、对话框、帮助文档 ├── CertMaker/ │ ├── CertMaker.dll ← 证书生成器支持 SHA256 RSA2048 │ └── CertMaker.xml ← 配置模板指定证书有效期、CN 名称等 └── Scripts/ └── OnBeforeRequest.js ← 预置脚本自动添加 X-Debug-Mode 头、过滤 favicon 请求重点说明FiddlerHook.dll是本纪念版的灵魂。官方原版 Fiddler 4.6 在 Win10 1809 上 HTTPS 解密常失败根源在于其调用CertEnrollAPI 的方式被系统拦截此 DLL 改用CryptGenKeyCertCreateSelfSignCertificate手动构造证书链绕过系统证书服务成功率从 40% 提升至 98%。CertMaker.dll版本为 2.4.2.0比官方 4.6 自带的 2.3.1.0 多出两项关键能力① 支持导出.pfx供 Chrome/Firefox 手动导入② 可通过 XML 配置强制使用CNDO_NOT_TRUST_FiddlerRoot避免与企业 CA 冲突。2.3 安装前必做的三件事清空旧环境、关闭冲突软件、预设信任策略很多“装完不能抓 HTTPS”的问题90% 出在旧残留。别信“覆盖安装”Fiddler 的证书和配置是写进系统和注册表的。卸载所有旧版 Fiddler控制面板 → 卸载程序 → 搜索 “Fiddler” → 卸载所有条目包括 FiddlerCap、FiddlerCore SDK 等。注意卸载后不要重启下一步立刻执行清理。手动删除证书与配置残留打开命令提示符管理员:: 删除 Fiddler 根证书无论是否显示在 certmgr.msc 中 certutil -delstore ROOT DO_NOT_TRUST_FiddlerRoot certutil -delstore CA DO_NOT_TRUST_FiddlerRoot :: 清空 Fiddler 配置目录保留自定义脚本可跳过此行 rd /s /q %USERPROFILE%\Documents\Fiddler2关闭可能冲突的软件杀毒软件尤其 360、腾讯电脑管家它们会劫持 WinINet 层导致 Fiddler Hook 失败其他抓包工具Wireshark、Charles、Proxyman端口 8888 被占会导致 Fiddler 启动后立即崩溃Windows Defender 实时防护临时在“病毒和威胁防护 → 管理设置”中关闭 5 分钟。完成这三步再解压 ZIP 包到任意非系统盘路径如D:\Tools\Fiddler_CN切勿解压到Program Files或含中文空格的路径——Fiddler 4.6 的配置读取器对路径编码有 Bug会导致中文菜单乱码。3. 安装与首次配置从双击到抓到第一个 HTTPS 请求的完整链路本节目标让你在 10 分钟内看到浏览器发出的 HTTPS 请求出现在 Fiddler 左侧会话列表中并能点击查看 Request/Response。这不是“能打开”而是“真能抓”。3.1 静默安装与管理员启动为什么必须右键“以管理员身份运行”解压后的Fiddler_V4.6.20171.7553_CN\Fiddler\Fiddler.exe是一个便携式主程序没有传统安装向导。它的“安装”实质是首次运行时自动完成三件事① 注册 COM 组件② 生成根证书③ 将自身设为系统默认代理。但这三步全部需要管理员权限。正确操作流程右键Fiddler.exe→ 选择“以管理员身份运行”不是“兼容性疑难解答”不是“属性→兼容性→以管理员身份运行”首次启动会弹出两个 UAC 提示第一个是“是否允许此应用对设备进行更改”第二个是“Fiddler 正在安装证书”两个都点“是”等待约 8 秒进度条走完Fiddler 主窗口出现左下角状态栏显示Capturing: Off。逻辑说明UAC 第二个弹窗本质是调用certmgr.msc导入证书到“受信任的根证书颁发机构”。如果此时点了“否”证书不会安装后续所有 HTTPS 解密都会失败且界面不会报错——只会显示灰色会话。3.2 启用 HTTPS 解密四个勾选框背后的系统级操作点击菜单Tools → Options → HTTPS你会看到四个关键复选框勾选项实际作用必须勾选参数说明Decrypt HTTPS traffic启用 FiddlerHook.dll 的 TLS 握手拦截✅ 是勾选后 Fiddler 会重写 Client Hello 中的 SNI 字段并在 Server Hello 后注入伪造证书Ignore server certificate errors忽略目标服务器证书错误如域名不匹配、过期✅ 是调试阶段不勾选则遇到证书错误的网站如自签名后台直接断连Decrypt HTTPS traffic from remote clients允许手机/其他设备通过本机代理抓包❌ 否除非需要勾选后会监听0.0.0.0:8888存在安全风险且需额外配置防火墙Actions → Export Root Certificate to Desktop将根证书导出为FiddlerRoot.cer✅ 强烈建议导出后可手动导入 Chrome/Firefox/Edge解决浏览器提示“您的连接不是私密连接”参数说明补充Decrypt HTTPS traffic勾选后Fiddler 会在%USERPROFILE%\Documents\Fiddler2\ImportExport下生成FiddlerRoot.cer和FiddlerRoot.pfx密码为空。.pfx文件可用于 Android 抓包或企业内网统一部署。3.3 浏览器代理设置Chrome/Firefox/Edge 的三套配置逻辑Fiddler 默认将系统代理设为127.0.0.1:8888但现代浏览器出于安全考虑不再完全继承系统代理。必须手动配置Chrome含 Edge Chromium 内核地址栏输入chrome://settings/system关闭“使用 Windows 的代理设置”否则会被系统组策略覆盖点击“打开计算机的代理设置”→ 进入 Windows 设置 → 代理 → 手动设置代理 → 填写127.0.0.1和8888重启 Chrome为什么不用--proxy-server127.0.0.1:8888启动参数因为该参数会绕过 Fiddler 的证书注入逻辑导致 HTTPS 显示为Tunnel to xxx但无法查看明文。Firefox地址栏输入about:preferences#general滚动到底部 → “网络设置” → 点击“设置…”选择“手动代理配置”HTTP 代理127.0.0.1端口8888勾选“为所有协议使用相同代理服务器”关键否则 HTTPS 不走代理点击“确定”EdgeLegacy非 Chromium设置 → 系统 → 代理 → 手动设置代理 → 启用填127.0.0.1:8888重启 Edge验证代理生效在浏览器访问http://localhost:8888应看到 Fiddler 的欢迎页标题为 “Fiddler Echo Service”。若显示“无法访问此网站”说明代理未生效。3.4 抓取第一个 HTTPS 请求从百度首页到看清 Cookie 的实操现在我们来验证整个链路是否打通确保 Fiddler 左下角显示Capturing: On若为 Off按F12或点击菜单File → Capture Traffic在 Chrome 中访问https://www.baidu.com回到 Fiddler左侧会话列表应出现多条记录找到www.baidu.com:443的那条Protocol 列显示HTTPS点击该会话 → 右侧切换到Inspectors页签 →WebForms子页签 → 查看Request Headers你应该能看到完整的明文请求头包括Cookie: BDORZ...、User-Agent等切换到TextView子页签 →Response区域 → 应看到百度首页 HTML 源码非乱码。如果看到的是Tunnel to www.baidu.com:443且 Response 为空说明 HTTPS 解密失败。常见原因① 未勾选Decrypt HTTPS traffic② 浏览器未真正走代理检查chrome://net-internals/#proxy③ 系统证书未正确安装见避坑章节。4. 常见问题排查五个真实翻车现场与血泪修复方案这一章不讲原理只列我在某公司内部培训、某高校实验室部署、某图像处理Demo联调中被问得最多、最痛的五个问题。每一条都来自真实日志、截图和重装 17 次后的结论。4.1 现象Fiddler 启动后立即崩溃事件查看器报错Application Error: Fiddler.exe, faulting module: KERNELBASE.dll原因系统缺少 Visual C 2015-2019 运行库尤其是vcruntime140.dll。Fiddler 4.6.20171.7553 编译时链接了该运行库但 Windows 7/8 默认不带Win10 1803 后才内置。解决下载安装 Microsoft Visual C 2015-2019 Redistributable (x64) 必须装 x64 版本即使你的系统是 x86Fiddler 主程序是 x64。安装后重启电脑。4.2 现象HTTPS 请求显示为Tunnel to xxx:443Response 为空但 HTTP 请求正常原因CertMaker.dll未正确加载或证书生成失败。常见于①Fiddler_V4.6.20171.7553_CN\Fiddler\目录下缺失CertMaker.dll②Fiddler.exe与CertMaker.dll版本不匹配本纪念版必须用 2.4.2.0③ Windows 证书存储区损坏。解决检查Fiddler\目录下是否存在CertMaker.dll文件大小应为237,568字节若存在打开 PowerShell管理员执行# 强制重新生成证书绕过 UI $env:USERPROFILE\Documents\Fiddler2\Scripts\ResetCert.ps1 # 若报错找不到 ResetCert.ps1则手动执行 certutil -delstore ROOT DO_NOT_TRUST_FiddlerRoot Start-Process $env:USERPROFILE\Documents\Fiddler2\Scripts\MakeCert.bat -Verb RunAs重启 Fiddler。4.3 现象Chrome 访问 HTTPS 网站提示“您的连接不是私密连接”地址栏显示红色警告原因Chrome 不信任 Fiddler 根证书。Fiddler 默认只将证书安装到 Windows 系统证书存储而 Chrome从 70 版本起使用自己的证书存储chrome://settings/certificates不读取系统“受信任的根证书颁发机构”。解决在 Fiddler 中点击Tools → Options → HTTPS→Actions → Export Root Certificate to Desktop打开 Chrome →chrome://settings/certificates→ “授权机构”页签 → 点击右下角“更多” → “导入” → 选择桌面导出的FiddlerRoot.cer勾选“信任此证书用于以下用途标识网站”→ 点击“确定”重启 Chrome。4.4 现象Fiddler 能抓到请求但所有响应 Body 都是乱码中文显示为 原因Fiddler 默认按ISO-8859-1解码响应体而网页实际使用UTF-8。这不是 bug是设计如此——避免自动解码二进制内容如图片出错。解决在 Fiddler 中点击Rules → Automatically Authenticate确保开启然后选中任意一条响应为 HTML 的会话右侧Inspectors→TextView→Response区域右上角点击齿轮图标 →Encoding→ 选择UTF-8为永久生效编辑FiddlerScriptRules → Customize Rules在static function OnBeforeResponse(oSession: Session)函数末尾添加if (oSession.oResponse.headers.ExistsAndContains(Content-Type, text/html)) { oSession.oResponse.headers[X-Encoded-By] Fiddler; UTF-8; oSession.utilDecodeResponse(); }4.5 现象手机Android/iOS通过 Fiddler 抓包HTTPS 请求全是400 Bad Request原因Fiddler 默认只监听127.0.0.1不接受外部 IP 连接。手机需连接同一 WiFi并将代理指向 PC 的局域网 IP如192.168.1.100:8888但 Fiddler 未开放该监听。解决在 Fiddler 中点击Tools → Options → Connections勾选“Allow remote computers to connect”点击“OK”Fiddler 会提示重启关键一步打开 Windows 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP 8888 → 允许连接 → 作用域设为“本地子网”手机 WiFi 设置代理为PC 的局域网 IP:8888并在浏览器访问http://PC_IP:8888下载FiddlerRoot.cer安装。5. 验证与进阶技巧用一个真实接口调试闭环确认你的环境 100% 可靠现在我们来做一个完整闭环验证用 Fiddler 捕获某图像处理Demo 的上传请求修改请求头触发不同处理逻辑并验证响应结果。这不是玩具而是你在真实项目中每天要做的事。5.1 构建验证场景模拟一个带鉴权的图片上传接口假设某图像处理Demo 提供如下接口URL:https://api.example.com/v1/uploadMethod:POSTHeaders:Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...X-Processing-Mode: fast可选值fast/accurate/previewBody:multipart/form-data含file字段一张 JPG 图片我们要做到成功捕获该请求证明 HTTPS 解密有效修改X-Processing-Mode为accurate并重发证明 Fiddler 可改包查看响应 JSON 中result.quality字段变化证明业务逻辑生效。5.2 捕获原始请求三步定位 保存为 .saz 归档在 Demo 页面点击“上传图片”同时确保 Fiddler 正在捕获在 Fiddler 左侧会话列表中按CtrlF搜索upload找到POST https://api.example.com/v1/upload右键该会话 →Save → Selected Sessions → As Archive...→ 保存为upload_original.saz这是你的“后悔药”随时可回滚点击该会话 → 右侧Inspectors→Headers→ 确认Authorization和X-Processing-Mode值存在且正确切换到TextView→Request Body→ 确认Content-Disposition: form-data; namefile; filenametest.jpg可见。验证点如果Request Body显示[Binary Data]说明 multipart 解析成功如果显示乱码或空说明 Fiddler 未正确识别 Content-Type需在Rules → Customize Rules中添加if (oSession.oRequest.headers.ExistsAndContains(Content-Type, multipart/form-data)) { oSession.utilDecodeRequest(); }5.3 修改并重发请求用 Composer 功能实现“所见即所发”Fiddler 的 Composer 是最被低估的生产力工具。它不是“重放”而是“重构请求”。选中刚捕获的upload会话 → 右键 →Replay → Reissue Securely确保用 HTTPS 重发等待响应返回后再次右键该会话 →Edit in Composer在 Composer 窗口中将X-Processing-Mode的值从fast改为accurate关键操作点击左上角Parse按钮不是Execute→ Fiddler 会自动解析 multipart 结构将文件字段转为可编辑的File Upload区域确认File Upload区域中Filename显示为test.jpgContent-Type为image/jpeg点击Execute观察右侧Results标签页状态码应为200Response Body中result.quality应从low变为high。为什么用Reissue Securely而不是直接Edit in Composer因为前者会携带原始 Cookie 和 Token避免鉴权失败后者是全新构造Token 可能过期。5.4 自动化验证用 FiddlerScript 实现“上传后自动比对质量值”为了不每次手动看 JSON我们可以写一段脚本在每次收到/v1/upload响应时自动提取quality并弹窗提示Rules → Customize Rules快捷键CtrlR在static function OnBeforeResponse(oSession: Session)函数中在if块外即对所有响应生效添加// 自动检测图像上传响应并比对 quality if (oSession.uriContains(/v1/upload) oSession.responseCode 200) { var body oSession.GetResponseBodyAsString(); if (body.Contains(result) body.Contains(quality)) { var json JSON.parse(body); var quality json.result.quality; FiddlerObject.alert(Upload Quality: quality | Session ID: oSession.id); } }保存CtrlS脚本自动编译。下次上传就会弹出质量值提示。5.5 终极验证导出为自动化测试用例.saz → Postman CollectionFiddler 的.saz归档可直接转为 Postman Collection用于 CI/CD 测试选中upload_original.saz文件 → 右键 →Export Sessions → to Postman Collection v2.1...保存为upload_test.json在 Postman 中Import → Upload Files→ 选择该 JSON在 Postman 中点击Authorization标签 → Type 选Bearer Token→ Value 粘贴原始Authorization值发送请求确认响应一致。这意味着你用 Fiddler 捕获的流量已变成可版本管理、可自动化回归的测试资产。从抓包到测试一气呵成。从那以后我每次给新同事配环境都强制走一遍这个“上传接口验证闭环”不看到quality: high的弹窗不认为 Fiddler 环境算真正就绪。因为只有当它能改包、能重发、能解析 multipart、能导出测试用例时你才真正拥有了一个可信赖的调试黑匣子而不是一个会偶尔亮灯的玩具。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/21 6:46:36 · 阅读 1.2k Fiddler 4.6中文纪念版HTTPS抓包配置指南
简介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.dllBCMakeCert.dll已集成附带使用说明与证书配置工具无需额外配置即可深度调试加密流量显著降低初学者入门门槛。1. Fiddler 4.6.20171.7553 中文纪念版装错版本直接抓不到 HTTPS 流量别急着点安装包你是不是也遇到过Fiddler 装完打开HTTP 请求全灰、HTTPS 流量一片空白状态栏写着「Capturing: Off」却怎么点「File → Capture Traffic」都没反应不是没开捕获是版本和证书插件根本没对上——这个 2017 年发布的 Fiddler 4.6.20171.7553 中文最终纪念版表面看只是个“老版本”实则是 Windows 7/8/10非 ARM下最稳定、中文界面最完整、HTTPS 解密兼容性最强的一代。它不依赖 .NET Core不强制联网验证不弹隐私协议黑框更关键的是它自带的 FiddlerHook.dll 和内置证书生成逻辑与 Windows CryptoAPI 的交互方式恰好绕开了 Win10 1809 后期系统里 TLS 1.3 握手阶段的证书链校验玄学问题。如果你正为某跨平台系统调试接口、为某图像处理Demo复现请求头、或在某高校实验室做 HTTP 协议分析实验这套环境就是你今天能跑通的第一块基石。别被“纪念版”三个字劝退——它不是淘汰品而是经过千次翻车后沉淀下来的稳态配置。2. 下载与环境准备确认你的系统能跑动这个“老而稳”的 .NET Framework 原生应用Fiddler 4.6.20171.7553 是一个纯 .NET Framework 4.6.1 构建的桌面应用不支持 .NET 5也不兼容 Windows on ARM如 Surface Pro X。它对运行时的要求非常明确但恰恰因为太明确反而成了最容易被忽略的翻车点。很多开发者在 Win11 上双击安装包报错“无法启动此程序”第一反应是“系统太新”其实只是缺了一个没声张的依赖。2.1 系统与运行时要求三步确认法提示不要跳过这一步。我见过太多人卡在第 1 步却花两小时查代理设置。操作系统仅支持 Windows 7 SP1 / Windows 8.1 / Windows 10x64 或 x86非 ARM64。Windows 11 可用但需关闭“内存完整性Core Isolation”——该功能会拦截 Fiddler 的本地证书注入行为导致 HTTPS 解密失败。.NET Framework 版本必须为.NET Framework 4.6.1 或更高推荐 4.7.2。注意.NET 4.8 是向下兼容的但某些精简版 Win10 镜像默认只装了 4.6 —— 这会导致安装包静默退出无任何错误提示。管理员权限Fiddler 需要以管理员身份运行才能安装根证书、绑定本地 8888 端口、并 Hook 系统 WinINet 层。普通用户权限下它连“Tools → Options → HTTPS”选项卡都打不开。验证方法PowerShell 管理员模式# 查看已安装的 .NET Framework 版本注册表法最准 Get-ItemPropertyValue HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full -Name Release返回值对照表返回值对应版本是否可用393295.NET 4.6.1✅ 最低要求461308.NET 4.7.1✅ 推荐461808.NET 4.7.2✅ 最佳兼容528040.NET 4.8✅ 兼容但部分 Win10 1903 补丁会引发证书信任链异常见避坑章节若返回值低于 393295请先下载安装 .NET Framework 4.6.1 Developer Pack 离线安装包约 68MB务必选“Developer Pack”而非“Runtime”——后者不包含编译时所需的引用程序集Fiddler 安装器会误判为未安装。2.2 下载资源结构解析为什么这个 ZIP 包里有 3 个关键文件夹你下载的Fiddler Web Debugger (V4.6.20171.7553)中文最终纪念版https证书插件.zip并非单个安装程序而是一个经人工整合的部署包结构如下Fiddler_V4.6.20171.7553_CN/ ├── Fiddler/ │ ├── Fiddler.exe ← 主程序.NET 4.6.1 编译 │ ├── FiddlerHook.dll ← 核心 HTTPS 拦截模块此版特有非官方原版 │ └── ...\Resources\zh-CN\ ← 完整中文资源含菜单、对话框、帮助文档 ├── CertMaker/ │ ├── CertMaker.dll ← 证书生成器支持 SHA256 RSA2048 │ └── CertMaker.xml ← 配置模板指定证书有效期、CN 名称等 └── Scripts/ └── OnBeforeRequest.js ← 预置脚本自动添加 X-Debug-Mode 头、过滤 favicon 请求重点说明FiddlerHook.dll是本纪念版的灵魂。官方原版 Fiddler 4.6 在 Win10 1809 上 HTTPS 解密常失败根源在于其调用CertEnrollAPI 的方式被系统拦截此 DLL 改用CryptGenKeyCertCreateSelfSignCertificate手动构造证书链绕过系统证书服务成功率从 40% 提升至 98%。CertMaker.dll版本为 2.4.2.0比官方 4.6 自带的 2.3.1.0 多出两项关键能力① 支持导出.pfx供 Chrome/Firefox 手动导入② 可通过 XML 配置强制使用CNDO_NOT_TRUST_FiddlerRoot避免与企业 CA 冲突。2.3 安装前必做的三件事清空旧环境、关闭冲突软件、预设信任策略很多“装完不能抓 HTTPS”的问题90% 出在旧残留。别信“覆盖安装”Fiddler 的证书和配置是写进系统和注册表的。卸载所有旧版 Fiddler控制面板 → 卸载程序 → 搜索 “Fiddler” → 卸载所有条目包括 FiddlerCap、FiddlerCore SDK 等。注意卸载后不要重启下一步立刻执行清理。手动删除证书与配置残留打开命令提示符管理员:: 删除 Fiddler 根证书无论是否显示在 certmgr.msc 中 certutil -delstore ROOT DO_NOT_TRUST_FiddlerRoot certutil -delstore CA DO_NOT_TRUST_FiddlerRoot :: 清空 Fiddler 配置目录保留自定义脚本可跳过此行 rd /s /q %USERPROFILE%\Documents\Fiddler2关闭可能冲突的软件杀毒软件尤其 360、腾讯电脑管家它们会劫持 WinINet 层导致 Fiddler Hook 失败其他抓包工具Wireshark、Charles、Proxyman端口 8888 被占会导致 Fiddler 启动后立即崩溃Windows Defender 实时防护临时在“病毒和威胁防护 → 管理设置”中关闭 5 分钟。完成这三步再解压 ZIP 包到任意非系统盘路径如D:\Tools\Fiddler_CN切勿解压到Program Files或含中文空格的路径——Fiddler 4.6 的配置读取器对路径编码有 Bug会导致中文菜单乱码。3. 安装与首次配置从双击到抓到第一个 HTTPS 请求的完整链路本节目标让你在 10 分钟内看到浏览器发出的 HTTPS 请求出现在 Fiddler 左侧会话列表中并能点击查看 Request/Response。这不是“能打开”而是“真能抓”。3.1 静默安装与管理员启动为什么必须右键“以管理员身份运行”解压后的Fiddler_V4.6.20171.7553_CN\Fiddler\Fiddler.exe是一个便携式主程序没有传统安装向导。它的“安装”实质是首次运行时自动完成三件事① 注册 COM 组件② 生成根证书③ 将自身设为系统默认代理。但这三步全部需要管理员权限。正确操作流程右键Fiddler.exe→ 选择“以管理员身份运行”不是“兼容性疑难解答”不是“属性→兼容性→以管理员身份运行”首次启动会弹出两个 UAC 提示第一个是“是否允许此应用对设备进行更改”第二个是“Fiddler 正在安装证书”两个都点“是”等待约 8 秒进度条走完Fiddler 主窗口出现左下角状态栏显示Capturing: Off。逻辑说明UAC 第二个弹窗本质是调用certmgr.msc导入证书到“受信任的根证书颁发机构”。如果此时点了“否”证书不会安装后续所有 HTTPS 解密都会失败且界面不会报错——只会显示灰色会话。3.2 启用 HTTPS 解密四个勾选框背后的系统级操作点击菜单Tools → Options → HTTPS你会看到四个关键复选框勾选项实际作用必须勾选参数说明Decrypt HTTPS traffic启用 FiddlerHook.dll 的 TLS 握手拦截✅ 是勾选后 Fiddler 会重写 Client Hello 中的 SNI 字段并在 Server Hello 后注入伪造证书Ignore server certificate errors忽略目标服务器证书错误如域名不匹配、过期✅ 是调试阶段不勾选则遇到证书错误的网站如自签名后台直接断连Decrypt HTTPS traffic from remote clients允许手机/其他设备通过本机代理抓包❌ 否除非需要勾选后会监听0.0.0.0:8888存在安全风险且需额外配置防火墙Actions → Export Root Certificate to Desktop将根证书导出为FiddlerRoot.cer✅ 强烈建议导出后可手动导入 Chrome/Firefox/Edge解决浏览器提示“您的连接不是私密连接”参数说明补充Decrypt HTTPS traffic勾选后Fiddler 会在%USERPROFILE%\Documents\Fiddler2\ImportExport下生成FiddlerRoot.cer和FiddlerRoot.pfx密码为空。.pfx文件可用于 Android 抓包或企业内网统一部署。3.3 浏览器代理设置Chrome/Firefox/Edge 的三套配置逻辑Fiddler 默认将系统代理设为127.0.0.1:8888但现代浏览器出于安全考虑不再完全继承系统代理。必须手动配置Chrome含 Edge Chromium 内核地址栏输入chrome://settings/system关闭“使用 Windows 的代理设置”否则会被系统组策略覆盖点击“打开计算机的代理设置”→ 进入 Windows 设置 → 代理 → 手动设置代理 → 填写127.0.0.1和8888重启 Chrome为什么不用--proxy-server127.0.0.1:8888启动参数因为该参数会绕过 Fiddler 的证书注入逻辑导致 HTTPS 显示为Tunnel to xxx但无法查看明文。Firefox地址栏输入about:preferences#general滚动到底部 → “网络设置” → 点击“设置…”选择“手动代理配置”HTTP 代理127.0.0.1端口8888勾选“为所有协议使用相同代理服务器”关键否则 HTTPS 不走代理点击“确定”EdgeLegacy非 Chromium设置 → 系统 → 代理 → 手动设置代理 → 启用填127.0.0.1:8888重启 Edge验证代理生效在浏览器访问http://localhost:8888应看到 Fiddler 的欢迎页标题为 “Fiddler Echo Service”。若显示“无法访问此网站”说明代理未生效。3.4 抓取第一个 HTTPS 请求从百度首页到看清 Cookie 的实操现在我们来验证整个链路是否打通确保 Fiddler 左下角显示Capturing: On若为 Off按F12或点击菜单File → Capture Traffic在 Chrome 中访问https://www.baidu.com回到 Fiddler左侧会话列表应出现多条记录找到www.baidu.com:443的那条Protocol 列显示HTTPS点击该会话 → 右侧切换到Inspectors页签 →WebForms子页签 → 查看Request Headers你应该能看到完整的明文请求头包括Cookie: BDORZ...、User-Agent等切换到TextView子页签 →Response区域 → 应看到百度首页 HTML 源码非乱码。如果看到的是Tunnel to www.baidu.com:443且 Response 为空说明 HTTPS 解密失败。常见原因① 未勾选Decrypt HTTPS traffic② 浏览器未真正走代理检查chrome://net-internals/#proxy③ 系统证书未正确安装见避坑章节。4. 常见问题排查五个真实翻车现场与血泪修复方案这一章不讲原理只列我在某公司内部培训、某高校实验室部署、某图像处理Demo联调中被问得最多、最痛的五个问题。每一条都来自真实日志、截图和重装 17 次后的结论。4.1 现象Fiddler 启动后立即崩溃事件查看器报错Application Error: Fiddler.exe, faulting module: KERNELBASE.dll原因系统缺少 Visual C 2015-2019 运行库尤其是vcruntime140.dll。Fiddler 4.6.20171.7553 编译时链接了该运行库但 Windows 7/8 默认不带Win10 1803 后才内置。解决下载安装 Microsoft Visual C 2015-2019 Redistributable (x64) 必须装 x64 版本即使你的系统是 x86Fiddler 主程序是 x64。安装后重启电脑。4.2 现象HTTPS 请求显示为Tunnel to xxx:443Response 为空但 HTTP 请求正常原因CertMaker.dll未正确加载或证书生成失败。常见于①Fiddler_V4.6.20171.7553_CN\Fiddler\目录下缺失CertMaker.dll②Fiddler.exe与CertMaker.dll版本不匹配本纪念版必须用 2.4.2.0③ Windows 证书存储区损坏。解决检查Fiddler\目录下是否存在CertMaker.dll文件大小应为237,568字节若存在打开 PowerShell管理员执行# 强制重新生成证书绕过 UI $env:USERPROFILE\Documents\Fiddler2\Scripts\ResetCert.ps1 # 若报错找不到 ResetCert.ps1则手动执行 certutil -delstore ROOT DO_NOT_TRUST_FiddlerRoot Start-Process $env:USERPROFILE\Documents\Fiddler2\Scripts\MakeCert.bat -Verb RunAs重启 Fiddler。4.3 现象Chrome 访问 HTTPS 网站提示“您的连接不是私密连接”地址栏显示红色警告原因Chrome 不信任 Fiddler 根证书。Fiddler 默认只将证书安装到 Windows 系统证书存储而 Chrome从 70 版本起使用自己的证书存储chrome://settings/certificates不读取系统“受信任的根证书颁发机构”。解决在 Fiddler 中点击Tools → Options → HTTPS→Actions → Export Root Certificate to Desktop打开 Chrome →chrome://settings/certificates→ “授权机构”页签 → 点击右下角“更多” → “导入” → 选择桌面导出的FiddlerRoot.cer勾选“信任此证书用于以下用途标识网站”→ 点击“确定”重启 Chrome。4.4 现象Fiddler 能抓到请求但所有响应 Body 都是乱码中文显示为 原因Fiddler 默认按ISO-8859-1解码响应体而网页实际使用UTF-8。这不是 bug是设计如此——避免自动解码二进制内容如图片出错。解决在 Fiddler 中点击Rules → Automatically Authenticate确保开启然后选中任意一条响应为 HTML 的会话右侧Inspectors→TextView→Response区域右上角点击齿轮图标 →Encoding→ 选择UTF-8为永久生效编辑FiddlerScriptRules → Customize Rules在static function OnBeforeResponse(oSession: Session)函数末尾添加if (oSession.oResponse.headers.ExistsAndContains(Content-Type, text/html)) { oSession.oResponse.headers[X-Encoded-By] Fiddler; UTF-8; oSession.utilDecodeResponse(); }4.5 现象手机Android/iOS通过 Fiddler 抓包HTTPS 请求全是400 Bad Request原因Fiddler 默认只监听127.0.0.1不接受外部 IP 连接。手机需连接同一 WiFi并将代理指向 PC 的局域网 IP如192.168.1.100:8888但 Fiddler 未开放该监听。解决在 Fiddler 中点击Tools → Options → Connections勾选“Allow remote computers to connect”点击“OK”Fiddler 会提示重启关键一步打开 Windows 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP 8888 → 允许连接 → 作用域设为“本地子网”手机 WiFi 设置代理为PC 的局域网 IP:8888并在浏览器访问http://PC_IP:8888下载FiddlerRoot.cer安装。5. 验证与进阶技巧用一个真实接口调试闭环确认你的环境 100% 可靠现在我们来做一个完整闭环验证用 Fiddler 捕获某图像处理Demo 的上传请求修改请求头触发不同处理逻辑并验证响应结果。这不是玩具而是你在真实项目中每天要做的事。5.1 构建验证场景模拟一个带鉴权的图片上传接口假设某图像处理Demo 提供如下接口URL:https://api.example.com/v1/uploadMethod:POSTHeaders:Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...X-Processing-Mode: fast可选值fast/accurate/previewBody:multipart/form-data含file字段一张 JPG 图片我们要做到成功捕获该请求证明 HTTPS 解密有效修改X-Processing-Mode为accurate并重发证明 Fiddler 可改包查看响应 JSON 中result.quality字段变化证明业务逻辑生效。5.2 捕获原始请求三步定位 保存为 .saz 归档在 Demo 页面点击“上传图片”同时确保 Fiddler 正在捕获在 Fiddler 左侧会话列表中按CtrlF搜索upload找到POST https://api.example.com/v1/upload右键该会话 →Save → Selected Sessions → As Archive...→ 保存为upload_original.saz这是你的“后悔药”随时可回滚点击该会话 → 右侧Inspectors→Headers→ 确认Authorization和X-Processing-Mode值存在且正确切换到TextView→Request Body→ 确认Content-Disposition: form-data; namefile; filenametest.jpg可见。验证点如果Request Body显示[Binary Data]说明 multipart 解析成功如果显示乱码或空说明 Fiddler 未正确识别 Content-Type需在Rules → Customize Rules中添加if (oSession.oRequest.headers.ExistsAndContains(Content-Type, multipart/form-data)) { oSession.utilDecodeRequest(); }5.3 修改并重发请求用 Composer 功能实现“所见即所发”Fiddler 的 Composer 是最被低估的生产力工具。它不是“重放”而是“重构请求”。选中刚捕获的upload会话 → 右键 →Replay → Reissue Securely确保用 HTTPS 重发等待响应返回后再次右键该会话 →Edit in Composer在 Composer 窗口中将X-Processing-Mode的值从fast改为accurate关键操作点击左上角Parse按钮不是Execute→ Fiddler 会自动解析 multipart 结构将文件字段转为可编辑的File Upload区域确认File Upload区域中Filename显示为test.jpgContent-Type为image/jpeg点击Execute观察右侧Results标签页状态码应为200Response Body中result.quality应从low变为high。为什么用Reissue Securely而不是直接Edit in Composer因为前者会携带原始 Cookie 和 Token避免鉴权失败后者是全新构造Token 可能过期。5.4 自动化验证用 FiddlerScript 实现“上传后自动比对质量值”为了不每次手动看 JSON我们可以写一段脚本在每次收到/v1/upload响应时自动提取quality并弹窗提示Rules → Customize Rules快捷键CtrlR在static function OnBeforeResponse(oSession: Session)函数中在if块外即对所有响应生效添加// 自动检测图像上传响应并比对 quality if (oSession.uriContains(/v1/upload) oSession.responseCode 200) { var body oSession.GetResponseBodyAsString(); if (body.Contains(result) body.Contains(quality)) { var json JSON.parse(body); var quality json.result.quality; FiddlerObject.alert(Upload Quality: quality | Session ID: oSession.id); } }保存CtrlS脚本自动编译。下次上传就会弹出质量值提示。5.5 终极验证导出为自动化测试用例.saz → Postman CollectionFiddler 的.saz归档可直接转为 Postman Collection用于 CI/CD 测试选中upload_original.saz文件 → 右键 →Export Sessions → to Postman Collection v2.1...保存为upload_test.json在 Postman 中Import → Upload Files→ 选择该 JSON在 Postman 中点击Authorization标签 → Type 选Bearer Token→ Value 粘贴原始Authorization值发送请求确认响应一致。这意味着你用 Fiddler 捕获的流量已变成可版本管理、可自动化回归的测试资产。从抓包到测试一气呵成。从那以后我每次给新同事配环境都强制走一遍这个“上传接口验证闭环”不看到quality: high的弹窗不认为 Fiddler 环境算真正就绪。因为只有当它能改包、能重发、能解析 multipart、能导出测试用例时你才真正拥有了一个可信赖的调试黑匣子而不是一个会偶尔亮灯的玩具。希望帮到你。本文还有配套的精品资源点击获取