企业官网建设流程全解析

用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发出的每个请求都先经过Fiddler，Fiddler记录、展示、甚至篡改之后，再转发给真实服务器。响应返回时也先经过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抓包是最简单的，三步就能搞定：

1. 启动Fiddler，确认右下角显示Capturing状态（按F12可以开关）。
2. 确认Chrome走的是系统代理，也就是上面说的代理链路没问题。
3. 在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 browsers only，因为如果你的机器上还有其他软件在发HTTPS请求，全解密会把列表搞得很乱。

第二步，安装证书。最简单的办法是在同一个HTTPS设置页里，点击Actions，选择“Trust Root Certificate”。

如果弹出一个“当前用户”还是“本地计算机”的选项，选当前用户就够了。系统会提示“即将在不受信任的证书存储中安装证书”，一路点是即可。

如果你更想手动操作，也可以先选“Export Root Certificate to Desktop”把FiddlerRoot.cer导出到桌面，然后双击证书，选择“将所有证书放入下列存储”，浏览找到“受信任的根证书颁发机构”，确定完成。

第三步，验证证书是否真的被信任。按Win+R输入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，先看清楚现象是哪一类：

这三类问题背后是完全不同的原因，混在一起排查会非常低效。下面按优先级从高到低展开。

4.2 第一类：列表里完全没有目标会话——代理链路没有生效

如果你访问https://www.baidu.com，但Fiddler里连baidu.com的影子都看不到，首先要怀疑的不是证书，而是流量压根没走进来。

按这个顺序排查：

1. Fiddler是否处于Capturing状态？按F12可以切换。状态栏右下角明确写着Capturing才行。我曾经在调试时不小心按到F12，结果列表一动不动，查了半天才发现把采集关掉了。
2. 系统代理是否真的指向Fiddler？用netstat -ano | findstr 8888确认端口监听正常；再检查Chrome设置里的系统代理值，或者干脆在Chrome访问http://127.0.0.1:8888，如果能打开Fiddler的回显页面，说明代理链路至少在这个端口上是通的。
3. 是不是有其他代理工具抢占了系统代理？某些安全软件、下载工具、加速器都会自动修改系统代理。处理方法很简单：把那些软件里“自动配置代理”的功能关掉，或者在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 一个按序排查的速查表，以及我最推荐的复位流程

结合上面三类，我整理了一份我自己排查时实际会用的顺序清单：

1. 确认Fiddler处于Capturing状态，端口8888正常监听
2. 确认Chrome系统代理指向127.0.0.1:8888，未被扩展/软件覆盖
3. 确认“Decrypt HTTPS traffic”已开启，范围选from browsers only
4. 打开certmgr.msc，确认Fiddler根证书在“受信任的根证书颁发机构”
5. 完全关闭Chrome再重启，用无痕窗口访问目标站点
6. 如果遇到证书错误，去chrome://net-internals/#hsts删除对应域名策略
7. 如果还是红叉，重置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，而是安卓模拟器里的应用，甚至真机App，Fiddler稍微换个姿势就行：它不再监听本机回环地址，而是变成一台局域网代理。

先在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再开始干活，从不带着疑问摸黑调试。