企业官网建设流程全解析

今天这篇聊聊Fiddler抓包，以及怎么让Chrome浏览器把HTTP协议和HTTPS协议的流量都完整地暴露出来。不管你是做前端联调、接口测试、爬虫分析，还是排查线上请求异常，只要用到Fiddler，前半段路基本都是相同的：装好工具、配好代理、装好证书。但恰恰是这些看似基础的操作，卡住了不少人——尤其是HTTPS这一步，很多人装完证书后依然只能看到CONNECT隧道，或者Chrome直接报证书错误，连网页都打不开。

这篇文章不打算只给步骤，还会把背后的原理讲透，同时把我平时实践中踩过的坑、测试过可行的方法一并整理出来。适合刚接触抓包的初学者，也适合用了很久但始终没搞明白HTTPS解密逻辑的老手。看完之后，你至少能独立完成从零配置，到过滤、改包、重放、弱网模拟这一整套操作。

1. 项目概述：Fiddler配合Chrome到底能做什么

1.1 典型使用场景

我最早接触Fiddler，是在做前后端联调的时候。后端同学说“接口返回了”，但前端拿到的数据总是不对，两边谁也说不清楚问题出在哪儿。这时候在Chrome开发者工具里看Network固然可以，但开发者工具能看到的内容仅限于浏览器当前页面发出的请求，而且不便于做篡改重放。换成Fiddler后，所有经过代理的请求都会被记录下来，前端可以看清请求头、请求体、响应体，后端可以拿着抓包文件去定位问题，沟通成本一下降下来了。

除了接口联调，Fiddler在几类场景中特别常用：

• 接口调试与Mock：通过AutoResponder直接返回指定的本地文件，不需要等后端出接口。
• 弱网模拟：模拟高延迟、低带宽网络，验证页面在极端网络下的表现。
• 移动端抓包：手机关联到电脑的Fiddler代理，查看App内WebView的流量。
• 小程序抓包：微信小程序很多请求走的是HTTP/HTTPS，配置好代理后同样能抓到。
• 安全与异常排查：查看是否存在敏感信息明文传输、接口是否返回异常状态码等。

你会发现这里面有一个共性：Fiddler本身不关心流量是哪来的，它只关注是否经过它这个“中介”。只要Chrome把代理指向Fiddler，流量就会乖乖地流过来。

1.2 为什么选Fiddler而不是其他工具

很多人会问，Chrome自带的开发者工具不也能抓包吗？确实能，但够用和好用是两回事。

开发者工具只能看到当前页面发起的请求，无法拦截其他进程的HTTP请求，不能对请求体做断点修改，也不方便把某条请求原封不动地重放一遍。它更像一个“只读”面板，适合快速查看，不适合做深入的请求分析和数据篡改。

Charles也是老牌抓包工具，功能上与Fiddler非常接近，但正经版本需要付费，不付费的话使用时间有限制。Wireshark则是另一类工具，它工作在网卡层，能抓TCP、UDP甚至ARP报文，但对应用层HTTP的分析能力反而不如Fiddler直观。Fiddler Classic作为免费工具，功能齐全、插件丰富、占用小，对Web开发调试来说，性价比非常高。

所以我的观点很直接：日常开发调试，Fiddler是综合体验最省事的那个。

2. 抓包原理与核心概念拆解

2.1 代理机制：Fiddler为什么能看穿一切

Fiddler本质是一个本地代理服务器。安装并启动后，它默认监听127.0.0.1的8888端口，Chrome将HTTP请求发送到该端口，Fiddler接收到后，再以客户端身份将请求转发给目标服务器。响应返回时同样经过Fiddler，它把服务端的响应转发给Chrome。整个过程可以类比成快递中转站：包裹原封不动地从中转站进出，但中转站每一件都拆开验视、记录在案。

Chrome自身并不直接和互联网上的服务器通信，而是先跟Fiddler打招呼。因此Fiddler能看到完整的URL、请求头、Cookie、POST表单、响应内容等。只要数据经过了它，它就能记录并展示。

那为什么有些人配置完还是抓不到包？最常见的原因是：Chrome没有真正将代理设置为Fiddler，或者Chrome开启了QUIC/HTTP3，这类协议属于UDP之上的可靠传输，Fiddler默认无法解密。这一点后面会专门讲。

2.2 HTTPS解密的中间人机制

HTTP是明文协议，抓包无需特殊处理。HTTPS则是在HTTP外面套了一层TLS加密，请求内容在网络上是密文。按理说Fiddler只能看到加密后的数据，但问题在于浏览器信任了谁。

Fiddler的办法是生成一个根证书，并引导用户将它安装到操作系统的“受信任的根证书颁发机构”列表中。安装之后，浏览器就会信任由这个根证书签发的所有子证书。每次浏览器向Fiddler发起HTTPS连接时，Fiddler都会动态地为对应域名生成一张“冒名顶替”的证书，浏览器检查后认为证书合法，于是放心地用Fiddler的公钥加密数据。Fiddler解密后，再与真正的目标服务器重新建立一条加密通道，把请求转发出去。

生活化地说，这就像A和B在传密信，原本C无法查看内容，但C提前伪造了一把双方都认可的钥匙。A把内容加密后交给C，C用自己的钥匙打开看，再换成真正的钥匙重新加密发给B。只要信任链建立起来，解密就变得顺理成章。

关键点在于，这种“中间人”能力完全依赖浏览器对根证书的信任。一旦证书安装的位置不对、信任级别不够，或者证书过期，浏览器就会立刻报警，HTTPS抓包也就宣告失败。

2.3 Fiddler的工作流程概览

一次完整的抓包流程可以梳理为如下几步：

1. Chrome的请求依据代理设置发送到Fiddler的监听端口。
2. 若是HTTPS请求，Fiddler先检查目标域名是否已生成过证书，没有则即时生成，并用根证书签名。
3. Chrome验证证书有效后，与Fiddler建立TLS连接。
4. Fiddler解密请求内容，同时向目标服务器发起真实请求。
5. Fiddler收到响应后，解密并记录内容，再加密返回给Chrome。

第2步是整条链路中最容易出问题的地方，一旦证书不受信任，整个流程就会在“Chrome验证证书”这一环断裂。

3. 环境准备与基础配置流程

3.1 选择版本：Fiddler Classic还是Fiddler Everywhere

官方有两个产品线。Fiddler Classic是经典的免费版本，仅支持Windows，界面老派，但功能够用，插件生态成熟，大多数教程和脚本都是基于它写的。Fiddler Everywhere则是跨平台版本，支持Windows、macOS、Linux，界面更现代，但需要登录账号，免费版有流量限制，部分功能被收纳到付费墙后面。

就“抓包并设置Chrome代理”这个目标而言，我更推荐Fiddler Classic。它轻量、免登录，设置项直接，不容易被各种弹窗干扰。如果你用的是macOS，那只能选择Fiddler Everywhere，或者去考虑Charles。Windows用户直接上Classic即可。

下载时注意认准官方域名，目前是Telerik旗下的Fiddler页面。网上有些镜像站捆绑了额外的软件，安装时一旦出现全家桶勾选，马上取消。

3.2 初始化配置：端口、捕获开关、远程连接

安装完成后，先做三个基础设置。

打开菜单栏的Tools -> Options，在Connections选项卡中确认Fiddler listens on port为8888，同时勾选Allow remote computers to connect。后者非常重要，如果你想用手机或模拟器抓包，没有开启这个选项，外部设备根本连不上你的代理。

同一个选项卡里，还有一个“Capture HTTPS CONNECTs”和“Chain to upstream proxy”之类的选项。日常调试保持默认即可。如果公司网络本身就走代理，需要在“Upstream Proxy”中填写公司代理地址，否则Fiddler转发流量时会直接连外网，可能受到网络策略限制。

设置完成后，回到主界面，确认左下角的“Capturing”状态是开启的。只有处于捕获状态时，Fiddler才会记录经过的流量。

3.3 开启HTTPS解密与证书安装

这是整篇文章的重中之重。进入Tools -> Options，切到HTTPS选项卡，勾选Capture HTTPS CONNECTs和Decrypt HTTPS traffic。勾选后，弹窗会提示证书信任问题，一般情况下我们直接选择“Yes”来信任Fiddler根证书。

这里我要特别提醒：自动信任操作有时候会在当前账户的“个人”证书存储区安装，而不是系统级别的“受信任的根证书颁发机构”。如果Chrome后续依然无法解密HTTPS，你需要手动检查证书位置是否正确。

手动检查方法：按Win + R，输入certmgr.msc，打开证书管理器，展开“受信任的根证书颁发机构”->“证书”，查找名为DO_NOT_TRUST_FiddlerRoot的证书。只要它存在于这个文件夹，就说明根证书已经被系统信任。如果不在，就需要手动导入。

手动导入的做法是：在Fiddler的HTTPS选项卡里，点击Actions -> Export Root Certificate to Desktop，导出得到CER文件，然后右键选择“安装证书”，存储位置选择“本地计算机”，再选“将所有的证书都放入下列存储”，浏览选择“受信任的根证书颁发机构”，一路下一步即可。

3.4 证书安装后的自查清单

证书装完之后别急着用，先做两项排查。第一，查看证书有效期。DO_NOT_TRUST_FiddlerRoot的默认有效期很长，但如果电脑系统时间不对，浏览器会认为证书无效。遇到“证书不是来自受信任的来源”“证书已过期”这类报错，先校准系统时间。

第二，清除Chrome的证书缓存和安全策略缓存。Chrome在启动时会加载系统证书库，但某些情况下缓存会导致新证书未被读取。最简单的办法是重启浏览器，或者打开Chrome的地址栏输入chrome://net-internals/#ssl，点击Clear session data清理SSL状态。

4. Chrome浏览器接入Fiddler的完整配置

4.1 设置Chrome的代理指向

Chrome本身不提供独立的代理设置框，它默认读取操作系统的代理配置。所以让Chrome走Fiddler，最直接的方式是把系统代理指向127.0.0.1:8888。

Windows下的设置路径：设置 -> 网络和Internet -> 代理，打开“使用代理服务器”开关，地址填127.0.0.1，端口填8888，保存即可。改完之后，Chrome新发起的请求就会自动经过Fiddler。

但这里有一个体验问题：改系统代理会影响所有走系统代理的软件，比如微信可能会突然无法登录，或者某些自动更新程序变慢。我平时开发时更推荐用浏览器插件来控制代理，比如SwitchyOmega。安装插件后新建一个“Fiddler”情景模式，协议HTTP，服务器127.0.0.1，端口8888，然后一键切换。

举个例子，如果我只想调试项目A，那就把SwitchyOmega切到Fiddler模式；调试结束后切回“直接连接”。整个过程中系统代理保持关闭，不影响其他软件。这个方式对日常高频调试友好得多。

4.2 验证HTTP和HTTPS流量是否正常捕获

配置完成后，打开Chrome访问一个测试页面。正常情况下，Fiddler主界面左侧会持续刷出会话记录。

区分HTTP和HTTPS请求的方法很简单：看协议列。HTTP请求显示为http，HTTPS请求显示为https。如果HTTPS请求那一行前面带一个锁形图标，说明Fiddler已经成功解密，点开Inspectors可以看到完整的请求体和响应体。如果只看到一条隧道记录且无法展开内容，大概率是证书或解密开关没弄好。

举个实战例子：我访问https://www.baidu.com，Fiddler里应该出现一条主机名为www.baidu.com的https会话。双击这条记录，在Inspectors选项卡的上半部分能看到请求头里的User-Agent、Cookie，下半部分能看到HTML源码与响应头。如果你看到的全是星星符号或者一个1KB出头的CONNECT记录，那基本就是解密环节出了问题。

4.3 Chrome版本差异对抓包的影响

Chrome浏览器近两年更新频繁，有几个版本细节值得留意。首先是Chrome 109及以上版本，Google逐步在默认配置中推广HTTP/3和QUIC协议。QUIC是基于UDP的加密传输协议，Fiddler的代理机制是面向TCP的，它能看到UDP请求的痕迹，但很难像HTTPS那样直接解密查看内容。

我在一次实际测试中就碰到过这种情况：开启Fiddler后，YouTube、Google搜索等部分域名的请求记录显示为“Remote Unknown”，内容完全看不懂。后来发现根源是Chrome走QUIC直连了，没有走Fiddler的TCP代理。

解决办法有两个方向：一是让Chrome禁用QUIC，在浏览器启动参数中添加--disable-quic，或者通过chrome://flags搜索QUIC并禁用；二是在Fiddler设置中启用“Handle CONNECT”相关选项，确保基于TCP的HTTPS请求优先走代理。我这里推荐前者，简单直接，尤其在做接口联调时，我们关心的是HTTP语义本身，QUIC带来的性能优势在这个场景下并不重要。

另一个细节是Chrome对证书信任的校验越来越严格。新版Chrome会对证书的颁发链做完整校验，如果你的Fiddler根证书是老版本生成的，或者签名算法过旧，就可能出现“NET::ERR_CERT_AUTHORITY_INVALID”。解决办法是更新Fiddler到最新版，删除旧证书后重新导出安装，再重启Chrome。

4.4 localhost流量抓取的特殊处理

明明Chrome已经走了代理，为什么访问http://localhost:3000时Fiddler还是什么都没有？这是因为Chrome默认认为localhost是一个可信的本地地址，很多情况下不会把流量提交到代理。

在Fiddler Classic里，一种常规做法是关闭“Filters”面板中的“Use Filters”选项，同时对localhost请求做伪装。最常用的是把访问地址从localhost改为localhost.abc或者本机计算机名的后缀。我在本机调试时，经常把地址写成http://localhost.abc:3000，这样流量就会被判定为普通域名请求，顺利经代理流转。这样做还有一个好处，能避免Chrome的“本地地址不走代理”逻辑干扰测试。

5. 核心实操：过滤、断点、修改与重放

5.1 使用过滤器精简会话列表

配置完成只是第一步，真正提升效率的是筛选。Fiddler默认捕获所有代理流量，某次联调过程中可能同时混着后台上报、CDN资源、统计平台请求，几百条记录翻看非常痛苦。

打开Filters选项卡，勾选Use Filters后，最常用的筛选方式有以下几种：

• Hosts筛选：只显示指定域名的请求。
• URI筛选：在Filter by URI中输入路径关键字，比如/api。
• Response Type筛选：只显示图片、CSS、JS等静态资源或HTML。
• Status Code筛选：只看404、500等异常状态。

举一个具体例子：我要调试login接口，就在Hosts里填写目标域名，在URI里填写/login，这样Fiddler只会留下与该登录接口相关的会话，排查效率直接翻倍。

如果你更喜欢键盘操作，可以看Fiddler底部的QuickExec命令行区域。输入?login，会高亮所有URL中包含login的请求；输入host:baidu.com，则只看百度域名下的会话；输入bpu /login，则对URL中包含/login的请求设置断点。这几个命令我几乎每天都会用到，比鼠标操作快不少。

5.2 断点拦截与请求修改

断点功能是Fiddler最有实战价值的能力之一。它允许在请求发出前、响应返回前暂停数据流转，此时我们可以随意修改请求参数、请求头，甚至可以伪造Cookie。

操作上，选择一条会话，按F11即可对下一个请求设置“请求前断点”。不过更可控的方式是在QuickExec里输入bpu，后面跟关键字。当请求命中后，Fiddler会弹出一个红色的请求编辑器，你可以直接修改Body，然后点“Break on Response”继续，或者点“Run to Completion”放行。

我在实际接口联调中常这样用：前端传的参数与后端签名校验不一致时，先用断点把请求体的timestamp改为与签名一致的时间戳，重新放行，验证后端是否只关心签名不关心实际值。改一次就能省掉反复找后端要测试签名的时间。

同理，响应断点可以用来篡改返回数据。比如在弱网页面调试时，想让某个列表接口返回空数组，就在响应断点里把JSON的data字段改成[]，然后放行，前端页面会根据空数据处理，我们不需要等后端真正的空数据。

5.3 AutoResponder：本地Mock接口

AutoResponder面板相当于“请求重定向器”。勾选Enable rules后，添加一条规则，匹配某个URL或正则，然后指定响应内容，可以是一个文件路径，也可以是一段HTTPS响应字符串。

举个例子，我联调首页时需要验证异常提示文案，但后端接口一时半会儿改不了。于是我在AutoResponder里把/api/home的返回内容替换为一段自定义JSON，其中包含业务异常码和提示信息。前端代码只要判断到该返回，就会弹出对应提示。整个过程不需要后端任何配合。

这个功能还经常用来做“缓存替换测试”。把某个JS文件的响应替换为本地打包后的文件，可以快速验证生产环境页面在未发布该文件时的表现。这里要注意，匹配规则顺序有优先级，越靠上的规则越优先执行，所以要把精确匹配放前面，正则放后面。

5.4 弱网模拟与延迟测试

弱网测试是移动端页面开发中绕不开的环节。Fiddler自带模拟功能，入口在菜单Rules -> Performance -> Simulate Modem Speeds，勾选后模拟的是较慢的调制解调器网络。

这种模拟方式比较粗糙，适合快速验证效果，但不适合精细化控制。如果要精确设置下载带宽、上传带宽和延迟时间，可以通过FiddlerScript来实现。

具体做法是：Rules -> Customize Rules，打开脚本编辑器，在OnBeforeRequest函数里加入延迟逻辑，比如在请求发出前sleep 500毫秒；在OnBeforeResponse里控制响应的延迟和带宽。脚本保存后立即生效，这种方式比切换预设值更贴近真实场景。我在做首屏性能测试时，就把下载延迟调成2秒，观察图片懒加载、骨架屏出现的时机，能发现很多隐藏的交互问题。

5.5 会话保存与重放

抓包文件是可以保存的。选中若干请求记录，按Ctrl + S即可保存为.saz文件。这个文件可以留着后续分析，也可以发给同事复现问题。

重放功能同样隐蔽但强大。选择一条请求，点击工具栏上的Replay按钮，Fiddler会重发一次请求。如果只想重放某个请求，右键选择Replay -> Reissue Requests。我经常用它配合AutoResponder做接口回归验证：把线上环境的关键接口保存下来，本地重放，对比返回内容是否一致，能快速发现因参数缺失导致的接口异常。

5.6 延伸：模拟器与小程序抓包

很多读者抓到“雷电模拟器”“微信小程序”这类关键词，是想把移动端流量也纳入调试。思路和PC端相同：让设备或小程序进程将代理指向电脑的Fiddler。

以雷电模拟器为例，先确保Fiddler开启了Allow remote computers to connect，同时Windows防火墙放行8888端口。然后在模拟器的WLAN设置里，手动设置代理为电脑的局域网IP和8888端口。之后模拟器内的请求就会出现在Fiddler列表中。

小程序抓包稍微不同。微信开发者工具自带“本地调试代理”能力，可以把请求代理到Fiddler；真机调试时，则要保证手机和电脑在同一局域网，手机WiFi代理指向电脑IP。不过需要留意，部分小程序启用了内置的证书校验或整包代理防护，这类流量不会直接走系统代理，需要更高级的Hook方案，这已经超出Fiddler的能力范围。

6. 常见问题与排查技巧实录

6.1 HTTPS会话全是CONNECT隧道，无法查看内容

现象：Fiddler左侧出现大量以“CONNECT”开头的隧道记录，展开后内容空白。

原因排查顺序：

• 检查Tools -> Options -> HTTPS里Decrypt HTTPS traffic是否勾选。
• 检查根证书是否安装到“受信任的根证书颁发机构”。
• 检查Fiddler版本是否太旧，新版Chrome要求的TLS签名校验更严格，老证书可能失效。
• 检查Chrome是否开了QUIC，QUIC流量不进Fiddler的TLS隧道。

按照这个顺序检查完，绝大多数解密问题都能解决。我遇到过的最隐蔽情况是，Fiddler被公司安全软件自动清理了根证书信任状态，重新导入证书后问题立即消失。

6.2 证书明明安装了，Chrome还是报证书错误

有些人安装证书后，访问HTTPS站点被Chrome拦截，地址栏显示NET::ERR_CERT_AUTHORITY_INVALID。这通常有三个原因：证书安装到了“个人”而非“受信任的根证书颁发机构”；系统时间与真实时间偏差过大；Chrome的安全缓存没有刷新。

处理方式是：删除之前的证书，重新导出，手动导入到“本地计算机-受信任的根证书颁发机构”，校正时间，再在chrome://net-internals/#ssl里清除缓存。这里有一个细节，导入时“证书存储位置”应该选“本地计算机”而不是“当前用户”，后者有时在Chrome的沙箱环境中不生效。

6.3 设置代理后所有网页都打不开

代理配置错误时，Chrome会表现为“所有网站都无法访问”。常见情况是Fiddler没有启动，或者监听端口不是8888。

排查方式：先确认Fiddler左下角Capturing是开启状态；再确认端口与Chrome代理设置一致。如果端口被占用，在Connections选项卡中改成其他端口，比如8889，同时更新Chrome代理配置。要注意端口号是三位数以上，不建议用1024以下端口，容易与本机服务冲突。

另一个冷门原因：Fiddler开启了“Use System Proxy”但系统代理被某些软件篡改，导致代理链循环。把连接选项中的“Use System Proxy”勾选状态切换一次即可。

6.4 抓包正常，但Fiddler内存占用越来越高

长时间高频抓包，Fiddler会堆积大量会话记录，内存占用持续上涨，电脑变卡。我会定期清空会话列表：File -> New Session，或者直接按Ctrl + X清空。也可以设置会话自动保存与自动清理，在Tools -> Options -> General里勾选“Save sessions on exit”等选项，但日常调试时手动清空更直观。

另外，Filters面板里的“Use Filters”一旦关闭，所有流量被无条件记录，数量级会非常吓人。建议平时保持过滤状态，比如只抓目标域名和URI，这样内存压力会小很多。

6.5 Fiddler能抓HTTP，但抓不到部分App的HTTPS

App类的HTTPS抓包比浏览器复杂得多。很多App内置了SSL Pinning（证书锁定）机制，它会对比服务端证书是否是预埋的固定证书，Fiddler动态生成的证书会被判定为非法。这种情况下，单纯安装Fiddler根证书没用，需要Hook App的证书校验逻辑，或使用支持SSL Pinning绕过方案的调试框架。这类技术属于安全研究范畴，日常开发中碰到，我通常建议找客户端同事关闭测试环境的证书校验，比逆向折腾的效率高得多。

6.6 安全与合规提醒

最后多说一句。抓包作为调试工具本身是正当技术，但它也意味着你能看到请求中的敏感字段，比如Token、用户ID、内部接口地址。在自己的项目、实验环境、经授权的测试场景中使用完全没有问题，但不要用它去抓取未经授权的流量、窃取他人数据或突破第三方系统的安全机制。这也算一个资深开发者该有的基本分寸。

结尾：一点实操体会

Fiddler配合Chrome的抓包配置，说难不难，说简单也不简单。真正困扰人的从来不是“代理怎么设”“证书怎么装”，而是当流量没有按预期出现时，你能不能快速判断是从哪个环节断掉了。

我个人的习惯是，遇到问题先不急着改配置，而是把链路拆成“浏览器是否走代理”“Fiddler是否解密成功”“目标服务器是否正常响应”三段，每一段用最少的时间验证。抓不到包就去看Chrome代理设置和QUIC开关；抓到但解不开就去查证书信任和版本；解开了但修改无效，再考虑断点和AutoResponder的规则匹配。这套排查思路用时比随便点一顿设置高效得多。

最后再分享一个小技巧：调试结束后，记得把SwitchyOmega切回“直接连接”或关闭系统代理。否则下一次开机时，你可能会发现所有浏览器莫名其妙都打不开网页，而本人已经忘了Fiddler这回事。这不是段子，我至少被坑过三次。