企业官网建设流程全解析

简介：Fiddler中文版本.zip是面向中国用户的本地化网络调试工具，适合Web开发与测试人员捕获、分析HTTP(S)流量，快速定位接口联调与网页加载中的异常问题。压缩包体积仅6.02MB，内置完整中文界面，无需额外配置或语言包即可直接运行，各功能菜单一目了然，大大降低英文工具的使用门槛。目前已有1988人学习下载，验证了其在调试场景中的实用价值。借助Fiddler核心能力，使用者可以实时查看请求头与响应体，设置断点修改请求和响应，解密HTTPS加密流量，并通过请求时间线分析性能瓶颈；同时支持脚本扩展与会话过滤，便于自动化验证和定向排查。无论是新手还是资深工程师，都能依托该中文版本完成从抓包、分析到干预请求的完整调试流程，提升日常工作效率。

1. Fiddler中文版本.zip：拿到手的第一步，是搞清你装的是哪一版

如果你下载过 Fiddler，大概率见过这类压缩包：文件名写着“Fiddler中文版本.zip”，解压出来要么是一个汉化补丁，要么是打包好的绿色版。Fiddler 本身是免费软件，但它默认只有英文界面，很多人卡在第一步不是因为不会抓包，而是看不懂菜单。这个 zip 解决的正是这个问题：把调试工具的界面门槛降下来，让你把精力放在分析请求和定位问题上。

不过我得先泼一盆冷水：中文版和原版在功能上没有区别，核心还是那个监听在 8888 端口的调试代理。真正决定你能不能抓到 HTTPS、能不能改包、能不能做弱网测试的，不是汉化包，而是证书、代理设置和过滤规则。这篇就顺着这个 zip 往下走，先讲清楚 Fiddler 的原理，再教你把抓包、改包、弱网这几件事跑通，最后给出几个我踩过的坑。

2. Fiddler 的工作原理与中文版的来历：先搞清楚你手里是什么

2.1 抓包工具的核心机制：代理服务器与 HTTPS 解密

Fiddler 本质上是一个本机代理服务器。它在你和目标服务器之间插入一层，所有经过它的 HTTP/HTTPS 请求都会先到 Fiddler，再由 Fiddler 转发出去。你在浏览器里访问一个页面，浏览器配置了代理 127.0.0.1:8888，请求就先到 Fiddler，Fiddler 记录下完整的请求头和响应体，然后再转发给真正的服务器。

这个过程叫“中间人代理”。对于 HTTP 流量，Fiddler 直接明文读取，不需要额外操作。但 HTTPS 流量是加密的，Fiddler 想看到里面的内容，就必须做一件事：生成一张自己的根证书，然后让客户端（浏览器、App、模拟器）信任这张证书。当客户端发起 HTTPS 请求时，Fiddler 用自己的证书冒充目标服务器，跟客户端完成 TLS 握手，同时再以客户端的身份去连接真正的服务器。

这就是为什么网上几乎每篇 Fiddler 教程都要你“安装证书”。不装证书的话，你只能看到一堆 CONNECT 请求，看不到具体的 URL、参数和响应内容。装完证书，Fiddler 就能解密 HTTPS 流量，你才能看到 POST 表单里的数据、接口返回的 JSON、Cookie 的完整内容。

这里要有一个意识：Fiddler 不是防火墙，不是网络监视器，它只处理“显式配置了代理”的流量。很多新手抓不到包，就是因为浏览器或 App 根本没走代理。后面章节我会专门讲这个坑。

2.2 中文版的三种常见形态：绿色版、汉化补丁与官方多语言

你拿到的“Fiddler中文版本.zip”，大概率是下面三种情况之一。

第一种是绿色免安装版。压缩包里直接是一个完整可运行的 Fiddler 目录，解压后运行 exe 即可，注册表和系统服务一概不碰。这种包通常已经把汉化文件放进去了，打开就是中文界面，省事。缺点是没有开始菜单快捷方式，也没有卸载入口，想删干净得自己手动清理。

第二种是汉化补丁包。压缩包里是几个语言文件，通常放在 Fiddler 安装目录下的 Languages 文件夹里。Fiddler 本身支持多语言扩展，你只需要把对应的 xml 或 lng 文件丢进去，然后在菜单里选择语言。这种包适合你已经有原版 Fiddler 的情况，相当于给软件“换个皮肤”。

第三种是安装包加汉化脚本。先运行原版安装程序，再执行一个批处理脚本，脚本自动把汉化文件复制到指定目录。这种包的问题在于，如果杀毒软件把脚本拦截了，汉化就不完整，界面会出现一半中文一半英文的“阴阳界面”。

不管哪种形态，你要记住一条判断标准：看 Fiddler 的版本号和证书有效期。Fiddler Classic 的版本号至今还在更新，老版本抓新系统的流量会出问题。我见过有个读者拿了一个 2015 年的绿色版，抓 Windows 11 上的 Edge 流量，证书装完依然报错，最后换新版才解决。汉化只是界面翻译，代理内核的兼容性不会因为汉化而变好。

2.3 为什么 Fiddler Classic 是主流选择而非 Fiddler Everywhere

很多人在搜索时看到两个名字：Fiddler Classic 和 Fiddler Everywhere。前者是免费的老牌桌面版，也就是本文讨论的这个；后者是 Telerik 后来推出的跨平台商业版，界面更现代，支持团队协作，但免费版有会话数量限制，且部分高级功能要订阅。

我的建议很直接：个人调试、学习抓包、给开源项目做接口分析，用 Fiddler Classic 就够了。Classic 免费、轻量、插件生态成熟，网上几乎所有教程都是基于它写的。Everywhere 的优势在跨平台（macOS/Linux）和云端收藏，但如果你是 Windows 用户，用 Classic 没有明显短板。

还有一点：Fiddler Classic 的汉化资源更丰富。毕竟它问世时间长，中文社区沉淀了大量汉化补丁和使用文档。你下载的 zip 如果自带的是 Classic 的汉化包，那基本可以放心用；如果压缩包描述里写的是 Everywhere，就得先确认版本匹配，两个产品的语言文件格式不一样，混用会直接报错。

3. 从 zip 到第一次抓包成功：安装、证书与最小验证

3.1 解压与运行：验证你的包能不能跑起来

拿到压缩包后，先别急着双击 exe。我习惯先把包解压到一个固定目录，比如D:\Tools\Fiddler，然后看一眼目录结构。一个规范的绿色版，目录下应该有Fiddler.exe、Fiddler.exe.config、CertMaker.dll和Languages文件夹。如果你发现里面只有一个汉化补丁，那就得先去官网下原版安装包，再把补丁文件复制进去。

解压完成后，用管理员权限运行 exe。第一次启动时，Fiddler 会检查端口 8888 是否被占用。如果被占用，你可以去菜单里改端口，方法后面讲。启动成功的标志是主界面出现，左侧会话列表为空，右下角状态栏显示 “Listening on port 8888”。

# 检查 8888 端口是否被占用，以及是哪个进程占用的 netstat -ano | findstr "8888" # 输出示例 # TCP 0.0.0.0:8888 0.0.0.0:0 LISTENING 12345 # 查看占用端口的进程名称 tasklist | findstr "12345"

这段命令是在 Windows PowerShell 或 CMD 里执行的。第一行用netstat列出所有监听中的端口，findstr "8888"只过滤出和 8888 相关的行。如果没有任何输出，说明端口空闲，Fiddler 可以正常监听。如果有输出，最后一列的数字是进程 PID，再用tasklist查这个 PID 对应的进程名。常见情况是 IIS、SQL Server 或另一个代理工具占用了 8888，你可以关掉那个进程，也可以在 Fiddler 里换一个端口，比如 8889。

3.2 浏览器代理配置与首次抓包验证

Fiddler 启动后默认会修改 Windows 系统代理设置，把 HTTP 代理指向 127.0.0.1:8888。这个行为可以在菜单里关闭，但第一次使用我建议保持默认。然后在浏览器里随便访问一个网站，回到 Fiddler 左侧的会话列表，你应该能看到一行行记录。

验证抓包是否生效的最快方法，是看 Fiddler 里的会话数量和浏览器地址栏的访问是否同步变化。如果打开百度首页，Fiddler 里应该出现几十个请求，包括 HTML、JS、CSS、图片等。如果页面加载了但 Fiddler 里空空如也，说明代理没生效，最常见的原因是浏览器使用了独立的代理设置，覆盖了系统代理。

// 在浏览器控制台执行，快速确认当前生效的代理 // 注意：这个 API 只能在 Chromium 内核浏览器里用 // Edge 和 Chrome 都支持 if (navigator.userAgent.indexOf("Chrome") !== -1) { console.log("当前浏览器是 Chromium 内核，走系统代理"); }

这段代码不是必需的，只是一个快速判断浏览器类型的思路。实际排查代理是否生效，我更推荐打开浏览器的代理设置页看一圈，或者直接看 Fiddler 的状态栏有没有显示捕获状态。有时候你开着 Fiddler 但忘了点左下角的 “Capturing” 按钮，也会导致抓不到包。这个按钮是开关式的，灰色表示暂停捕获，红色表示正在捕获。

3.3 HTTPS 证书配置：不装证书就只能看到加密乱码

访问纯 HTTP 网站能抓到请求，但访问 HTTPS 网站时，你会发现左侧会话列表里出现一堆 CONNECT 开头的记录，点开看不到 URL 路径，也看不到 POST 数据。这就是前面说的：Fiddler 还没能解密 HTTPS。

点击菜单栏的 Tools -> Options -> HTTPS，勾选 “Capture HTTPS CONNECTs” 和 “Decrypt HTTPS traffic”，然后点右边的 “Actions” 按钮，选择 “Trust Root Certificate”。这时候会弹出一个证书安装向导，一路下一步，把证书安装到“受信任的根证书颁发机构”。重启 Fiddler，再访问 HTTPS 网站就能看到完整内容。

# 用 certutil 验证根证书是否安装到位 # 证书主题里应该包含 DO_NOT_TRUST_Fiddler certutil -store Root | findstr /i "Fiddler"

certutil是 Windows 自带的证书管理命令行工具。这条命令把系统“受信任的根证书颁发机构”存储区里的证书全部列出来，然后过滤出包含 “Fiddler” 字样的条目。如果输出为空，说明证书没装进去；如果有输出，会显示证书的序列号和主题名称。这个命令最大的价值是帮你判断“到底装没装”，因为有时候安装向导显示成功，但实际上装到了“个人”存储区而不是“根证书颁发机构”，那 HTTPS 依然解密不了。

这里要提醒一句：证书是 Fiddler 抓 HTTPS 的钥匙，也是隐私风险点。用完抓包工具，如果是在公用电脑上，记得在同一个界面里点 “Remove Root Certificate” 把证书删掉，否则任何经过这台电脑的 HTTPS 流量都可能被这个根证书对应的私钥解密。

4. Fiddler 抓包的四类核心操作：过滤、改包、弱网与手机抓包

4.1 会话过滤：让列表里只剩你关心的请求

Fiddler 默认会抓取所有代理流量，包括浏览器扩展的请求、系统更新的连接、杀毒软件的通信。这些噪音会让会话列表变得混乱，找接口的效率极低。我一般在开始调试前，先设置过滤器。

在 Fiddler 左侧会话列表的上方，有一个 “Filters” 标签，勾选 “Use Filters”，然后配置过滤条件。最常用的两个选项：一个是 “Host” 过滤，只显示特定域名的请求；另一个是 “Process” 过滤，只显示指定进程（比如 Chrome.exe）发起的请求。

# 一个典型的过滤配置，只保留 api.example.com 的请求 # 菜单：Filters -> Hosts -> Show only the following hosts # 输入框里写： api.example.com *.example.com

这个配置的含义是，只有主机名是api.example.com或者任何子域名匹配*.example.com的请求会显示在列表里，其他请求自动隐藏。注意*.example.com不包含裸域example.com，如果你也需要那个裸域，得单独加一行。过滤配置生效后，你可以搭配下方的 “Highlight” 选项，把匹配的请求高亮成黄色，一眼就能扫到目标请求。

还有一个高频场景是按响应类型过滤。调试图片加载问题时，只看Status是 404 的记录；调试 POST 接口时，在过滤器的 “Request Headers” 里加一行Content-Type: application/json。这些过滤规则写多了以后，你会发现找接口的时间比改代码的时间还长的情况会明显减少。

4.2 断点修改 URL 与响应：线上问题的本地复现

抓包不只是“看”，更常用来“改”。最常见的两个改包场景：把 URL 里的某个参数替换掉，验证后端对异常参数的处理；把响应体里的某个字段改掉，模拟前端在不同数据下的表现。

Fiddler 里实现改包的方式是断点（Breakpoint）。在菜单栏选择 Rules -> Automatic Breakpoints -> Before Requests，Fiddler 会在每个请求发送之前暂停，让你修改请求头、URL 或请求体；选择 After Responses，则在响应返回之后暂停，让你修改响应数据。手动断点的快捷键是 Shift + F11 设置请求前断点，Alt + F11 设置响应后断点。

// 通过 FiddlerScript 在请求发出前自动改写 URL 参数 // 打开 FiddlerScript 编辑器：菜单 Rules -> Customize Rules // 在 OnBeforeRequest 函数里加这段逻辑 if (oSession.HostnameIs("api.example.com") && oSession.url.indexOf("page=1") !== -1) { // 把 page=1 改成 page=2，模拟翻页请求 oSession.url = oSession.url.Replace("page=1", "page=2"); // 写一行日志到 Fiddler 的 Log tab FiddlerObject.Log("URL rewritten by custom rule"); }

上面这段是 FiddlerScript 的典型写法，它运行在 Fiddler 内部，用 JScript 语法。oSession代表当前正在处理的会话对象，HostnameIs判断请求的域名，url属性可以直接修改请求地址。这个方案比手动断点高效的地方在于：它是自动化规则，每个匹配的请求都会执行，不需要你一次次点放行。

改响应也类似。你可以在OnBeforeResponse函数里判断状态码或者 Content-Type，然后把oSession.ResponseBody里的字符串替换成目标内容。但注意，修改响应体之后要记得把oSession.utilSetResponseBody("...")一下，否则 Fiddler 不会重新计算 Content-Length，浏览器端会报错。

4.3 弱网测试：用 Fiddler 模拟高延迟与低带宽

弱网测试是移动端开发的高频需求，Fiddler 的 “Simulate Modem Speed” 预设是最被人熟知的弱网方案，但我得说：这个预设太粗糙了，只适合粗略演示，不适合严谨的弱网验证。

更可控的方式是自定义延迟。打开 Rules -> Customize Rules，在OnBeforeRequest里加入延迟逻辑，让请求在发出前暂停指定的毫秒数。这样可以模拟不同网络条件下的请求耗时，而不影响带宽。

// 模拟延迟：每 10 个请求中随机取 3 个延迟 2000ms // 放在 OnBeforeRequest 函数末尾 if (Math.random() < 0.3) { // System.Threading.Thread.Sleep 的单位是毫秒 System.Threading.Thread.Sleep(2000); FiddlerObject.Log("Simulated network delay of 2000ms"); }

Math.random()生成 0 到 1 之间的随机数，小于 0.3 表示约 30% 的请求被注入延迟。Thread.Sleep(2000)让当前线程暂停两秒，模拟弱网下的高延迟。这个方案不适合线上环境，只适合本地开发联调时用，因为它会阻塞 Fiddler 的处理线程，流量大的时候会让整个界面卡住。

精准的弱网模拟，我一般配合 Charles 使用，或者直接用 Fiddler 的脚本控制更多维度的参数。但如果你只在 Fiddler 里做，还有个技巧：修改OnBeforeRequest里的oSession["request-trickle-delay"]属性，值为 300 表示每 300ms 才发送一个数据块。这个属性的效果是限制上行速度，跟上面的 Sleep 是两种不同的模拟手段，一个管延迟，一个管带宽。

4.4 手机与模拟器抓包：代理指向同一台电脑

手机抓包是 Fiddler 的另一大用途。原理很简单：手机的流量不经过 Fiddler，除非你把手机的网络代理指向电脑的 IP 和 Fiddler 的端口。前提是手机和电脑必须在同一个局域网内。

在 Fiddler 的 Options -> Connections 里勾选 “Allow remote computers to connect”，然后记下电脑的局域网 IP。手机端打开 Wi-Fi 设置，把代理模式改成手动，主机名填电脑 IP，端口填 8888。然后手机浏览器访问http://电脑IP:8888，会看到一个 Fiddler 证书下载页面，点下载并安装证书，之后手机上的 HTTPS 请求就能被解密了。

# 查看电脑的局域网 IP，确保手机和电脑在同一网段 ipconfig | findstr /i "IPv4"

ipconfig是 Windows 查看网络配置的命令行工具，findstr /i "IPv4"过滤出 IPv4 地址那几行。你可能会看到多个网卡地址，比如有线、无线、虚拟机网卡，要选手机能 ping 通的那个。虚拟机网卡（VMware 或 Hyper-V 的虚拟网卡）在手机端是无法访问的，别把那个 IP 填到手机里。配置完成后，用手机访问几个页面，回到 Fiddler 看左侧会话列表，如果出现了手机发起的请求，说明链路通了。

这里有一个我反复踩的坑：手机关闭 Wi-Fi 或者在 App 内使用蜂窝数据时，代理不会生效。App 的某些页面如果走 UDP 协议（比如视频通话），Fiddler 抓不到，这是协议限制，不是配置问题。模拟器抓包也基于同样的原理，Android 模拟器里把代理指向宿主机的 IP 即可，但要注意模拟器自带的网络模式，如果用的是 NAT 模式，代理指向10.0.2.2而不是电脑的局域网 IP。

5. Fiddler 中文版避坑指南：证书失败、抓不到请求与参数失效

5.1 证书装完依然抓不到 HTTPS：检查证书存储位置与 Fiddler 进程权限

现象：按照教程安装了根证书，也勾选了 Decrypt HTTPS traffic，但重启 Fiddler 后访问 HTTPS 网站，会话列表里依然是 CONNECT 记录，双击只看到加密内容。

原因：最常见的是证书没有安装到“受信任的根证书颁发机构”存储区。Windows 的证书安装向导默认会选“当前用户”和“个人”存储区，而 Chrome 和 Edge 只信任系统根证书存储区的证书。另一个常见原因是 Fiddler 没有以管理员权限运行，导致它无法读取机器级证书存储。

解决：先按 3.3 节的certutil命令确认证书存储位置，如果发现证书在个人存储区，打开 Fiddler 的 HTTPS 选项，先点 “Remove Root Certificate”，再重新勾选安装，这次安装时手动选择“受信任的根证书颁发机构”。同时右键 Fiddler.exe，选择“以管理员身份运行”。改完这两步，重启浏览器再试一次。如果还不行，看 Fiddler 的 Log tab 里有没有证书生成失败的错误日志，通常是CertMaker.dll损坏，重新覆盖安装一次即可。

5.2 手机或模拟器连不上代理：网络隔离、端口被防火墙拦截

现象：手机配置了代理，但打开页面直接报网络错误，Fiddler 端没有任何新记录。

原因：排查分三步，但很多人卡在第一步就放弃了。第一，手机和电脑不在同一网段，这种情况在办公室 Wi-Fi 里特别常见，公司网络开启了 AP 隔离，手机能上网但无法访问电脑的 IP。第二，Windows 防火墙拦截了 8888 端口的入站连接，Fiddler 默认只监听本地回环地址，不开放对外端口。第三，Fiddler 的 “Allow remote computers to connect” 没有勾选。

解决：先 ping 一下电脑 IP，手机端下个 ping 工具或者在浏览器里访问http://电脑IP:8888，能打开 Fiddler 的证书下载页说明网络通了。如果浏览器打不开，检查防火墙：控制面板 -> Windows 防火墙 -> 允许应用通过防火墙，把 Fiddler.exe 勾上专用和公用网络。如果还是不通，直接在 Fiddler 的 Options -> Connections 里把端口改成 8899，再在防火墙里放行这个新端口。注意，改完端口后手机端的代理端口也要同步修改，忘记改端口是最常见的“明明配置了却连不上”的原因。

5.3 弱网模拟参数不生效：模拟调制解调器预设与实际场景不匹配

现象：在 Rules 菜单里勾选了 Performance -> Simulate Modem Speed，刷新页面后发现请求并没有变慢，或者变慢的幅度不符合预期。

原因：这个预设本质上是设置两个延迟属性：request-trickle-delay和response-trickle-delay。它在很多场景下确实有效，但如果你之前手动在 FiddlerScript 里写过自定义延迟，自定义规则的优先级会覆盖预设值。另一个情况是，请求走了缓存，浏览器根本没有发起真实请求，Fiddler 自然没有流量可以延迟。

解决：确认 FiddlerScript 里没有写死oSession["request-trickle-delay"]；在浏览器开发者工具的 Network 面板里勾选 Disable cache，强制请求走网络。如果要模拟更真实的弱网（比如 3G 网络），不要只用预设，建议自己写脚本：上行延迟 300ms、下行延迟 150ms，再配合限速属性。预设值 56kbps 模拟的是非常老旧的拨号网络，对现代 App 来说过于极端，很多请求会直接超时，这也是一种“参数不生效”的表现，其实是生效了但效果太强。

5.4 汉化不完整与界面卡顿：补丁版本过老或装了多个版本

现象：Fiddler 界面上半部分是中文，下半部分菜单还是英文，部分按钮甚至扭曲变形；或者打开抓包页面时界面卡顿，点一个菜单要等好几秒。

原因：汉化不完整占九成是语言文件版本和 Fiddler 版本不匹配。Fiddler 升级后，菜单项增加了或改名了，语言文件里对应的字符串缺失，软件会回退到英文显示。界面卡顿更多是因为汉化文件体积过大或者格式不规范，Fiddler 每次渲染界面都要解析一遍语言文件，导致性能下降。

解决：先确认当前 Fiddler 的具体版本号：菜单 Help -> About。然后找到与这个版本配对的汉化包，重新覆盖Languages目录下的文件。如果找不到匹配的汉化包，退而求其次，把语言切换回英文，用英文界面做调试，主要功能不受影响。卡顿问题清理一下Languages目录，把多余的语言文件删掉只留一份，重启 Fiddler 一般能解决。我自己的习惯是：重要的调试场景用英文原版，避免语言文件引发的一切玄学问题。

6. 把抓包流程固化成规则：用 FiddlerScript 打造个人调试工具箱

当你已经熟练使用过滤器和断点之后，下一步就是把自己的调试习惯固化成脚本规则，不必每次手动设置。

我最常用的一套规则是：自动剥离静态资源请求，只保留接口请求；给所有经过的响应注入一个自定义响应头，方便前端确认请求真的经过了 Fiddler；把线上环境的请求自动切到本地调试地址。前两个用过滤器和会话列表就能手动完成，但第三个是纯手工难以稳定复现的，脚本才是正解。

// 自动把线上域名映射到本地开发环境 // 在 OnBeforeRequest 里添加以下逻辑 if (oSession.HostnameIs("api.example.com") && oSession.uriContains("api/v1/")) { // 改写请求地址到本地的 mock 服务 oSession.url = oSession.url.Replace("https://api.example.com", "http://127.0.0.1:3000"); // 记录一条日志，方便在 Log tab 里回溯 FiddlerObject.Log("Mapped to local: " + oSession.url); }

这段脚本最关键的一行是.Replace()。它把 HTTPS 请求中的域名替换成本地服务的地址，请求体、请求头、Cookie 全部保持不变。这个能力的价值在于：你可以用线上的真实请求数据去调试本地代码，而不用手动构造一套假数据。uriContains("api/v1/")是路径匹配，避免把静态资源页误转走。

用脚本调试时，我养成了一个习惯：每次加新规则只加一段，然后立刻用一条线上真实请求去验证，再把验证结果记录在 Log tab 里。这样一旦出了问题，能快速定位是哪段规则造成的，不用把整段脚本翻来覆去排查。这个习惯帮我避过不少坑，也让我越来越觉得 Fiddler 真正的分水岭，不在抓包，而在能不能把自己的调试流程沉淀成一套可复用的规则。希望这篇能帮你少走点弯路，把 Fiddler 真正用成顺手的工具。

本文还有配套的精品资源，点击获取