企业官网建设流程全解析

简介：Fiddler是一款由Telerik开发的HTTP协议抓包与调试代理工具，面向开发者、测试人员及需要排查网络问题的用户，可帮助分析请求响应、定位接口异常与页面加载瓶颈。本资源为Fiddler下载包，采用7z压缩格式，共包含90个文件，整体约3.11MB，其中以dll动态库、exe可执行程序、pdb调试符号、dat响应模板及config配置文件为主，另含少量wav音频、ico图标与脚本文件，覆盖主程序、证书工具、语法编辑器及导入导出组件等模块。目前已有2248人学习下载，适合希望快速获取完整工具集并上手抓包调试的读者。通过该资源可了解Fiddler的目录结构与组件构成，为后续配置HTTPS解密、断点调试、AutoResponder规则及会话管理打下基础，是网络调试入门与进阶的实用工具包。

1. 抓包这件事，从 Fiddler 下载说起

很多人第一次接触 HTTP 调试，都是从 Fiddler 开始的。它不像 Wireshark 那样一上来就给你满屏十六进制，也不像浏览器开发者工具那样只能看自己发出去的请求。Fiddler 站在客户端和服务器中间，把经过它的每一个 HTTP/HTTPS 请求都摊开给你看——请求头、响应头、Cookie、Body、耗时，全都能改、能断点、能重放。这次要聊的这份 Fiddler 下载资源，就是这套工具的完整安装包，适合做接口联调、移动端抓包、线上问题排查的开发者。如果你正在找一个能看懂请求、能改参数、能复现问题的抓包工具，这份资源可以直接落地用起来。

2. Fiddler 凭什么能当中间人：代理机制与证书信任链

Fiddler 的本质是一个本地 HTTP 代理服务器。启动后它会在本机监听一个端口（默认 8888），然后把系统或应用的流量引导到这个端口上。请求进来，它先记一笔，再转发给真正的服务器；响应回来，它再记一笔，然后交还给客户端。整个过程对上层应用透明，所以你能看到的东西比浏览器 F12 多得多——尤其是那些不走浏览器、直接由 App 或后台进程发出的请求。

2.1 代理转发与 HTTPS 解密的基本原理

HTTP 请求是明文的，Fiddler 直接读就行。但 HTTPS 不一样，客户端和服务器之间有一条 TLS 加密通道，Fiddler 如果只是单纯转发，看到的全是乱码。它的做法是：对客户端伪装成服务器，对服务器伪装成客户端，也就是中间人（MITM）。具体来说，Fiddler 会动态生成一张证书，用这张证书和客户端完成 TLS 握手，再用真正的服务器证书和服务器握手。这样两边都以为自己在和对方说话，实际上数据都从 Fiddler 过了一遍。

要让这套机制跑通，客户端必须信任 Fiddler 生成的根证书。否则浏览器或 App 会直接报证书错误，连接根本建立不起来。所以安装完 Fiddler 之后，第一件事就是导出并安装它的根证书。

2.2 安装后必须做的三件事：端口、证书、系统代理

下载安装包之后，默认下一步下一步就能装完。但装完不等于能用，下面这三步不做，抓包大概率是空的或者全是 CONNECT 隧道。

第一步，确认监听端口。打开 Fiddler，菜单栏 Tools → Options → Connections，看 Fiddler listens on port 是不是 8888。如果这个端口被其他程序占了，改成 8889 或别的都行，但后面所有配置都要跟着改。

第二步，导出并安装根证书。Tools → Options → HTTPS → Actions → Export Root Certificate to Desktop，桌面上会多出一个 FiddlerRoot.cer 文件。双击安装，选择“本地计算机”或“当前用户”都行，关键是把它放进“受信任的根证书颁发机构”。这一步不做，HTTPS 请求会直接失败。

第三步，开启系统代理。Fiddler 默认会自动把系统代理指向自己，但有时候会被其他代理工具改回去。可以在 Tools → Options → Connections 里确认 “Act as system proxy on startup” 是勾上的。如果没勾，手动在系统网络设置里把代理指向 127.0.0.1:8888。

# 检查 8888 端口是否被占用（Windows） netstat -ano | findstr :8888 # macOS / Linux 下检查 lsof -i :8888

这两条命令用来确认端口状态。如果输出里有 LISTENING 且 PID 不是 Fiddler，说明端口被占了，需要改端口或者结束占用进程。改端口之后，系统代理、移动端代理、代码里的 proxy 配置都要同步改，否则流量根本进不来。

提示：安装证书时如果系统弹出“要安装此证书吗”，一定要选“是”，并且确认证书被放进了“受信任的根证书颁发机构”。放错位置等于没装。

3. 把 Fiddler 用起来：从 PC 到移动端的完整抓包链路

装好只是开始，真正要抓的是业务流量。PC 端的浏览器请求相对简单，移动端才是大多数人用 Fiddler 的主战场。下面按场景拆开说。

3.1 PC 端抓包：过滤器与断点调试

PC 端抓包最直接，Fiddler 启动后系统代理自动生效，浏览器里刷一下页面就能看到请求列表。但列表一长就不好找，这时候要用 Filters。右侧 Filters 面板勾上 “Use Filters”，在 Hosts 里填目标域名，比如api.example.com，这样列表里只留相关请求。

断点调试是 Fiddler 的杀手锏。在 Rules → Automatic Breakpoints 里可以设置 Before Requests 或 After Responses。设置之后，请求发出前会暂停，你可以改 URL、改 Header、改 Body，然后点 Run to Completion 放行。这个能力在测试接口边界条件时特别有用——比如把某个参数从 1 改成 0，看服务端怎么处理。

// Fiddler 的 CustomRules.js 里可以写脚本自动改请求 // 位置：Rules → Customize Rules // 下面这段把请求头里的 User-Agent 统一改掉 static function OnBeforeRequest(oSession: Session) { if (oSession.oRequest["User-Agent"].indexOf("MyApp") > -1) { oSession.oRequest["User-Agent"] = "Mozilla/5.0 (Custom)"; } }

这段脚本挂在 OnBeforeRequest 事件上，每次请求发出前都会执行。oSession.oRequest["User-Agent"]读取原始 UA，判断是否包含 “MyApp”，如果是就替换成自定义值。CustomRules.js 用的是 JScript 语法，改完保存立即生效，不需要重启 Fiddler。参数说明：oSession是当前会话对象，oRequest是请求对象，oResponse是响应对象，改哪个就在对应事件里操作。

3.2 移动端抓包：代理设置与证书安装

移动端抓包分两步：让手机流量走 Fiddler，让手机信任 Fiddler 证书。

先保证手机和电脑在同一个局域网。电脑上查一下内网 IP，Windows 用ipconfig，macOS 用ifconfig | grep "inet "。然后在手机 Wi-Fi 设置里，把代理改成手动，主机名填电脑 IP，端口填 8888。改完手机上的请求就会经过 Fiddler。

接下来装证书。手机浏览器访问http://电脑IP:8888，Fiddler 会返回一个页面，点里面的 “FiddlerRoot certificate” 下载。下载完在系统设置里安装。Android 从 7.0 开始，用户证书默认不被 App 信任，需要在 App 的 network security config 里显式信任用户证书，或者把证书装到系统分区（需要 root）。iOS 装完证书还要去“关于本机 → 证书信任设置”里手动开启完全信任。

# 查看本机内网 IP（macOS） ifconfig | grep "inet " | grep -v 127.0.0.1 # Windows 下查看 ipconfig | findstr IPv4

这两条命令用来拿到电脑在局域网里的地址。手机代理里填的就是这个地址。如果手机连不上，先 ping 一下电脑 IP，确认网络互通。另外注意防火墙，Windows 防火墙可能会拦 8888 端口的入站连接，需要在防火墙里放行。

注意：Android 7.0 以上版本对用户证书的限制越来越严，很多 App 直接不信任用户安装的证书。遇到这种情况，要么用低版本 Android 设备，要么在 App 的 network security config 里加白名单，要么把证书装到系统分区。没有 root 的话，前两条路更现实。

3.3 抓包结果分析：Timeline、Statistics 与 Inspectors

抓到请求之后，怎么看才是关键。Fiddler 右侧的 Inspectors 面板分上下两部分，上面是请求，下面是响应。每个部分都有多个标签页：Headers 看头信息，TextView 看文本 Body，ImageView 看图片，HexView 看二进制。排查接口问题时，我一般先看 Headers 里的状态码和 Content-Type，再看 TextView 里的返回体。

Timeline 标签页用瀑布图展示每个请求的耗时分布，能一眼看出哪个请求慢、慢在 DNS 还是 TLS 还是服务端处理。Statistics 标签页则给出本次会话的汇总数据，比如请求总数、发送字节数、接收字节数。这两个面板在性能排查时比逐个看请求高效得多。

4. 避坑与排查：Fiddler 抓不到包的五个常见原因

Fiddler 用起来不难，但翻车的地方不少。下面这五条是我自己踩过或者帮别人排查时最常遇到的。

现象一：浏览器能上网，但 Fiddler 列表里什么都没有。原因：系统代理没生效，或者 Fiddler 没有以管理员权限运行。 解决：检查 Tools → Options → Connections 里的 “Act as system proxy on startup” 是否勾选。Windows 下建议以管理员身份运行 Fiddler，否则改不了系统代理。另外看看是不是有其他代理工具在抢系统代理设置。

现象二：HTTPS 请求全是 CONNECT 隧道，看不到明文。原因：根证书没装，或者装了但没放进“受信任的根证书颁发机构”。 解决：重新导出证书，安装时手动选择“将所有的证书都放入下列存储 → 受信任的根证书颁发机构”。装完重启浏览器。如果还不行，在 Fiddler 的 HTTPS 选项里勾上 “Decrypt HTTPS traffic”。

现象三：手机代理设好了，但 Fiddler 里没有手机流量。原因：手机和电脑不在同一网段，或者电脑防火墙拦了 8888 端口。 解决：确认手机和电脑连的是同一个 Wi-Fi，且没有开 AP 隔离。在电脑上临时关闭防火墙测试，如果能通，就在防火墙里给 8888 端口加入站规则。

现象四：Android App 抓不到包，浏览器却可以。原因：App 不信任用户证书，或者 App 用了证书固定（SSL Pinning）。 解决：Android 7.0 以上，用户证书默认不被 App 信任。可以尝试在 App 的 network security config 里加信任，或者用低版本 Android。如果是 SSL Pinning，Fiddler 这种常规中间人方式基本无解，需要额外手段，这里不展开。

现象五：Fiddler 开着的时候，某些网站打不开或者报证书错误。原因：Fiddler 的证书和网站证书冲突，或者 Fiddler 的规则拦截了请求。 解决：先关掉 Fiddler 确认网站正常，然后检查 Rules → Automatic Breakpoints 是不是设了断点没放行。另外在 HTTPS 选项里可以给特定域名设置 “Skip decryption”，让这些域名不走解密，直接隧道转发。

5. 进阶技巧：用 FiddlerScript 和 Composer 把抓包变成自动化

Fiddler 最被低估的能力是 FiddlerScript。前面提过 CustomRules.js，它本质上是一个事件驱动的脚本环境，能在请求和响应的各个生命周期插入自定义逻辑。除了改 Header，还能做自动重定向、自动 mock 响应、自动记录日志。

比如线上某个接口返回了错误数据，你想在本地复现但服务端不好改，可以在 FiddlerScript 里拦截这个请求，直接返回一个本地构造的响应：

// 拦截特定 URL，返回自定义 JSON static function OnBeforeResponse(oSession: Session) { if (oSession.url.Contains("api.example.com/user/profile")) { oSession.utilDecodeResponse(); // 解码响应体 var oBody = oSession.GetResponseBodyAsString(); if (oBody.Contains("\"code\":500")) { // 把错误响应替换成正常数据 var mockBody = "{\"code\":0,\"data\":{\"name\":\"test\"}}"; oSession.utilSetResponseBody(mockBody); } } }

这段脚本挂在 OnBeforeResponse 上，在响应返回给客户端之前执行。oSession.url.Contains判断请求地址，utilDecodeResponse解码压缩的响应体，GetResponseBodyAsString拿到文本内容，utilSetResponseBody替换成新的 Body。这样客户端收到的就是你构造的数据，不用改服务端代码就能验证前端逻辑。参数说明：utilDecodeResponse处理 gzip 压缩，不解码的话拿到的可能是乱码；utilSetResponseBody会自动更新 Content-Length，不用手动改。

另一个实用工具是 Composer。左侧 Composer 标签页可以手动构造 HTTP 请求，填 URL、Method、Header、Body，点 Execute 就发出去。这个在测试接口时比写 curl 命令直观，尤其是需要带一堆 Header 和 Cookie 的场景。构造好的请求可以保存到 Sessions 列表里，下次直接拖出来重放。

还有一个技巧是给 Fiddler 加自定义列。默认列表只显示 URL、Status、Protocol 等几列，可以在列头上右键 → Customize Columns，加一列显示请求耗时或者响应大小。我一般会加一列 “Duration”，按耗时排序，快速定位慢请求。

从那以后我每次装完 Fiddler，第一件事就是导出证书装到受信任根目录，第二件事是把 CustomRules.js 备份一份。因为升级或者重装的时候，这些配置不会自动保留，重新配一遍很烦。希望帮到你。

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