企业官网建设流程全解析

做 Web 开发这些年，我调试接口、排查线上问题，用到最多的工具就是 Fiddler。抓包工具名字听起来很专业，说白了就是一台“中间交换机”：所有经过本机的 HTTP/HTTPS 流量，它都能截下来给你看。不管你是后端排查接口返回，还是前端查看实际请求，又或者是做移动端联调，总会在某个时刻需要它。

这篇内容我不打算抄官方文档，而是结合这几年实际使用中踩过的坑、积累的技巧，把 Fiddler 抓包工具从安装到进阶用法完整讲一遍。内容适合刚接触抓包的新手，也适合用了一段时间但总在某些细节上卡住的朋友。我会尽量说人话，把原理讲透，把操作步骤展开，争取你看完就能直接上手。

1. 抓包这件事，到底在抓什么

1.1 抓包抓的是“约定”

很多人第一次打开 Fiddler，看到满屏的会话记录是懵的：这么多条目，到底哪个是我要看的？这里得先建立一个大前提：抓包抓的不是“数据”，而是“请求”。

HTTP 协议本质上是一套约定好的对话格式。客户端发起请求时，要带上请求行（方法、路径、协议版本）、一堆请求头（Host、User-Agent、Cookie、Content-Type 等），以及可选的请求体。服务器返回时，同样会带上状态行（200、404、500 一类的状态码）、响应头、响应体。Fiddler 做的事，就是把这套对话完整记录下来，并呈现给你看。

用个生活化的类比：你去饭店点菜，菜单格式是固定的，服务员应答的格式也是固定的。抓包就是站在柜台旁边，把“客人点了什么、服务员上了什么、菜是什么颜色”全部记录成一张流水单。不同的是，HTTP 流水单里每条记录都带有完整的前后文，方便你追查任何一个异常环节。

理解这一点，你就知道后文所有操作的核心目标了：找到一条你关心的会话，看清楚它的请求和响应，必要时再动手修改。

1.2 什么场景最需要 Fiddler

我实际使用中，遇到最多的场景是这几类：

• 接口联调：前后端对接时，前端说“我传了参数但返回 400”，后端说“我这边没收到参数”，两边各执一词，抓一次包就知道问题出在哪。
• 线上问题排查：用户反馈某个页面异常，但本地环境复现不了。抓包看看线上真实返回的数据，往往一眼就能定位。
• 移动端调试：手机 App 的请求看不到，用 Fiddler 做代理，把手机流量导到电脑上抓。
• 接口 Mock：后端接口还没写好，前端先用 Fiddler 模拟一个假响应，开发进度不阻塞。
• 性能观察：看某个接口的整体耗时、DNS 时间、连接时间、下载速度，定位慢在哪一步。

这些场景覆盖了开发流程中几乎所有“需要看清网络通信”的时刻。比起到处打日志，抓包是最直观、最快的一种方式。

1.3 为什么不用浏览器自带调试工具

可能你会问：浏览器开发者工具里的 Network 面板也能看请求，为什么还要单独学 Fiddler？

浏览器自带工具确实方便，但它有几个明显局限。第一，它只能看当前页面发出的请求，管不到其他客户端；第二，它不好全局拦截并修改请求，尤其是你想模拟一个特殊响应时，很难操作；第三，它看不到非浏览器流量，比如桌面软件、手机 App、游戏客户端的请求。

Fiddler 这类独立代理工具的思路完全不同：它把自己注册成系统代理，所有经过本机的 HTTP/HTTPS 流量都会被它截获，然后再转发出去。这意味着不管请求来自浏览器、桌面程序还是同一局域网里的手机，只要流量通过它，它就能看到。这是浏览器开发者工具做不到的。

2. 安装、启动与界面认知：先让工具跑起来

2.1 版本选择和安装注意事项

Fiddler 有两个常见版本：Windows 上用的是经典的 Fiddler Classic，免费，功能完整；macOS 和 Linux 上用的是 Fiddler Everywhere，界面更现代，但部分高级功能需要付费授权。

我个人的建议是：如果你主要用 Windows，直接上 Fiddler Classic，够用且习惯的人多；如果你在 macOS 上做开发，选择 Fiddler Everywhere 会更顺手。安装过程没什么特别复杂的，一路下一步就行，但有三个地方要提前注意：

• 安装时尽量关闭正在运行的浏览器和其他网络请求频繁的程序，避免端口占用。
• 安装路径不要带中文，避免后面脚本和证书路径处理出问题。
• 部分杀毒软件会把 Fiddler 的证书安装识别为风险操作，遇到拦截提示时要确认来源后再放行。

装好后第一次打开，如果系统弹出“是否允许修改代理设置”之类的提示，要点允许。Fiddler 的核心工作方式就是修改系统代理，不授权它什么都干不了。

2.2 界面五大区域快速熟悉

Fiddler 的界面初看有点乱，但拆开看就五块区域：

• 会话列表（左上）：所有被捕获的请求都会按时间顺序列在这里，每条显示 URL、状态码、协议、Host、大小、耗时等关键字段。
• 过滤器区（顶部工具栏下方）：用于隐藏不想看的请求，只保留你关心的流量。
• 详情面板（右侧）：点中某条会话后，这里会显示请求的信息，包括 Headers、Cookies、JSON、Raw 等不同视图。
• QuickExec 命令行（左下）：一个类似命令行的输入框，输入规则和命令可以快速操作 Fiddler。
• 状态栏（底部）：显示当前是否在抓包、代理地址、捕获进度等信息。

刚开始你不用记全，只需要记住：左边会话列表是“目录”，右边详情面板是“正文”，左下命令行是“快捷操作入口”。后面所有操作基本都是围绕这三块展开。

2.3 默认的“本机代理”是怎么工作的

打开 Fiddler 后，它会自动把 Windows 系统代理设置为 127.0.0.1:8888。这一步是自动完成的，所以你打开 Fiddler 后，浏览器的流量就会从原本直连服务器的路径，变成“浏览器 → Fiddler → 服务器”。

这中间多了一道转发，但正常情况下你不会感觉到速度差异。Fiddler 拿到浏览器的请求后，会原样转发给目标服务器；拿到服务器的响应后，也会原样返回给浏览器。它就像一个顺便做记录的信使。

这里有个重要的坑：如果你直接点击右上角的 × 关闭 Fiddler，或者程序异常退出，系统代理可能不会自动恢复。结果就是浏览器还能打开网页，但所有请求都走不到服务器，具体表现是页面一直转圈打不开。遇到这种情况，去 Windows 的“Internet 选项 → 连接 → 局域网设置”里，把代理服务器的勾选去掉即可恢复。

3. HTTPS 为什么抓不到，以及如何解开这层壳

3.1 代理能看到的其实是密文

默认情况下，你用 Fiddler 抓 HTTPS 流量，会话列表里会看到一堆“Tunnel to”的条目，双击进去内容是密文，什么都看不懂。这是因为 HTTPS 在 HTTP 基础上加了一层 TLS 加密：请求发出前是明文，发出后经过 TLS 握手变成密文，服务器收到后解密。Fiddler 只是一个代理，它转发的数据是密文，自然没法记录“明文内容”。

很多人卡在第一步，就是在这里：明明 Fiddler 启动了、流量也经过了，但就是看不到内容。其实这不是 Fiddler 坏了，而是你还没让它拥有“解密”的权限。

3.2 Fiddler 的解密思路：中间人这一步怎么实现

Fiddler 采用的解密方案叫“中间人解密”。思路大致是这样的：

• 它生成一个属于自己的根证书，并把这个根证书安装到系统“受信任的根证书颁发机构”里。
• 当浏览器向一个 HTTPS 网站发起请求时，Fiddler 会拦截这个请求，然后用自己的证书伪装成那个网站，与浏览器完成一次 TLS 握手。
• 与此同时，Fiddler 又作为客户端，与真正的目标服务器建立另一次 TLS 连接。
• 两条连接都是加密的，但 Fiddler 同时握有两边的密钥，所以它能把浏览器发来的密文解开、记录下来，再重新加密转发给服务器；服务器返回的密文，它也能解开、记录，再加密回传给浏览器。

用同声传译来类比：你以为你在和老外直接对话，实际上中间隔了一个翻译。翻译能听懂两边的话，还能把话传给对方，但你要想真正听懂原话，就必须让这个翻译是“你信任的人”。Fiddler 的根证书，就是让你系统信任这个翻译的凭证。

3.3 证书安装的关键细节

解密操作的入口是菜单栏的 Tools → Options → HTTPS，勾选 Decrypt HTTPS traffic。勾选后，Fiddler 会问你是否导入它自带的根证书，点是即可。

但这一步只是让 Fiddler 自己“准备”好证书，真正让浏览器信任它，还得把根证书装到系统里。具体操作是：

1. 在 Tools → Options → HTTPS 页面，点击 Actions 按钮。
2. 选择 Export Root Certificate to Desktop，把证书导出到桌面。
3. 右键这个证书文件，选择“安装证书”。
4. 证书存储位置选择“本地计算机”，然后手动选择“受信任的根证书颁发机构”。

装完之后重启浏览器，再访问 HTTPS 网站时，Fiddler 就能看到明文内容了。

这里有个关键细节：证书必须安装在“受信任的根证书颁发机构”，不能是“个人”或“中间证书颁发机构”。我见过很多人安装时一路下一步，结果装到了个人证书区，抓包依旧是密文。

如果你是 macOS 上的 Fiddler Everywhere，安装证书后还要在“钥匙串访问”里找到对应证书，把它标记为“始终信任”，否则系统依旧不信任它。

4. 常规抓包实操：从启动到精准定位请求

4.1 第一次抓包：看明白一个完整请求

我先带你走一遍最基础的流程。打开 Fiddler 后，打开浏览器随便访问一个网站，回到 Fiddler，你会看到会话列表里不断有新的条目刷新。每一条就是一个请求。

点中其中一条，右边详情面板默认显示的是 Inspectors 视图。上面是请求，下面是响应。请求部分重点看三块：请求行（比如 GET /index.html HTTP/1.1）、请求头（一堆键值对）、请求体（如果是 POST 的话）。响应部分重点看状态码、响应头、响应体。

新手最容易犯的错是看到什么点什么。建议第一次抓包时，先关闭其他一切网页和程序，只留浏览器访问一个简单页面。这样会话列表里只有几十条记录，你能清楚分辨哪些是页面本身的 HTML，哪些是 CSS、JS、图片，哪些是接口请求。

拿到一条请求后，按顺序看三个字段：URL 确定请求目标，Method 确定操作类型，Status Code 确定处理结果。三个字段看完，基本就知道这条会话在做什么了。

4.2 用 Filters 快速过滤目标流量

真实开发场景里，会话列表每分钟可能刷新几百条记录，其中大量是图片、CSS、字体这类静态资源。你要是靠肉眼在列表里翻找目标接口，会非常痛苦。Fiddler 的 Filters 就是用来解决这个问题的。

在 Fiddler 左上角勾选 Use Filters，然后在下拉框里选择过滤条件。我使用频率最高的是 Host 过滤和进程过滤：

• Host 显示：选择 Show only the following Hosts，然后在下面的输入框里填api.example.com，列表里就只剩这个域名的请求了。
• 进程过滤：选择 Show only traffic from specific processes，然后勾选当前浏览器进程，这样其他软件的请求就不会混进来。

还有一个很实用的场景：把静态资源隐藏掉。在 Filters 里勾选 Hide if URL contains，填入.css|.js|.png|.jpg|.ico，这些资源请求就不会再污染你的视线。

这里有个操作细节：修改某种过滤条件后，旧的会话不会立刻从列表里消失，但新捕获的会话会按照新规则展示。想快速清空列表重新开始，可以按快捷键 Ctrl+X 或点击会话列表上方的“删除全部”按钮。

4.3 QuickExec 命令行：老手都在用的快捷键

QuickExec 是 Fiddler 一个很容易被忽略但极其强大的能力。它位于左下角，是一个单行输入框。在这里输入命令，可以替代大部分鼠标操作。

我最常用的命令是这些：

cls 清空会话列表 ?s=login 查找 URL 中带 login 的全部会话 select html 选中类型为 html 的会话 bpu 设置请求断点，后面跟 URL 关键字 bpafter 设置响应断点，后面跟 URL 关键字 bps 按状态码设置响应断点

举个例子：你在联调时想只看登录接口https://api.example.com/user/login的请求，可以在 QuickExec 里输入：

?s=/user/login

回车后，会话列表会立刻筛选出所有 URL 包含该路径的请求。这个查找功能比肉眼快得多，尤其是流量大的时候。

还有一组命令值得记：bpu和bpafter。它们用来打断点，后面会详细讲。你现在只要知道，所有以>开头的命令都能填入 QuickExec，输入时还有自动补全提示，多按几个 Tab 就能看到候选命令。

5. 移动端抓包配置：安卓与苹果的真机实战

5.1 模拟器场景：局域网代理加证书

移动端抓包有两个场景：模拟器和真机。先说模拟器，以最常见的安卓模拟器为例。

核心操作是两步：设置代理、安装证书。

第一步，找到你电脑在局域网里的 IP 地址。在命令行输入ipconfig（Windows）或ifconfig（macOS），找到类似于192.168.x.x的地址。注意，这里的 IP 不能是 127.0.0.1，因为模拟器内部的 127.0.0.1 指向它自己，不是你电脑。

第二步，在 Fiddler 中允许远程连接。打开 Tools → Options → Connections，勾选 Allow remote computers to connect。这一步如果不做，手机和模拟器根本连不上 Fiddler 的 8888 端口。

第三步，在模拟器里设置代理。路径一般是“设置 → WLAN → 长按当前网络 → 修改网络 → 高级选项 → 代理”，把主机名填你电脑的局域网 IP，端口填 8888。

第四步，用模拟器里面的浏览器访问http://你的电脑IP:8888，页面会显示 Fiddler 的证书下载界面，点击下载并安装 Fiddler 根证书。

装完证书，模拟器里的流量就能被正常解密了。

5.2 真机场景：设置代理与安装证书

真机和模拟器的思路完全一样，只是要求手机和电脑必须连接同一个 WiFi。

以安卓手机为例：进入 WiFi 设置，把当前网络的代理模式改为“手动”，主机名填电脑的局域网 IP，端口填 8888。然后打开手机浏览器访问http://电脑IP:8888下载证书，下载完成后在“设置 → 安全 → 加密与凭据 → 安装证书”里完成安装。苹果手机流程差不多，但证书装完后，还要去“设置 → 通用 → 关于本机 → 证书信任设置”里，把 Fiddler 证书的完全信任开关打开，否则系统不会认它。

真机操作里最容易翻车的是防火墙。Windows 自带防火墙默认会拦截来自外部设备的 8888 端口访问，导致手机下载不了证书，代理也连不上。遇到这种情况，你需要手动在防火墙“入站规则”里放行8888端口，或者干脆在被拦截的提示里勾选允许访问。macOS 也要留意网络权限弹窗，必须允许 Fiddler 接受外部连接。

还有一点容易被忽视：安卓手机的“私人 DNS”功能会干扰代理解析，抓包时最好把它关掉。如果用某一款手机系统的默认浏览器下载证书失败，换用系统自带浏览器或者无痕模式登录，成功率会高很多。

5.3 安卓 7.0 以上的 App 抓包问题

真机抓包还有一道大坎：安卓 7.0 及以上系统，App 默认不信任用户安装的 CA 证书。简单说，就算你把 Fiddler 根证书装到了手机里，很多 App 依然会拒绝用这个证书建立 HTTPS 连接，表现就是 Fiddler 里看到一堆握手失败或者连接重置。

这是因为安卓从 7.0 开始，默认的安全配置只信任系统证书，不信任用户证书。普通浏览器还是能用你装的用户证书，因为浏览器自己实现了证书信任逻辑，但大多数 App 走的是系统默认逻辑，直接不认。

解决办法有几种：

• 如果 App 是自家开发的，在项目的网络配置里允许调试证书，这种方式最干净。
• 把 Fiddler 证书安装到系统证书目录，这需要 Android 手机已 root，或者借助 Magisk 模块把证书转成系统证书。
• 使用支持客户端证书的抓包工具，比如通过模拟器里的调试模式来绕过某些限制。

我个人的建议是：优先用模拟器抓 App 的包，尤其是涉及到 HTTPS 的场景。真机抓包更适合调试那些信任用户证书的应用，或者在你能控制 App 调试配置的情况下使用。

6. 进阶玩法：断点、构造请求与模拟响应

6.1 用断点拦截请求和响应

抓包只是第一步，Fiddler 真正值钱的能力是“修改流量”。断点就是最常用的修改手段。

断点分成两类：请求断点和响应断点。请求断点在请求发往服务器的路上拦截，响应断点在服务器返回的路上拦截。设置方式直接在 QuickExec 里输入：

bpu /api/user/login // 拦截 URL 中包含该路径的请求 bpafter /api/user/login // 拦截 URL 中包含该路径的响应

设置了请求断点后，当你触发目标请求，Fiddler 会话列表里那条记录会变成一个带红色箭头的状态，双击它进入详情面板，你就能随意修改请求头、请求体、Cookie 等字段。改完后点击“Break on Response”继续放行，请求就会以修改后的内容发往服务器。

响应断点的操作类似，只不过你修改的是服务器返回的状态码、响应头和响应体。这个能力在测试前端容错时特别有用：比如你想验证前端在“接口返回 500”或者“返回字段缺失”时会不会出问题，直接用响应断点改一个假响应就行，不用真的让后端制造故障。

需要注意的是，设置断点后别忘记取消。取消断点的命令是bpu或bpafter后面不带参数直接回车，它会清空你之前设置的拦截条件。否则你会在某个时刻误以为 Fiddler 坏了——其实是被你自己设的断点卡住了。

6.2 Composer：手工构造一个请求

Composer 可以让你不依赖外部程序，直接手工发出一个 HTTP 请求。它本质上是一个请求构造器，适合用来重放接口、测试参数边界、验证服务端逻辑。

用法很简单：在 Fiddler 菜单栏点击 Composer 标签，你会看到一个类似编辑器的界面。从左往右依次设置请求方法（GET、POST、PUT、DELETE 等）、请求 URL、HTTP 版本、请求头、请求体。填好后点击右上角的 Execute 按钮，请求就会真实发出去，并且出现在会话列表里。

我在实际调试中经常用 Composer 干一件事：把接口从“正常参数”改成“错误参数”，看服务端返回什么。比如登录接口，我先把正常请求抓下来，拖到 Composer 里，然后把密码字段改成错误值，执行一次，看返回的提示信息是否合理。这比打开 Postman 重新填一堆参数要省事得多，因为请求头、Cookie、签名这些都能直接沿用抓到的原始数据。

有个细节：Composer 里的请求头是原始的文本格式，如果请求体格式是 JSON，要在请求头里明确指定Content-Type: application/json；如果是表单，则用application/x-www-form-urlencoded。格式不对，服务器可能直接不认。

6.3 AutoResponder 模拟接口返回

AutoResponder 是 Fiddler 里我利用率最高的功能之一，它的作用是把某个请求“替换”成你指定的响应。简单说就是造假接口返回。

操作流程非常直接：把会话列表里的一条请求直接拖到右侧 AutoResponder 面板里，勾选 Enable rules 和 Unmatched requests passthrough，然后在下方的规则列表里选中这条规则，编辑它的响应内容。

响应内容有三种常见来源：找本地的 HTML/JSON 文件作为响应体；用 Fiddler 自带的响应编辑器手写返回内容；或者指定一个 HTTP 状态码（比如直接返回 404）。编辑完成后，重新触发那个请求，返回给你的就不再是服务器的真实响应，而是你编辑的假响应。

这个功能最典型的应用场景是：后端接口还没写好，前端要先开发页面。你把接口的 Request 拖进 AutoResponder，写一份符合接口文档的假 JSON 返回，页面就能正常联调，不用干等后端。

这里有个容易踩的坑：AutoResponder 里返回本地文件时，路径不要有中文和空格，否则可能出现加载失败。另外，如果你修改了规则但实际访问时没生效，先检查是否勾选了 Enable rules，以及目标请求是否真的匹配到了这条规则。

7. 高频问题与避坑经验

7.1 高频问题速查表

我把这几年用 Fiddler 遇到的问题整理成一个速查表，方便你直接对照参考：

这些问题是初学者遇到最多的几类，大部分不需要重装 Fiddler，往往只是配置层面的小问题。

7.2 几个容易忽略的细节

除了上面的高频问题，我还有几个实战中总结的细节想单独提一下：

第一，抓包时优先开无痕浏览器窗口。普通浏览器窗口会命中大量缓存，导致很多请求根本不会发出去，你看到的流量就是不完整的。无痕窗口可以最大程度避免缓存干扰。

第二，长时间抓包记得定期清理会话列表。Fiddler 把所有请求都保存在内存里，几个小时不清理，内存占用会越来越高，界面操作明显变慢。我的习惯是每完成一个调试任务就 Ctrl+X 清空一次。

第三，不要把 Fiddler 开着用于日常上网。它是开发调试工具，不是常驻软件。平时上网挂着它，所有流量都要经过一层转发，不仅影响速度，还会记录大量你完全不需要的信息。用完就关，保持干净。

第四，FiddlerScript 值得研究。在 Fiddler 菜单里可以打开 FiddlerScript 编辑器，它允许你用脚本在请求和响应经过时自动执行一些逻辑，比如自动给所有请求添加一个 Header，或者自动修改响应内容。这个功能有一定学习成本，但掌握后能极大提高调试效率。

第五，如果遇到 Fiddler 本身崩溃或者配置混乱，不用急着卸载重装。把安装目录下的配置备份后删掉，重开软件让它重新生成本地配置，大多数问题都能解决。别问我是怎么知道的——这是我踩过最深的一个坑。

我自己最开始用 Fiddler 时，光是把界面看明白都花了半天，后来真正跑通“抓 HTTPS → 过滤目标 → 断点修改 → 模拟响应”这条链路后，才算真正把它的价值榨出来。回头看，Fiddler 最值钱的不是界面，而是帮助你建立对网络请求流转的完整认知：请求从哪里来、经过哪里、变成了什么、最终去了哪里。

最后再分享一个小技巧：如果你经常要在不同项目间切换调试目标，把你的常用 QuickExec 命令和 Filters 配置记在一个笔记里，换项目时直接对照着设置，能省下大量重复操作的时间。抓包这件事其实没什么高深莫测的，多抓几次、多改几次，你自然就会了。