简介：这份压缩包提供Fiddler中文版本，专为Web前端开发、后端联调及测试人员准备，解决抓包分析、接口调试与网络问题排查等需求。Fiddler是Telerik出品的HTTP(S)调试工具，中文界面大幅降低了国内用户的上手门槛，尤其适合刚接触网络协议的初学者。整个压缩包约6.02MB，下载部署非常轻量。工具支持完整记录客户端与服务器之间的会话，可实时修改请求头、响应体、参数或状态码；内置断点功能，可在数据发送前后暂停编辑；还提供JScript.NET脚本扩展、HTTPS流量解密、性能时间线分析，以及按URL、方法、状态码过滤会话等实用能力。配合Session面板管理、数据导入导出和Visual Studio等开发工具集成，能显著提升日常调试效率。目前已有1988人学习下载，无论是排查加密通信问题、优化网页加载速度，还是进行自动化测试与数据验证，这份中文版资源都能帮助你快速上手并深入理解网络通信过程。
1. Fiddler中文版本.zip 是什么：绕开英文界面，先认清这个包的真身
很多人第一次接触 Fiddler，就是在网上搜“Fiddler中文版本.zip”，下回来一个压缩包，解压之后发现里面躺着一个 Fiddler Classic 的安装程序外加一两个汉化文件——这就是这个标题背后最常见的真实形态。Fiddler 是一款以 HTTP/HTTPS 抓包调试为核心的桌面代理工具，它能让你看到本机或手机上的每个请求去了哪里、带了什么参数、返回了什么内容，也能让你手动改请求、模拟弱网、断点调试接口。适合谁？前端排查接口问题、后端联调时看实际报文、测试人员做弱网场景验证，以及刚入门想搞懂“数据到底怎么从浏览器发到服务器”的开发者。
这里要先说一句得罪人的实话：Fiddler 官方版本从来只提供英文界面，所谓“中文版本.zip”都是第三方汉化产物，而且网上流出的包质量参差不齐，有的带捆绑安装、有的汉化文件跟 Fiddler 版本不匹配导致菜单错乱。如果你想用顺手中文界面的抓包工具，又有稳定可复现的落地路径，这篇就是按“认版本、装环境、抓包、避开坑”的顺序来拆。
2. 从下载到中文界面：Fiddler 的版本选择与汉化落地
2.1 先分清 Fiddler Classic 和 Fiddler Everywhere，再决定下哪个包
Fiddler 官方现在有两条产品线，名字相似但定位完全不同，下载前不搞清楚，后面全是坑。Fiddler Classic 是经典的 Windows 免费版，体积小、启动快、支持 FiddlerScript 脚本定制，绝大多数教程和公司内部资料说的都是它，而且它本身就是便携解压后就能跑的工具，适合本地调试和测试机的临时抓包。Fiddler Everywhere 是后来的跨平台付费版，支持 Windows、macOS、Linux，界面更现代，但免费版有请求数量限制，且冒烟测试里最常用的断点功能和脚本扩展支持不如 Classic 灵活。
我的建议是：日常开发调试、弱网模拟、手机抓包这些高频操作，直接用 Fiddler Classic。这个版本虽然是英文界面，但核心菜单就那么几个，用熟了反而避免被汉化包里的错译误导。如果你确实需要中文界面，就只做汉化外壳的补充，不要替换核心文件。
在下载这个环节，最稳妥的路径是到官方站点获取 Fiddler Classic 的安装包，再用第三方汉化文件覆盖语言资源。这里绕开任何来路不明的“Fiddler中文版本.zip”，原因是这类聚合包里经常被塞进浏览器主页修改工具或静默安装程序，为了一个中文界面去冒这个险不值得。
2.2 用命令行参数做静默安装，规避安装器里的附加项
Fiddler Classic 的安装包支持静默安装参数，这是在一台干净的测试机上快速部署最常用的方式。把安装包和汉化文件放在同一个目录后，以管理员身份打开 PowerShell 执行如下操作：
# 静默安装 Fiddler Classic，关闭“运行后打开欢迎页”等交互选项 .\fiddler_setup.exe /S # 安装完成后找到程序目录，默认在 %LOCALAPPDATA%\Programs\Fiddler $fiddlerDir = Join-Path $env:LOCALAPPDATA "Programs\Fiddler" Write-Host "Fiddler 安装目录: $fiddlerDir"这里用/S参数让安装器跳过所有图形化交互，避免它默认勾选“启动时检查更新”或“安装桌面快捷方式”之外的捆绑项。安装结束后，程序目录下的Fiddler.exe就是主程序，首次启动它会自动把自己设置为系统代理，端口默认 8888。
参数说明：/S是 Inno Setup 安装器的通用静默参数（Fiddler Classic 的安装器基于它），大小写敏感；如果你需要指定安装路径，可以追加/DIR="D:\Tools\Fiddler"，但注意加了这个之后，系统代理相关的注册表项仍然会写入当前用户环境，不影响后续使用。如果不是管理员权限的 PowerShell，%LOCALAPPDATA%路径解析会指向当前用户目录，这一步不用额外提权。
2.3 汉化文件放置与语言切换的完整操作
汉化 Fiddler Classic 的原理并不复杂：它的界面文本资源打包在安装目录的Fiddler.exe同级的语言文件中，第三方汉化包做的就是把英文资源替换成中文。需要替换的通常是C:\Users\你的用户名\AppData\Local\Programs\Fiddler\下的Fiddler.exe对应的语言目录文件，或者某些汉化包直接替换Fiddler.exe本身。
以常见的“中文汉化补丁”结构为例，操作步骤如下：
# 1. 备份原始程序文件，后悔药必须留在手边 $srcExe = Join-Path $env:LOCALAPPDATA "Programs\Fiddler\Fiddler.exe" Copy-Item $srcExe "$srcExe.bak_EN" -Force Write-Host "已备份原版 Fiddler.exe 为 Fiddler.exe.bak_EN" # 2. 将汉化包中的 Fiddler.exe 覆盖到程序目录 # 假设汉化包已解压到 D:\fiddler_cn\ Copy-Item "D:\fiddler_cn\Fiddler.exe" $srcExe -Force Write-Host "汉化文件已覆盖" # 3. 启动 Fiddler，界面语言跟随系统区域自动加载 Start-Process $srcExe这里有一个容易翻车的细节：很多汉化包只替换Fiddler.exe，不替换FiddlerCore.dll和相关资源文件。新版 Fiddler Classic 的界面文本不完全在 exe 里，部分菜单字符串在FiddlerCore.dll、Fiddler.WebUITools.dll之中。如果你覆盖 exe 后启动，发现只有一半菜单变成中文，另一半仍是英文，说明这个汉化包只做了 shell 层汉化，继续使用会出现中英混杂的界面。
更稳妥的做法是找那种带Languages\zh-CN目录的汉化包，因为 Fiddler Classic 从较新的版本开始支持语言文件外置。操作方式如下：
# 在程序目录下创建 Languages\zh-CN 目录，放入语言资源文件 $langDir = Join-Path $env:LOCALAPPDATA "Programs\Fiddler\Languages\zh-CN" New-Item -ItemType Directory -Path $langDir -Force Copy-Item "D:\fiddler_cn\zh-CN\*" $langDir -Force # 启动后用菜单 Tools > Options > General > Language 切换为中文语言文件外置的玩法好处是：原版 exe 不用动，升级覆盖也不容易把汉化冲掉，而且可以从中文界面切回英文排错。汉化完成后，第一件事不是急着抓包，而是到Tools > Options > HTTPS里确认Capture HTTPS CONNECTs和Decrypt HTTPS traffic两个复选框的状态——汉化包不解决证书问题，这才是后面能抓到 HTTPS 明文的关键。
3. 用 Fiddler 在本地和手机上跑通完整抓包：HTTPS 解密与弱网模拟
3.1 打开 HTTPS 解密开关：搞不定证书，你就只能看到加密隧道
Fiddler 默认只捕获 HTTP 明文流量，HTTPS 请求在列表里会显示为一条Tunnel to 域名:443的记录，看不到里面的路径、参数和响应体。要做 HTTPS 解密，必须让 Fiddler 成为中间人：它生成一个根证书，用这个根证书动态签发目标域名的证书，浏览器或 App 信任了这个根证书，Fiddler 才能解开流量。
操作路径是：菜单Tools > Options > HTTPS，勾选Capture HTTPS CONNECTs和Decrypt HTTPS traffic。第一次勾选时 Fiddler 会弹窗询问是否信任它生成的根证书，一定要点是。如果不小心点了否，后续就要手动到Tools > Options > HTTPS > Actions > Trust Root Certificate重新信任。
信任根证书后，浏览器访问任意 HTTPS 站点，Fiddler 列表里就能看到完整的 URL、请求头、请求体、响应体。但这里有个必踩的坑：旧版本 Fiddler 生成的是 1024 位 RSA 根证书，新版 Windows 和 Chrome 对这种根证书直接不信任，导致浏览器报NET::ERR_CERT_INVALID。解决办法是尽量下载新版 Fiddler Classic，它生成的根证书已经是 2048 位；如果你手里的“Fiddler中文版本.zip”是三五年前的旧包，大概率栽在这。
3.2 用 FiddlerScript 定制弱网参数：延迟、丢包和带宽限制
Fiddler 自带一个Simulate Modem Speeds开关（菜单Rules > Performance > Simulate Modem Speeds），但它只模拟一个固定速率的慢速网络，没法精确控制延迟和丢包率。做弱网测试的专业做法是改 FiddlerScript 里OnBeforeRequest函数下的网络模拟逻辑。
FiddlerScript 是 Fiddler Classic 的脚本扩展机制，用 JScript 语法。点击菜单FiddlerScript打开脚本编辑器后，找到OnBeforeRequest方法，加入如下代码：
// 在 OnBeforeRequest 中注入网络延迟与带宽限制 static function OnBeforeRequest(oSession: Session) { // 对指定测试域名做弱网模拟，其它请求保持正常 if (oSession.HostnameIs("api.test.svc")) { // 插入 800ms 延迟，模拟高延迟链路 oSession["request-trickle-delay"] = "800"; // 限制下载带宽为 256kbps，观察大响应体场景下的表现 oSession["response-trickle-delay"] = "1024"; // 记录弱网标记，方便后续从状态栏确认规则生效 oSession["ui-backcolor"] = "#FFFFBB"; } }这段脚本的逻辑是：当请求目标主机名是api.test.svc时，给请求方向插入 800 毫秒延迟，给响应方向插入一个模拟慢速链路的延迟值。Fiddler 的 trickle-delay 机制是每延迟一定毫秒数才放行一部分数据，response-trickle-delay的数值单位是“每 KB 数据的延迟毫秒数”，设置1024就表示每传输 1KB 数据额外等 1024ms，实际带宽大约被压到 1KB/s 左右，非常苛刻。
参数说明：request-trickle-delay控制上行（请求体）速度，response-trickle-delay控制下行（响应体）速度。测试时一般先设一个宽松值，比如300，跑通后再逐步收紧到1024，观察接口在弱网下的超时表现。如果你只关心固定人工延迟而不限制带宽，可以不用 trickle-delay，改在脚本里调用Utilities.sleep(800)实现——但注意阻塞式 sleep 会卡住 Fiddler 处理线程，并发测试时不推荐。
脚本保存后立即生效，不需要重启 Fiddler。验证弱网规则是否生效，可以在响应耗时列看数值变化，正常从几十毫秒跳到几百毫秒以上。这里有一个翻车点：FiddlerScript 保存后如果语法错误，右下角会弹红条提示脚本未通过编译，但不会影响 Fiddler 继续运行——这时候弱网规则是失效的，别以为改完就万事大吉。
3.3 手机抓包全流程：同一局域网 + 代理指向 + 证书安装
手机抓包是 Fiddler 考验最集中的场景，前端定位 App 接口问题、测试验证线上环境都要用。整体链路是：手机和电脑连同一 Wi-Fi，手机 Wi-Fi 代理指向电脑 IP 的 8888 端口，然后手机浏览器访问http://电脑IP:8888下载并安装 Fiddler 根证书。
具体到操作步骤，我按顺序走一遍：
- 电脑上启动 Fiddler，菜单
Tools > Options > Connections，确认勾选Allow remote computers to connect，端口保持 8888。 - 在电脑命令行执行
ipconfig查 Wi-Fi 适配器的 IPv4 地址，记下来。 - 手机进入 Wi-Fi 设置，把代理模式改为手动，主机名填电脑的 IPv4 地址，端口填 8888。
- 手机浏览器访问
http://电脑IP:8888，页面最下方有一个FiddlerRoot certificate下载链接，点击下载。 - 在手机系统设置里安装这个证书。Android 和 iOS 的安装路径不一样，这一步最容易卡住。
Android 端如果你用的是 7.0 以上系统，并且抓的是 App 的 HTTPS 流量，会遇到一个额外问题：App 的targetSdkVersion大于等于 24 时，系统默认不信任用户安装的证书，Fiddler 的中间人证书装进去了也不生效。绕过办法包括：App 的networkSecurityConfig里显式信任用户证书（需要 App 改配置重新打包），或者把 Fiddler 证书装到系统证书目录（需要 root）。这也是手机抓包翻车率最高的地方，后面避坑章节会细说。
iOS 端安装证书后还有一个开关：设置 > 通用 > 关于本机 > 证书信任设置，必须把 Fiddler 证书对应的开关打开，否则 Safari 和 App 依然不信任。这一步漏掉的人很多，表现为证书下载成功、代理也配好了，但 HTTPS 请求全部失败或显示证书错误。
3.4 用 QuickExec 命令快速改请求：URL 重定向与断点拦截
抓包不只是看，很多时候要改。Fiddler 在左下角的 QuickExec 输入框（黑色底命令栏）可以直接输入命令控制会话，这是不用写脚本就能快速干预请求的路径。
高频命令如下：
?keyword：在列表中高亮 URL 里包含 keyword 的会话。select text/html：选中所有响应类型为 text/html 的会话。bpv或bpu：设置断点。bpu 关键字只对请求 URL 包含关键字的会话设置请求断点，bpv则对任意响应设置断点，再输一次同命令会取消断点。urlreplace 旧串 新串：请求 URL 里的旧串替换成新串。这个命令常用来做测试环境切换，比如把api.example.com改到api-test.example.com，不需要重启 Fiddler。
我一般会用urlreplace处理线上环境到测试环境的快速切换，这比改 hosts 更可控，因为只影响经由 Fiddler 代理的流量。命令运行后，新发出的请求会实时被替换，老会话不受影响。要注意的是，urlreplace 对请求 URL 生效，但不改 Host 头之外的 referer 或 cookie 域字段，某些接口鉴权绑定了域名时会报 403，这种时候就得升级到 AutoResponder 或者 FiddlerScript 做精细化改写。
4. Fiddler 的抓包避坑指南：代理失效、解密失败与端口冲突
我经手过的 Fiddler 相关排障，百分之八十集中在下面这几类问题上。每一条都按“现象 → 原因 → 解决”来拆，基本都是血泪经验换来的。
坑一：启动 Fiddler 后浏览器全军覆没，所有页面打不开
现象：Fiddler 开着，Chrome 任何网站都报ERR_PROXY_CONNECTION_FAILED或直接超时；关掉 Fiddler 就恢复正常。
原因：Fiddler 启动时会把 Windows 系统代理设置为127.0.0.1:8888，但 Fiddler 的监听端口实际没有起来——最常见的是端口被占用，Fiddler 启动失败后没有回滚系统代理设置。另一个常见原因是公司电脑装了安全软件，拦截了 Fiddler 对 WinINET 代理的写入。
解决：先重启 Fiddler 让代理设置重新写入；不行就改端口，菜单Tools > Options > Connections，把监听端口改成 8899，然后重新勾选Capture Traffic。改端口后浏览器不用动，Fiddler 会更新系统代理指向新端口。安全软件拦截的情况，加白名单或用管理员身份运行 Fiddler 基本能解决。
坑二：HTTPS 列表里全是 CONNECT，没有一条能看明文
现象：抓 HTTP 完全正常，HTTPS 记录只有Tunnel to www.example.com:443，看不到 URL 和响应内容。
原因：没打开 HTTPS 解密，或者打开后浏览器不信任 Fiddler 根证书。新版 Chrome 对自签名根证书要求更高，旧证书算法可能被直接拒绝。
解决：确认Tools > Options > HTTPS里两个复选框是勾选状态。不放心就点Actions > Reset All Certificates，重置后重新信任根证书并重启浏览器。重置证书会清掉之前所有已信任的 Fiddler 证书，如果多台设备之前都装了同一个根证书，它们全部需要重新安装，这点要先想清楚。
坑三：Android 真机抓包，HTTPS 请求全部失败或响应为空
现象：App 的网络请求在 Fiddler 里看得到，但状态列是 400 或显示证书错误；部分请求直接 0 字节返回。
原因：Android 7.0 以上默认不信任用户证书。如果 App 的targetSdkVersion >= 24，即便你把 Fiddler 证书装进了“用户证书”分区，App 也不认。这是系统安全策略，不是 Fiddler 的问题。
解决：第一选择是把 Fiddler 证书作为系统证书安装，需要 root 环境并挂载/system分区，Android 10 以上还有只读分区限制，操作复杂。第二选择是用 Fiddler 配合模拟器做抓包，模拟器系统版本可以选 Android 6.0 及以下，规避证书信任限制。第三选择是抓纯 HTTP 流量（如果有），或者让开发在 Debug 包中配置信任用户证书的networkSecurityConfig——这是最省事的路径，但需要开发配合。
坑四：模拟器抓包连不上，代理地址写什么都是白搭
现象：Android 模拟器里配了代理指向 Fiddler 所在电脑的 IP，但网络请求完全不经过 Fiddler，或者报拒绝连接。
原因：模拟器内的10.0.2.2是宿主机 loopback 的别名，用这个地址可以访问宿主机，但 Fiddler 的绑定地址默认只监听本机回环，不接收来自虚拟网卡的流量。
解决：Fiddler 菜单Tools > Options > Connections，勾选Allow remote computers to connect，勾选后它会绑定所有网卡接口。模拟器代理地址写10.0.2.2（Android 官方模拟器）或宿主机的局域网 IP，端口写 8888。注意勾选这个选项后，Fiddler 会监听 0.0.0.0:8888，局域网内其他设备也能连上来，用完建议关掉，避免同事的流量全部打进你的 Fiddler。
坑五：汉化包装了之后功能菜单缺失，FiddlerScript 编辑器打不开
现象：费劲装完中文汉化包，结果菜单栏少了一大块，Tools > Options点了没反应，或 FiddlerScript 编辑器直接白屏。
原因：汉化包版本与 Fiddler Classic 安装版本不匹配。Fiddler 官方更新频繁，菜单结构在版本之间会调整，旧汉化文件里写的资源 ID 对应不上新版程序，导致部分菜单找不到对应文本而崩溃或隐藏。
解决：这是汉化包最大的风险点。要么找到与你的 Fiddler 版本严格匹配的汉化包，要么放弃汉化，直接用英文界面。我的习惯是装新版官方 Fiddler Classic，配一个只覆盖Languages\zh-CN的轻量汉化包，万一出问题就删除语言文件目录，恢复英文界面，不影响抓包功能本身。
5. 从抓到改再到自动响应：Fiddler 进阶使用与验证方法
5.1 AutoResponder：用一个本地文件 mock 掉整个服务的响应
AutoResponder 是 Fiddler 里被低估的功能，它可以在不改后端代码的情况下，把指定的请求直接映射到本地文件、另一个 URL 或者一个自定义响应体。前端做页面联调、测试模拟异常返回、后端没就绪时提前开发，全靠这个功能扛。
操作路径是：选中一条已捕获的请求，右键Save > Response > Response Body存为本地文件，然后打开右侧AutoResponder标签，勾选Enable Rules和Unmatched requests passthrough，把保存的文件拖进规则列表。Fiddler 会自动生成一个EXACT:或正则匹配的规则，把匹配到的请求响应替换成你保存的内容。
我常用的几种规则写法：
- 精确匹配：
EXACT:http://api.example.com/v1/user/info命中规则，只影响这个完整 URL。 - 前缀匹配：
http://api.example.com/v1/user/命中所有带此前缀的请求。 - 正则匹配：
regex:.*\.example\.com/api/.*命中所有子域名下的 API 请求。 - 本地文件替换：
http://api.example.com/v1/user/info -> C:\mock\user_info.json。
实际落地过程中，AutoResponder 最常见的坑是路径匹配规则写太宽，把首页 HTML 和静态资源全部命中到 mock 文件，页面直接花掉。我的做法是先用EXACT:做精确匹配兜底，确认链路通了再放宽到前缀或正则，避免一上来就是.*通杀。
5.2 Composer：手工构造请求与重放攻击测试
Composer 标签页是 Fiddler 的请求构造器，拖一条历史会话进去会自动填充方法、URL、头、请求体，改完点Execute就重新发一次。这个能力在做接口重放测试、修改鉴权头、模拟重复提交时非常有用。
举一个真实场景：测试环境有个下单接口，后端做幂等校验，用requestId判断是否重复提交。用 Fiddler 抓一次正常下单请求，把 Composer 里的请求体复制三份，分别修改requestId为不同值再连续执行，就能验证后端幂等逻辑是否真的按requestId去重。如果不改requestId直接重放，应该被拒掉；如果后端没做校验，就会出现重复订单——这正好暴露问题。
Composer 执行后会生成一个新会话进入列表，方便你直接用?keyword高亮出来看响应耗时和状态码。它的限制是没有内置的压测能力，想连续打 100 次就得上脚本或外部压测工具，但做几组手工重放足够覆盖大多数接口联调场景。
5.3 验证抓包配置是否生效的三个快速检查法
配置完 Fiddler 或者改了弱网规则后，怎么确认“真的生效了”而不是“看起来生效了”？我的习惯是三个检查：
第一，看会话列表状态列。正常解密后的 HTTPS 会话，Result列会显示实际的 HTTP 状态码（200、302、404 等），如果看到Tunnel to或只有 CONNECT，说明解密没生效。
第二，看响应耗时。修改了response-trickle-delay后，选中一个命中规则的会话，右侧Statistics标签页里能看到Request took时间，这个值应该明显大于未命中规则的同类请求。
第三，用 QuickExec 输入show命令预览脚本配置。FiddlerScript 里加过的规则，在脚本编辑器里应该能搜到对应代码；搜不到就说明脚本没保存成功，或者保存的是旧版本。
这三个检查各针对一个维度：第一项验证解密，第二项验证弱网规则，第三项验证脚本代码落地。三者配合，基本能把配置层的错误和运行层的错误区分开。
5.4 用 Fiddler 做代理跨域调试的上游代理转发
最后提一个容易被忽视的场景：当你的开发环境处于企业内网，浏览器直连外网 API 需要走公司统一代理时，Fiddler 需要配置上游代理才能抓到外网请求。路径是Tools > Options > Gateway，这里有几种模式：Direct表示不走任何上游代理，Manual Proxy填写内网代理地址，Use IE Proxy跟随系统 IE 代理设置。
我踩过的坑是：Fiddler 开了解密，同时用Manual Proxy指向内网网关，但网关本身又不信任 Fiddler 的中间人证书，结果抓到的是网关重新加密的流量——列表里全是 502。解决方法是把网关地址加入 Fiddler 的No Proxy For列表（在 Gateway 配置的底部，按分号分隔域名后缀），让内网域名绕过上游代理直接访问，同时只对外网域名走代理。这样抓外网接口用系统代理链路，抓内网接口用直连链路，各不干扰。
还有一个跨域的典型用法：本地前端跑在localhost:8080，后端接口在dev-api.internal.net，浏览器跨域报错时，用 AutoResponder 把前端的/api/路径重写映射到后端实际地址，配合 CORS 响应头的本地 mock，能绕开跨域限制做纯前端联调。这种方案的前提是请求已经经过 Fiddler 代理，所以浏览器代理设置一定不能用--no-proxy-server强行绕开。
回到我自己的习惯：新版 Fiddler Classic 出来之后，我不会急着汉化追新，而是保留一个原版英文程序目录用于排错，汉化目录用于日常操作；遇到界面怪异或功能缺失，先删除语言资源切回英文确认是汉化问题还是功能问题。抓包工具的核心价值是把网络交互过程透明化，界面语言只是舒适度问题——中文界面舒服，但解不开 HTTPS 一样白搭。希望这篇落地笔记能帮你在“Fiddler中文版本.zip”这个看似讨巧的入口上少走几步弯路，把力气花在真正有用的抓包和调试能力上。
本文还有配套的精品资源，点击获取
