用Fiddler抓包Chrome浏览器的HTTP/HTTPS协议流量几乎是每个做Web开发、接口调试、前端联调的人都绕不开的基本功。很多人遇到的问题是Fiddler装好了Chrome也开着HTTP的请求倒是能看到几条一到HTTPS就只剩下一堆“Tunnel to”双击进去什么都看不到或者更彻底浏览器直接给你甩一个证书错误连页面都打不开。这篇文章不打算只教你点哪里而是把从HTTP到HTTPS的完整配置链路、每一步背后的原理、以及我实际踩过的坑都梳理清楚。只要读完照着做一遍你不仅能正常抓到Chrome的明文HTTP请求还能把HTTPS解密配置做到一次成功并且在以后遇到“抓不到包”时能自己按逻辑一步步排查而不是到处找教程。1. 先搞清楚Fiddler和Chrome的分工代理链路决定成败1.1 Fiddler本质上是一个代理服务器不是浏览器插件很多人第一次接触Fiddler时会下意识地以为它和Chrome DevTools差不多是什么“浏览器调试工具”。这个误解会直接导致后面所有配置全都看不太懂。实际上Fiddler是一个独立的HTTP/HTTPS代理服务器它监听在你本机的一个端口上默认是8888然后等着浏览器、App、桌面程序把流量送过来。它的官方定位从来都是“web debugging proxy”而不是“Chrome插件”。链条是这样的Chrome - Fiddler(127.0.0.1:8888) - 目标服务器 Fiddler(127.0.0.1:8888) - 目标服务器Chrome发出的每个请求都先经过FiddlerFiddler记录、展示、甚至篡改之后再转发给真实服务器。响应返回时也先经过Fiddler然后再送回Chrome。所以Fiddler能看到双向完整数据。理解了这一点你就会明白一个关键结论要让Chrome流量被Fiddler抓到唯一条件是“Chrome的所有请求都走127.0.0.1:8888这个代理”没有第二条路。1.2 Chrome的代理来源系统代理与代理覆盖工具Chrome在Windows上默认遵循系统代理设置也就是我们在“Internet选项”里看到的那一套“局域网设置”。这套代理是WinINET层面的全系统通用。Fiddler启动之后会自动尝试把系统代理设置为127.0.0.1:8888。也就是说正常情况下你根本不用手动去设置Chrome——只要Fiddler开着Chrome流量就会自动流过去。这也是为什么很多人明明什么都没配打开Fiddler也能抓到东西。但这里有一个很常见的干扰源代理覆盖工具。如果你装了SwitchyOmega之类的代理切换扩展或者某些安全软件自带的代理管理功能它会覆盖系统代理把流量指到别的地方。这时候Fiddler就成“睁眼瞎”了怎么刷新页面都看不到新会话。所以配置前的第一步自查是在Chrome地址栏访问chrome://settings/system确认“打开您计算机的代理设置”指向的是127.0.0.1和Fiddler端口如果你用了代理切换扩展请把扩展里的HTTP代理也手动改成127.0.0.1:8888或者暂时禁用扩展。1.3 一个最容易被误解的“监听端口”概念Fiddler右下角状态栏会显示一行字Listening on 127.0.0.1 port 8888。这个端口号是可以改的并不是永远固定。为什么要强调这一点因为我见过太多人按照教程写死8888结果自己机器上Fiddler换成了8889端口或者8888被别的程序占了Fiddler自动改端口但Chrome还傻傻地往8888上发请求结果页面全部“代理服务器拒绝连接”。自查命令很简单在命令行里执行netstat -ano | findstr 8888如果能看到监听在127.0.0.1:8888的进程那就说明Fiddler在这个端口上工作正常。如果什么都查不到去Tools - Options - Connections里看“Fiddler listens on port”到底是什么值然后把系统代理改成对应的端口。2. 抓HTTP协议流量代理配对成功就能跑通最常踩的坑有两个2.1 三步完成HTTP流量抓取HTTP协议本身没有加密代理只需要做“转发记录”就能看到全部内容不需要安装任何证书。所以HTTP抓包是最简单的三步就能搞定启动Fiddler确认右下角显示Capturing状态按F12可以开关。确认Chrome走的是系统代理也就是上面说的代理链路没问题。在Chrome里随便访问一个HTTP站点比如http://httpbin.org/get然后回到Fiddler看会话列表。正常你会看到一条新的会话记录双击打开上方是Request下方是Response完整的URL、请求头、请求体、响应体都在。这里有个细节值得单独说Chrome访问http://站点时发到代理的是普通的GET /get HTTP/1.1请求而访问https://站点时发到代理的是CONNECT hostname:443请求。你在Fiddler里看到Tunnel to hostname:443说明这是HTTPS流量尚未解密。2.2 “对于本地地址不使用代理”这个复选框是本地调试的第一个坑很多人会卡在一个非常诡异的现象上外部网站全部抓得到唯独localhost:8080、127.0.0.1:3000这种本地服务Fiddler列表里一条都没有。问题往往出在Windows代理设置里的一个默认勾选项“对于本地地址不使用代理服务器”。它的本意是让浏览器访问本机或者局域网地址时绕过代理直接连接减少不必要的转发。但Fiddler作为代理恰恰就死在这个“绕过”上——流量根本没经过它自然什么也看不到。解决办法很粗暴在“局域网(LAN)设置”里把“对于本地地址不使用代理服务器(B)”的勾去掉或者在代理设置的高级模式里把localhost;127.0.0.1;从“请勿对以下列条目使用代理服务器”的列表里删掉。顺带一提本地开发时你用http://localhost:3000访问前端项目如果这个勾选还在前端发到后端接口的请求你就永远无法在Fiddler里看到。我第一次带新人联调时对方折腾了半小时就是不知道这一点后来把勾去掉立刻满屏会话。2.3 会话列表太吵用过滤器把无关流量挡在门外Chrome一打开后台会有几十个并发请求扩展程序、预加载、统计上报、静态资源……Fiddler默认会把它们全部显示出来你找目标请求就像在菜市场里找一个人。我的习惯是一开始就开过滤器。左下角有个Filters页签勾选“Use Filters”在Hosts那一栏选择“Show only the following hosts”然后填目标域名比如httpbin.org。这样会话列表里只会留下这个域名的流量。Fiddler左下角的黑色输入栏叫QuickExec平时我基本靠几个命令做快速筛选?keyword只显示URL里包含keyword的会话POST只看POST请求200只看响应码为200的会话404只看404的会话clear清空列表这些命令看起来不起眼但联调的时候效率提升非常明显。3. 抓HTTPS协议流量核心不是开关而是证书五步配好完整解密3.1 HTTPS为什么不能像HTTP一样直接看明文HTTPS和HTTP的最根本区别在于HTTP是明文传输代理看一眼就知道你发了什么HTTPS在TCP之上又加了一层TLS加密传输的内容全部是被加密过的代理只能看到目标地址域名和端口看不到具体URL、请求头、请求体。所以当你只抓没解密Fiddler里会看到Tunnel to example.com:443这样的会话双击进去只有一句话这个连接是加密的。想看明文你得让Fiddler“解密”。解密原理说白了是中间人代理Fiddler自己生成一个根证书然后把它安装到你的操作系统“受信任的根证书颁发机构”列表里。之后每次你访问新域名Fiddler就用这个根证书临时签一个该域名的“假证书”返回给Chrome。Chrome一看这个假证书的签发者是受信任的根证书链路验证通过于是正常运行。而在Fiddler这一侧它再和真正的服务器做一次标准的TLS握手拿到真正的明文内容。这样一边是Chrome信任Fiddler假证书一边是Fiddler与真实服务器正常通信中间的数据就被完整解出来了。一个很形象但不严谨的类比HTTP是送快递不拆封代理看一眼箱子上的标签就行HTTPS是箱子加了密码锁Fiddler想检查内容就先复制了一把“万能钥匙”根证书把锁打开看完再原样锁上。3.2 五步完成HTTPS解密配置第一步打开Tools - Options - HTTPS勾选“Capture HTTPS CONNECTS”和“Decrypt HTTPS traffic”。勾选之后下面会出现一个下拉选项三个值选项含义适用场景from all processes解密所有进程的HTTPS流量需要抓全局时from browsers only只解密浏览器流量平时首选噪音最小from non-browsers only只解密非浏览器流量抓特定客户端时使用我平时选from browsers only因为如果你的机器上还有其他软件在发HTTPS请求全解密会把列表搞得很乱。第二步安装证书。最简单的办法是在同一个HTTPS设置页里点击Actions选择“Trust Root Certificate”。如果弹出一个“当前用户”还是“本地计算机”的选项选当前用户就够了。系统会提示“即将在不受信任的证书存储中安装证书”一路点是即可。如果你更想手动操作也可以先选“Export Root Certificate to Desktop”把FiddlerRoot.cer导出到桌面然后双击证书选择“将所有证书放入下列存储”浏览找到“受信任的根证书颁发机构”确定完成。第三步验证证书是否真的被信任。按WinR输入certmgr.msc打开证书管理器展开“受信任的根证书颁发机构 - 证书”按颁发者排序应该能看到DO_NOT_TRUST_FiddlerRoot或类似的条目。如果看不到说明上一步没装到位。第四步完全关闭Chrome再重新打开。这一步很多人会漏结果配置完发现还是打不开HTTPS页面。因为Chrome可能还在使用之前缓存的证书校验结果重启后就正常了。第五步验证解密是否生效。在Chrome访问任意HTTPS网站比如https://www.baidu.com回到Fiddler双击该会话。如果Inspectors里能看到明文HTML、JS或者JSON说明解密成功。会话列表里每个HTTPS会话前面也会出现一个绿色的锁形图标代表“已解密”。3.3 证书装好之后如何验证是真的解开了光看会话列表有内容还不够我推荐做一次“对比验证”用一个你能明确预期内容的请求来验证比如访问https://httpbin.org/get它返回的JSON里带了你请求时的headers和参数。如果在Fiddler的响应面板里能看到这段JSON的明文内容那就百分之百说明解密链路是通的。另一个快速判断方法是看图标的颜色会话前有绿色锁该HTTPS流量已经被Fiddler成功解密会话前有灰色锁或“Tunnel”只建立了隧道内容未解密多半是没勾解密选项或该站点不在解密范围会话前面是红色错误图标TLS握手过程中出了问题通常是证书过期、系统时间错误、或客户端校验太严格3.4 从“Trust Root Certificate”到“Reset All Certificates”证书生命周期管理这里必须提一个很多人不知道的坑Fiddler Classic在安装时生成的根证书是有有效期的通常是一年。一旦过期Chrome访问所有HTTPS站点都会报NET::ERR_CERT_DATE_INVALID但Fiddler的界面看起来一切正常很多人会误以为是目标网站坏了。我遇到过不止一次这种情况半夜上线前联调突然所有HTTPS页面都打不开排了半天发现是Fiddler根证书过期。处理方法是回到HTTPS设置页在Actions里选择“Reset All Certificates”。这会把旧的根证书从系统里删掉并重新生成一个新的然后你需要再次执行Trust Root Certificate重启Chrome。所以我的建议是每次系统时间有大变动或者Chrome突然大面积报证书错误优先怀疑Fiddler证书。与其排查一小时不如直接重置证书两分钟搞定。4. HTTPS抓包翻车现场复盘从空列表到一片红的完整排查链路4.1 先把故障画面分成三类避免瞎猜遇到“抓不到HTTPS包”不要上来就重装Fiddler先看清楚现象是哪一类现象大概率原因会话列表里根本没出现目标域名流量根本没经过代理链路问题有Tunnel会话但双击没明文解密未生效、证书信任问题、HSTS拦截会话有内容但请求/响应是红色的TLS握手失败、证书固定、协议版本问题这三类问题背后是完全不同的原因混在一起排查会非常低效。下面按优先级从高到低展开。4.2 第一类列表里完全没有目标会话——代理链路没有生效如果你访问https://www.baidu.com但Fiddler里连baidu.com的影子都看不到首先要怀疑的不是证书而是流量压根没走进来。按这个顺序排查Fiddler是否处于Capturing状态按F12可以切换。状态栏右下角明确写着Capturing才行。我曾经在调试时不小心按到F12结果列表一动不动查了半天才发现把采集关掉了。系统代理是否真的指向Fiddler用netstat -ano | findstr 8888确认端口监听正常再检查Chrome设置里的系统代理值或者干脆在Chrome访问http://127.0.0.1:8888如果能打开Fiddler的回显页面说明代理链路至少在这个端口上是通的。是不是有其他代理工具抢占了系统代理某些安全软件、下载工具、加速器都会自动修改系统代理。处理方法很简单把那些软件里“自动配置代理”的功能关掉或者在Fiddler的Tools - Options - Connections里开启“Act as system proxy on startup”然后重启Fiddler。还有一种情况你访问的是localhost上的HTTPS服务。Chrome对本地地址走代理的策略和普通站点不完全一样加上之前说的“本地地址不使用代理”勾选双重因素下本地HTTPS请求很容易被跳过。配置方法仍然是把那个绕过选项取消。4.3 第二类只有Tunnel没有明文证书、HSTS与Chrome缓存这一类的典型表现是会话列表里有Tunnel to www.baidu.com:443双击进去却只有一句话看不到任何HTTP报文。首先检查Fiddler的HTTPS设置页确认“Decrypt HTTPS traffic”处于勾选状态。如果没勾立刻勾上重启Fiddler再看效果。如果已经勾了但还是看不到明文最常见的原因就是证书信任出了问题。你在Chrome里如果能看到NET::ERR_CERT_AUTHORITY_INVALID这样的红色警告页说明Chrome不认Fiddler签发的证书。解决方式是回到证书管理器确认Fiddler的根证书真的在“受信任的根证书颁发机构”里而不是“个人”或“中间证书颁发机构”。如果位置错了删掉重新装一次。接下来是HSTS。这个坑隐蔽很多。某些网站通过Strict-Transport-Security响应头告知浏览器“以后只准用HTTPS访问我”或者域名进了Chrome内置的HSTS预加载列表。Chrome一旦记住这个策略即便你只是想调试一下它也会在建立连接之前强制跳HTTPS甚至可能直接拦截不受信任的中间人证书。处理方式在Chrome地址栏打开chrome://net-internals/#hsts在“Delete domain security policies”里输入出问题的域名点Delete删除HSTS策略然后重启Chrome试试。最后还有一个很容易忽略的Chrome缓存。即使解密配置完全正常第二次访问同一个URL时Chrome可能直接命中缓存不再发出网络请求Fiddler自然没有新会话。这不算故障我通常会开一个无痕窗口做抓包测试避免缓存干扰。4.4 第三类浏览器正常访问但Fiddler会话红成一片TLS版本与证书固定浏览器能打开页面说明真实证书链路没问题但Fiddler里的HTTPS会话一片红说明中间人这条链路上出了差错。最常见原因是TLS版本不兼容。Fiddler Classic对非常新的TLS配置可能存在兼容性问题。在Tools - Options - HTTPS里可以点Protocols...按钮调整允许的TLS版本勾选较新的TLS1.2/TLS1.3。如果站点强制TLS1.3而Fiddler默认列表里没有握手就会失败。另一类是证书固定Certificate Pinning多见于移动App、客户端程序Chrome浏览器里相对少见Chrome已经放弃了HPKP机制但部分自研内核、WebView还是可能用到。证书固定的意思是客户端内置了服务器证书的公钥指纹只信任这个指纹其他证书一概拒收。Fiddler签发的假证书再正规指纹对不上也是白搭。表现是浏览器能正常访问但Fiddler会话里全是握手失败的错误或者请求根本没有经过Fiddler解密。遇到这种场景别死磕Fiddler要么在测试环境关闭固定校验要么换用支持证书固定绕过能力的更底层方案。4.5 一个按序排查的速查表以及我最推荐的复位流程结合上面三类我整理了一份我自己排查时实际会用的顺序清单确认Fiddler处于Capturing状态端口8888正常监听确认Chrome系统代理指向127.0.0.1:8888未被扩展/软件覆盖确认“Decrypt HTTPS traffic”已开启范围选from browsers only打开certmgr.msc确认Fiddler根证书在“受信任的根证书颁发机构”完全关闭Chrome再重启用无痕窗口访问目标站点如果遇到证书错误去chrome://net-internals/#hsts删除对应域名策略如果还是红叉重置Fiddler证书Reset All Certificates重新信任重启Chrome这条链路几乎覆盖了所有我遇到的HTTPS抓包问题。如果你按完第7步还不行才需要考虑TLS版本、证书固定这类更边缘的因素。5. 流量拿到手的玩法断点篡改、弱网模拟、模拟器与小程序抓包5.1 用断点和重放把“观察者”变成“干涉者”抓包只是第一步真正提升联调效率的是“动手改包”。Fiddler的QuickExec栏输入断点命令即可拦截请求bpu /api/login拦截URL中包含/api/login的请求修改后放行bpafter /api/user拦截响应可在服务器返回前修改响应体bps 500拦截所有状态码为500的响应不带参数直接输入bpu会清空旧断点我实际用到最多的场景是前后端联调时期后端说某个接口一定会返回正确数据前端说页面上就是不显示。这时候我在Fiddler里把响应体手动改成一个预期值如果前端立即正常显示说明问题出在后端或者数据格式上如果前端还是无反应那就是前端的逻辑问题。几分钟就能把锅甩明白。重放接口也很实用把一个请求右键选择“Replay - Reissue”Fiddler会用一模一样的参数重新发一次请求。改参数的话把它拖到Composer选项卡里修改或者直接在Inspectors里编辑Request再发出。5.2 弱网测试的精调两条trickle-delay命令走天下Fiddler自带了模拟弱网的功能Rules - Performances - Simulate Modem Speeds点击后所有请求会被人为加上约300ms延迟和较慢的带宽。但很多人不知道的是这个开关是全局生效的而且延迟值固定。想要精确控制延迟打开Rules - Customize Rules会看到FiddlerScript脚本编辑器。在onBeforeRequest函数里加一行if (m_SimulateModem) { oSession[request-trickle-delay] 2000; }在onBeforeResponse函数里加if (m_SimulateModem) { oSession[response-trickle-delay] 2000; }单位是毫秒。上面这两段的意思是当Simulate Modem Speeds开关打开时请求发出前延迟2秒响应返回前再延迟2秒。实测下来这个效果对排查接口超时、loading状态展示、弱网下的重试逻辑都非常直观。如果你不想全部请求都延迟还可以加上一个域名判断比如if (oSession.HostnameIs(api.example.com) m_SimulateModem) { oSession[response-trickle-delay] 3000; }只对特定接口做延迟其他请求不受影响。5.3 模拟器和真机抓包Fiddler从本机走向局域网如果你要抓的不是Chrome而是安卓模拟器里的应用甚至真机AppFiddler稍微换个姿势就行它不再监听本机回环地址而是变成一台局域网代理。先在Fiddler的Tools - Options - Connections里勾选“Allow remote computers to connect”。注意这里会提示你Fiddler不能和系统代理同时使用一般选允许。然后Windows防火墙需要放行8888端口否则模拟器内部访问不到宿主机的代理。本机IP地址用ipconfig查通常类似192.168.x.x。模拟器或者真机的WiFi代理设置为代理主机宿主机IP 代理端口8888代理生效后打开模拟器自带的浏览器访问http://宿主机IP:8888页面上有Fiddler的证书下载链接默认是http://宿主机IP:8888/FiddlerRoot.cer下载并安装证书。这里有一个关键差异必须提Android 7及以上系统普通App默认只信任系统证书你手动安装的“用户证书”对大多数App是不生效的。换句话说浏览器流量能解出来但App里的HTTPS仍然是一堆Tunnel。雷电模拟器这类可Root环境下的解决办法是用Root权限把Fiddler证书改名为系统证书移动到/system/etc/security/cacerts/目录设置644权限后重启。具体做法是用openssl计算证书哈希openssl x509 -inform PEM -subject_hash_old -in FiddlerRoot.pem -noout输出的哈希值就是文件名把pem证书改名为哈希.0再push到系统证书目录。做完这一步大部分App的HTTPS流量都能正常解开了。5.4 小程序和WebView流量的抓包思路小程序的流量本质上就是WebView的流量走的是微信或其他宿主App内部的网络栈。在模拟器里只要模拟器的全局代理设置正确微信运行在模拟器内部它的网络请求也会走代理顺势就能抓到。实际过程中需要注意两点第一微信等App在某些版本可能不走系统代理这时候你可以借助进程代理工具强制把微信的TCP连接转发到Fiddler端口第二小程序里的性能上报、接口请求往往带有大量并发和缓存要在Fiddler里过滤出目标域名或者直接用QuickExec输入?号加关键字快速定位。我个人的建议是只对你自己开发、或者有明确测试授权的小程序做这种调试。抓包工具本身是中性技术但使用边界一定要清楚别在未授权场景下乱试。最后补一句实战体会这几套配置和排查链路我在小团队、个人项目里反反复复用了很多年带新人时也基本是把上面内容过一遍。实际情况中最多人倒下的地方就三处本地地址绕过代理、Fiddler根证书过期、以及忘了重启Chrome。你如果配完之后还是抓不到包先别急着重装Fiddler老老实实按第四章的顺序从头过一遍绝大多数问题都能在十分钟内定位。最后再分享一个小习惯我每次换机器后配置Fiddler都会在配完证书后立刻访问一次https://httpbin.org/get做验证看到明文JSON再开始干活从不带着疑问摸黑调试。
