今天这篇聊聊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把内容加密后交给CC用自己的钥匙打开看再换成真正的钥匙重新加密发给B。只要信任链建立起来解密就变得顺理成章。关键点在于这种“中间人”能力完全依赖浏览器对根证书的信任。一旦证书安装的位置不对、信任级别不够或者证书过期浏览器就会立刻报警HTTPS抓包也就宣告失败。2.3 Fiddler的工作流程概览一次完整的抓包流程可以梳理为如下几步Chrome的请求依据代理设置发送到Fiddler的监听端口。若是HTTPS请求Fiddler先检查目标域名是否已生成过证书没有则即时生成并用根证书签名。Chrome验证证书有效后与Fiddler建立TLS连接。Fiddler解密请求内容同时向目标服务器发起真实请求。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请求显示为httpHTTPS请求显示为https。如果HTTPS请求那一行前面带一个锁形图标说明Fiddler已经成功解密点开Inspectors可以看到完整的请求体和响应体。如果只看到一条隧道记录且无法展开内容大概率是证书或解密开关没弄好。举个实战例子我访问https://www.baidu.comFiddler里应该出现一条主机名为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是否开了QUICQUIC流量不进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的HTTPSApp类的HTTPS抓包比浏览器复杂得多。很多App内置了SSL Pinning证书锁定机制它会对比服务端证书是否是预埋的固定证书Fiddler动态生成的证书会被判定为非法。这种情况下单纯安装Fiddler根证书没用需要Hook App的证书校验逻辑或使用支持SSL Pinning绕过方案的调试框架。这类技术属于安全研究范畴日常开发中碰到我通常建议找客户端同事关闭测试环境的证书校验比逆向折腾的效率高得多。6.6 安全与合规提醒最后多说一句。抓包作为调试工具本身是正当技术但它也意味着你能看到请求中的敏感字段比如Token、用户ID、内部接口地址。在自己的项目、实验环境、经授权的测试场景中使用完全没有问题但不要用它去抓取未经授权的流量、窃取他人数据或突破第三方系统的安全机制。这也算一个资深开发者该有的基本分寸。结尾一点实操体会Fiddler配合Chrome的抓包配置说难不难说简单也不简单。真正困扰人的从来不是“代理怎么设”“证书怎么装”而是当流量没有按预期出现时你能不能快速判断是从哪个环节断掉了。我个人的习惯是遇到问题先不急着改配置而是把链路拆成“浏览器是否走代理”“Fiddler是否解密成功”“目标服务器是否正常响应”三段每一段用最少的时间验证。抓不到包就去看Chrome代理设置和QUIC开关抓到但解不开就去查证书信任和版本解开了但修改无效再考虑断点和AutoResponder的规则匹配。这套排查思路用时比随便点一顿设置高效得多。最后再分享一个小技巧调试结束后记得把SwitchyOmega切回“直接连接”或关闭系统代理。否则下一次开机时你可能会发现所有浏览器莫名其妙都打不开网页而本人已经忘了Fiddler这回事。这不是段子我至少被坑过三次。
