简介：Fiddler 是广受开发者欢迎的网络调试工具，这份安装包面向需要抓包分析、接口调试与性能排查的 Web 前端、后端开发及测试人员，解决查看 HTTP/HTTPS 交互细节、定位接口异常、优化网页加载等常见问题。包内共 90 个文件，涵盖 Fiddler 主程序、36 个 DLL 运行库、13 个 EXE 辅助工具、13 个 PDB 调试符号，以及配置文件、提示音、图标、说明文档和自定义脚本样例，压缩后仅 5.5MB，便于快速下载部署。目前已有 574 人学习下载。压缩包包含完整安装与运行组件，支持解密 HTTPS 流量、修改请求/响应、断点调试等核心功能，同时提供证书信任相关工具和自定义脚本示例，可帮助读者快速搭建调试环境并上手自动化网络模拟。对希望深入理解 Fiddler 工作原理、扩展插件或进行网络层问题排查的开发者来说，这套精简资源提供了扎实的基础环境与可参考的脚本模板。 先说个背景：我最早接触 Fiddler，就是因为手头一个命名为“Fiddler安装包.zip”的文件。解压之后里面没有 setup.exe，只有一个可执行程序、一个配置文件夹和一堆说明文档。当时我理解它只是“听说能抓包”，第一反应其实是“这东西到底怎么才能跑起来”。后来折腾完 HTTPS 证书、手机代理、过滤、弱网模拟，才意识到 Fiddler 的真正价值远不止“看一眼请求数据”这么简单。这篇就顺着我从 zip 包开始折腾 Fiddler 的完整路径，把下载、安装、汉化、常用功能和踩过的坑挨个说清楚，尤其适合刚接触抓包、又被网上各种“绿色精简 zip 版”搞蒙的朋友。
1. Fiddler 到底是什么，以及为什么会以 zip 包形式出现
1.1 一个 HTTP/HTTPS 调试代理的核心定位
Fiddler 本质是一个运行在本地、监听在你电脑某个端口上的调试代理服务器。它会把本机应用发出的 HTTP/HTTPS 请求先拦下来，记录完整报文，再转发给真正的服务器；服务器返回的响应同样会被它截获、解析、展示。听起来很简单，但能做的事情非常多：看请求头和响应头、检查 Cookie 和表单参数、给请求/响应打断点、把线上资源替换成本地文件、模拟弱网环境、定位前后端联调时谁拿到的数据不对。
我在团队里最常用的场景是联调阶段：前端说“接口返回的数据不对”，后端说“我这边响应是对的”，双方扯皮时让 Fiddler 交出中间人视角的完整报文，谁也别争。另一个高频场景是移动端调试：手机连着和电脑同一个 Wi-Fi，把 Fiddler 的代理地址填到手机 Wi-Fi 设置里，手机上 App 的接口请求就能在电脑上全部看到。
1.2 为什么网上流传的版本经常是“Fiddler安装包.zip”
Fiddler 官方主推的下载形态其实是安装 exe，或者通过应用商店/包管理器安装，并不提倡绿色 zip 分发。但很多老博客、网盘分享、培训课程为了方便离线分发，会把已经装好、甚至已经汉化的 Fiddler 目录直接压缩成 zip 丢出来，于是“Fiddler安装包.zip”就这么出现在你面前。
这类第三方 zip 包里，有的是官方安装完再打包，能用；有的则会夹带私货，比如修改了默认代理端口、塞了预设脚本、篡改了 hosts 设置，甚至捆绑其他东西。所以拿到 zip 包，我建议先做两件事：
- 第一，看文件数字签名。右键主程序 Fiddler.exe，切到“数字签名”标签页，确认签名的主题是 Telerik/Progress Software 相关的合法发布者。绿色破解版经常没有签名，或签名机构是乱七八糟的个人。
- 第二，比对哈希。在官方页面找到对应版本的 SHA256 或 MD5，本地用
certutil -hashfile Fiddler.exe SHA256算出来对一下，一致再双击运行。
如果实在不确定，最稳妥的做法是放弃 zip 版，直接去 Telerik 官方页面下载 Fiddler Classic 安装包自己装一次。多花五分钟，能省掉后面一连串“为什么抓不到包”的排查时间。
2. 安装与汉化：从压缩包到可用的中文环境到底经历了什么
2.1 官方安装程序的关键交互点
Fiddler Classic 官方安装过程非常简单，基本都是下一步下一步，但有两个交互点值得留意。
第一个是端口选择。安装完第一次启动，Fiddler 会默认把自己设为系统代理，监听 8888 端口。很多机器上 8888 已经被其他本地服务占用了，比如有的 PHP 环境、Docker 映射、或者另一个代理工具。如果启动后左下角一直提示“代理注册失败”，大概率是端口被占。解决办法是提前在安装时就改端口，或者在 Tools → Options → Connections 里修改“Fiddler listens on port”，改完重启再勾选“Act as system proxy on startup”。
第二个是证书相关的组件。安装过程中 Fiddler 会写入一个名为 CertMaker 的证书生成组件，负责动态签发用于 HTTPS 解密的根证书。如果安装时被杀毒软件拦截了 CertMaker.dll 的写入，那之后开启 HTTPS 解密时往往会报“证书生成失败”。遇到这种情况，我一般先把杀毒软件对 Fiddler 目录的实时防护临时关掉，卸载重装，装好后再加白名单。
2.2 汉化方案的选择与风险
Fiddler 官方界面是英文的，国内很多教程会顺手提供一个“汉化版 zip”。市面上流传的汉化方式大概有三种：替换 Fiddler.exe 或以 Fiddler.UI.* 命名的程序集、覆盖语言文件（Language.xml 或其他语言目录）、以及基于插件式的汉化包。
我的建议：能用语言文件方式的，不要动 exe 程序集。exe 级别的汉化对二进制改动很大，杀毒软件报毒概率高，而且版本一旦升级就失效。语言文件方式相对温和，但也一定记得先备份原始语言文件，汉化后界面如果出现方块字、按钮跑偏，说明字符编码或字体不匹配，立刻还原。
需要提醒的是，Fiddler 最核心的很多功能其实不依赖界面语言。抓包列表、Inspectors、AutoResponder 这些核心功能，英文界面对照网上教程也完全能对上。把时间花在理解每一列代表什么意思、响应编码怎么切换，比纠结按钮叫“保存”还是“Save”要有价值得多。
3. 抓包前的必配三件事：HTTPS 解密、代理监听与移动端接入
3.1 本地 HTTPS 解密：为什么你光开代理看不到请求内容
很多新手第一次开 Fiddler，发现能抓到一大堆请求，但打开某条 HTTPS 请求后，Inspectors 里全是乱码，或提示“This request could not be decrypted”。原因很简单：HTTPS 是加密的，Fiddler 必须生成一个本地根证书，并让操作系统信任它，才能以中间人方式解密流量。
操作路径是 Tools → Options → HTTPS，勾选 Decrypt HTTPS traffic，弹窗问是否信任 Fiddler 的根证书，选 Yes。之后去 Windows 的证书管理列表里，能看到“受信任的根证书颁发机构”下多了一条名为 DO_NOT_TRUST_FiddlerRoot 的证书。这个名字确实吓得人，但它只是官方故意的警告式命名，意思是“只有调试时才信任这个证书”，调试结束后可以删除。
这里有个经验：企业内网机器如果装了公司统一下发的安全管理证书，Fiddler 的根证书信任后偶尔会冲突，导致某些内网系统打不开。这时候可以只在需要用 Fiddler 的浏览器或应用里单独启用代理，而不是全局系统代理。我自己的做法是日常不勾选“Act as system proxy on startup”，需要用的时候再手动开启，用完立刻关。
3.2 手机抓包：从代理设置到证书安装
移动端抓包是 Fiddler 的高频用法。先把电脑和手机连到同一个局域网，记下电脑的局域网 IP。然后在 Fiddler 的 Tools → Options → Connections 里勾选 Allow remote computers to connect，这个选项不勾的话，手机发来的请求会被直接拒绝。端口保持 8888，电脑防火墙如果弹窗，允许专用网络访问。
手机端设置其实不复杂：
- Wi-Fi 里选择当前网络，把代理设为“手动”。
- 主机名填电脑 IP，端口填 8888。
- 用手机浏览器访问
http://电脑IP:8888，页面里有一个 FiddlerRoot certificate 下载链接，点开下载并安装证书。
安卓 7.0 以后有个麻烦：用户安装的证书默认不被 App 信任，系统只信任系统级证书，所以很多 App 你会看到请求列表里有一堆 CONNECT 或直接超时。解决思路是把用户证书转成系统证书：先用某种方式把证书导出成 pem/cer 文件，计算哈希文件名，然后用 adb 的 root 或模拟器把文件推到/system/etc/security/cacerts/下并改权限。这个操作在真机上要 root，所以我优先推荐在模拟器里做，省事且不折腾主设备。
iOS 端证书安好后，还要去“设置 → 通用 → 关于本机 → 证书信任设置”里把 Fiddler 的根证书开关打开，否则 Safari 和其他 App 依然会证书校验失败。这步漏掉的人非常多，典型症状就是证书明明装了，但 App 仍然请求失败。
3.3 只过滤自己关心的域名，别被噪音淹没
不设置过滤的抓包体验非常痛苦：浏览器扩展、后台服务、系统更新请求全混在一起，列表刷得飞快，想定位一个接口得瞪大眼睛找半天。Fiddler 的过滤器在右下角 Filters 标签页里，勾选 Use Filters，然后在 Hosts 区块的第二个下拉框选择“Show only the following Hosts”，把目标域名填进去，比如api.example.com，点击动作生效后列表基本就清净了。
过滤规则里也支持通配：*.example.com能匹配该域名下所有子域。还有人喜欢先用左下角 QuickExec 命令输入框输入select image或select css，快速把所有图片或 CSS 请求标黄，这在找“哪个资源加载不出来”时很管用。总的思路是：一开始抓全量，定位到目标后就立刻开过滤，减少干扰。
4. 进阶使用：弱网模拟、响应替换和 QuickExec 的日常打法
4.1 弱网测试不只是“模拟调制解调器速度”
Fiddler 自带一个极简弱网功能：Rules → Performance → Simulate Modem Speeds，勾选后所有请求会被强行加上延迟，模拟拨号上网年代的龟速。这个功能只能用来“简单粗暴地看页面有多卡”，不能精确控制具体网速。
真正想按 2G/3G/4G 的场景来测，需要改脚本：Rules → Customize Rules，打开脚本编辑器，在 OnBeforeRequest 方法里加入类似这样的代码：
if (m_SimulateModem) { // 每 KB 数据延迟 10ms，约为 100KB/s oSession["request-trickle-delay"] = "10"; }数值含义是每个请求每发送 1KB 数据人为延迟多少毫秒。比如想模拟一个下行约 100KB/s 的网络，1000ms 除以 100KB 得到每 KB 10ms，就填10。完整的规则里还要在 OnBeforeResponse 里给响应也加延迟，通常响应延迟更大，因为下行流量远大于上行。这个脚本改完要保存并重新加载，Fiddler 会立刻应用新策略。实测下来，这个方案虽然远不如网卡级弱网工具精确，但胜在零依赖、可控，日常验证接口页面在慢网下的表现完全够用。
4.2 AutoResponder：造数据、拦截接口的一把利器
开发联调时最讨厌的情况是什么？后端没写好、测试环境数据被污染、第三方接口不配合。AutoResponder 能解决一部分这类麻烦。
打开 AutoResponder 标签页，勾选 Enable rules，再勾选 Unmatched requests passthrough，意思是“没匹配到的请求照常放行”。然后新建规则，比如把线上某个 JS 文件直接替换成本地改过的文件：
- 规则匹配项填：
regex:.*costom\.js - 规则动作选：
200-SimpleHTML并指定本地文件路径，或者直接填一个文件路径。
实际调试接口时，还可以把一个响应整体替换为自定义 JSON：
`http://example.com/api/getinfo` → `200-OK` Response body 填入自定义 JSON这里有一个特别容易被忽略的细节：如果替换的是 JSON 接口，记得在响应头里带上Content-Type: application/json，否则前端拿到的可能是乱码或解析失败。AutoResponder 的匹配语法里，EXACT:表示精确完整匹配，regex:是正则，其余情况默认作为 URL 通配模式。优先级从上往下匹配，第一条命中了就不再往下走，所以通用规则要放在下面，精确规则放上面。
4.3 QuickExec：键盘党的主控台
Fiddler 左下角那个看起来不起眼的小输入框，其实是一个命令行入口，叫 QuickExec。我最常用的命令有几个：
?keyword：只高亮显示 URL 中含有 keyword 的会话，比翻半天列表舒服。select image：把所有图片类型的响应标黄。cls：清空当前会话列表，比鼠标点 Remove All 快得多。bps 500：给状态码为 500 的响应打断点，改后端错误响应测试前端容错。bpafter txt：给 URL 里含 txt 的响应打断点。!：显示所有命令帮助。
这些命令本质上是在调 Fiddler 内部的脚本函数，比一层层点菜单高效不少。更妙的是，QuickExec 支持在命令前直接输入一个 URL，按回车就能让浏览器打开该 URL 并自动抓包。我一般会在开始一轮新测试前先cls清空会话，再通过 QuickExec 拉起目标页面，这样拿到的会话列表非常干净。
5. 从“Fiddler安装包.zip”延伸出的 zip 经典故障与排查思路
5.1 invalid zip archive: could not find eocd 的根因
以“Fiddler安装包.zip”为引子，绕不开 zip 本身的那些破事。很多人在 Github 下载 zip 项目、解压 Fiddler 版本包、或导入离线依赖包时，会碰到一行明显吓人的报错：
invalid zip archive: could not find eocd这里的 EOCD 指 End of Central Directory Record，就是 zip 文件末尾一段用来记录索引信息的特殊结构。解压工具靠它定位文件列表，找不到 EOCD，整个 zip 就被判定为不完整或损坏。出现这个报错的原因排行大致是：
- 下载没完成就被拿去用了，常见于浏览器断点续传后文件不完整。
- 某些网盘/HTTPS 下载工具在传输过程中改了文件头。
- zip 文件被压缩工具以“自解压格式”或“分卷格式”生成，后缀却还叫 zip。
- 文件被安全软件隔离，只剩一个占位文件或 0 字节文件。
排查思路很简单。先看文件大小，压缩包一般不会是个整齐的整数，如果大小奇怪，比如几百 KB 的 Fiddler 安装包 zip，基本可以断定下载不完整。然后用 7-Zip 的“测试”功能直接跑一遍压缩包完整性，7-Zip 会明确告诉你哪个文件 CRC 失败。最后比对来源站点提供的哈希值，本地算出来不一致，那就甭想了，重新下载。
5.2 汉化包引发的“打不开”和“证书失效”
前面提到的汉化如果用了替换 exe 的方式，最容易出现的问题不是界面没变，而是程序启动后报错，或者 HTTPS 解密功能直接失效。原因在于 Fiddler 的证书生成逻辑和版本号强相关，某些汉化包是从旧版本里改出来的，覆盖到新版后签名失效、依赖缺失就报错。
遇到这种情况，最快的方式是回到最初那个 zip 包，把备份的原始 exe 还原回去。如果当初没备份，那就只能重新下载。我在团队里多次强调过一句话：汉化和工具升级不能同时进行，升级前必须先把汉化还原，否则一堆莫名问题根本没法定位。
还有一个隐蔽坑：杀毒软件会把经过修改的 Fiddler.exe 判定为恶意软件并直接隔离，表面表现是 Fiddler 突然打不开、证书目录被清空、系统代理被重置。排查时除了看事件日志，也要顺手看一眼杀毒软件的隔离区，很多冤枉的“报错”其实就是被隔离后留下的残留问题。
5.3 抓不到包时的排查链路，别跳过系统代理这一步
Fiddler 抓不到包是提问率最高的问题之一。最常见的表现有：开 Fiddler 后浏览器所有网页打不开（代理指向了但 Fiddler 没工作）、开着 Fiddler 但列表里只有 CONNECT 没有实际请求、关闭代理后一切又恢复正常。
我的排查顺序大致是：
- 确认 Fiddler 中 Tools → WinINET 或“Act as system proxy on startup”是否处于生效状态。浏览器里打开“Internet 选项 → 连接 → 局域网设置”，如果代理地址不是
127.0.0.1:8888，说明代理没生效或别的工具改掉了。 - 确认端口没被占用。命令行
netstat -ano | findstr 8888，看监听进程是不是 Fiddler。 - 确认目标请求走的是 HTTP 或 HTTPS，域名解析有没有走系统代理。有些服务用 Socket 直连、不走系统代理，Fiddler 默认看不见，需要在 FiddlerScript 里注册连接事件，或者改用透明代理模式。
- 确认时间戳不是过去时间。有的电脑系统时间不准，Fiddler 对证书有效期校验很敏感，时间偏了会导致 HTTPS 请求全部失败。
如果只是抓本机访问http://localhost的流量，Fiddler 有个已知限制：默认不捕获本机回环流量。最简单的规避办法是访问时把 localhost 写成http://localhost.:端口，最后加个点强制走代理，或者用http://127.0.0.1:端口一般也能抓到。
6. 最后分享一点关于工具的长期使用体会
Fiddler 这种代理类调试工具，和 IDE 里的 Debugger 一样，属于“平时不觉得，一旦出问题就离不开”的配置型工具。它不像代码库里修复 Bug 那样有标准答案，更多是熟悉它每个开关的边界条件：代理什么时候生效、证书什么时候会被拦截、过滤规则什么时候会漏，把这些边界摸清楚，之后遇到任何请求相关的问题都能快速缩小范围。
另外我也建议大家，如果只是随手用一次，用绿色 zip 版没问题；但如果是日常工作依赖的工具，还是老老实实装官方原版，保持英文界面。工具越稳定，你越可以把精力放在被调试的业务本身，而不是被工具的各种奇怪表现带走。抓包本身不神秘，核心是理解 HTTP 协议在真实网络环境里到底长什么样，而 Fiddler 恰恰是带你看到这一幕的最佳窗口之一。
本文还有配套的精品资源，点击获取
