入行这些年的一个真实经历前端同学信誓旦旦说页面没发请求后端同学说接口根本没收到我跑到工位上一看两边都能理直气壮谁也说服不了谁。最后我打开Fiddler抓包工具把手机、浏览器流量挂上代理十分钟内就发现是测试环境域名被缓存劫持到了旧网关请求压根没到后端。这种场景你大概率也遇到过——程序员的日常一半时间在写代码另一半时间在证明“不是我的锅”。Fiddler抓包工具就是把这个“证明”过程变得可视化、可操作、可复现的工具。无论你是前端、后端、测试还是运维只要你的工作和 HTTP/HTTPS 接口沾边Fiddler 都能帮你看到浏览器和手机 App 背后最真实的流量。它能看请求头、响应体、状态码、耗时、Cookie、重定向链能断点篡改数据、能 Mock 接口、能保存会话做回归对比。这篇文章不打算给你罗列菜单而是按我实际使用的路径把从安装到进阶的流程、原理和踩坑经验一次性讲透让你能照着操作也能在出问题时知道去哪个设置里找原因。1. 从零跑通第一次抓包先弄清Fiddler在干什么1.1 代理是怎么一回事Fiddler 本质上是一个本地代理服务器。你在浏览器或手机里设置代理地址为电脑 IP 加 8888 端口后所有HTTP/HTTPS请求都会先经过Fiddler再由它转发给目标服务器。服务器返回的数据也会先回到Fiddler再交还给你。所以“抓包”并不是偷看而是让流量主动绕道经过一个可以记录和修改的中间点。这个机制的关键是“中间人”。你可以把它想象成快递员正常情况下你的包裹直接由商家发到你手上中间人模式下包裹先送到中转站中转站拆开检查、登记、甚至换掉里面的商品再重新封好发给你。Fiddler 就是那个中转站。它拆包的依据就是你的代理设置这个设置只对当前配置的客户端生效并不会影响其他设备。理解了这一点排查问题就顺了。比如网页能打开但Fiddler看不到任何会话先别怀疑软件坏了99%的情况是代理没有生效。Chrome 等浏览器如果要走系统代理需要确认启动参数没有被改或者插件强制了直连手机端则要确认代理 IP 和端口填对了并且电脑防火墙放行了 8888。这些都是新手最容易卡住的地方。1.2 安装与初始配置安装 Fiddler 没什么门槛一路默认即可。我第一次装完就急着抓 HTTPS结果发现全是“Tunnel to ...”明文字段一概看不到后来才知道还差两步开启解密开关和安装证书。在你拿到一个旧版本时这两个入口通常藏在 Tools Options HTTPS 里勾选“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”然后按提示安装根证书。初始配置里还有一个高频坑默认只捕获浏览器流量不捕获系统服务或其他进程。新版入口可能在“WinConfig”或“System Proxy”相关位置你要确认“Capture Traffic”处于开启状态同时把 System Proxy 打开否则代理没挂到系统上什么都看不到。建议安装完先做一次最小验证打开 Fiddler重启浏览器访问任意网站看会话列表有没有出现记录。有记录说明代理链路已经通了后面再逐步增加 HTTPS、手机端等能力。注意安装证书后操作系统会信任 Fiddler 生成的根证书。不用时建议关闭解密开关或移除证书避免在公用环境留下不必要的信任风险。1.3 第一个抓包实例观察请求从哪里来到哪里去跑通代理之后我建议你先别急着看细节而是用 Fiddler 自带的功能看一遍“请求生命周期”。随便访问一个测试站点点中会话列表里的一条请求右边 Inspector 面板里能看到请求行、请求头、请求体再点响应区域能看到状态行、响应头、响应体。这里最关键的不是看懂每个字段而是建立“一对多”的感觉——你访问一个页面往往会产生几十个请求真正想要的 HTML 只是其中一条其他是图片、脚本、样式、统计上报。你可以立即体验过滤的必要性。在左下角 QuickExec 输入框输入?ts就只显示 URL 里带“ts”的请求输入302只显示 302 状态码输入host:example.com只看某个域名的流量。这些过滤不是高深技术但它们决定了你能不能快速锁定目标。我见过很多新人把几屏请求从头翻到尾十分钟找不到接口我过去敲一个?api/列表瞬间干净。工具的熟练程度很多时候就体现在这些不起眼的操作上。2. 看懂会话流识破每一次请求的“底细”2.1 会话列表字段的潜台词Fiddler 的会话列表Web Sessions默认显示 Result、Protocol、Host、URL、Body、Caching、Content-Type 等字段。很多人只看 URL 和 Result其实前几列的信息量被严重低估。Protocol 是 HTTP/1.1 还是 HTTP/2直接决定你后面分析连接复用和队头阻塞的方向。Caching 列的no-cache说明资源每次都要回源校验private说明只能本地私有缓存这对排查“页面更新了但客户端还是显示旧数据”至关重要。状态码也是很有讲究的。200 不是唯一正常的答案304 表示缓存有效服务器没有重新返回内容这通常不是错误302 后面一定还有一个跳转后的请求如果你只看到 302 没看到后续可能是 Location 头被拦截或客户端没有跟随跳转。404、500 大家都会看但容易被忽略的是 401 和 403前者是没登录后者是登录了但没权限排查时思路完全不同。我自己的习惯是点中一个会话按F12打开 Inspector然后从头到尾读一遍请求头和响应头。大部分问题藏在细节里Host 是不是预期域名Content-Type 是不是表单Origin 和 Referer 是否被服务端校验Cookie 传递是否完整Set-Cookie 的 Domain 和 Secure 标志是否设置正确。这些字段单个看都认识组合在一起才构成完整的请求语境。2.2 请求与响应在Inspectors里的对应关系右侧 Inspector 上半部分是请求下半部分是响应默认以分类视图显示但更推荐你用 Raw 视图。Raw 视图能看到完整的原始报文包括首部顺序和不可见字符比如请求体末尾没有换行符、响应头里有多余的空格这类问题只在原始报文里能发现。具体操作是选中会话点击右侧上方的“Raw”标签你能看到类似下面的结构GET /api/users?a1 HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: */*下面空一行然后是请求体。响应则显示状态行、响应头、空行、响应体。这个结构是 HTTP 协议的基础Fiddler 只不过把它可视化。我常让同事做一个练习不看 Fiddler 的分类视图只看 Raw 报文尝试说清楚这个请求的 Content-Length 和实际请求体长度是否一致。这个练习做完再看抓包数据就不再发怵了。2.3 状态码与耗时快速定位异常的三个指标除了状态码你还应该盯三个时间指标DNS 解析时间、TCP 连接时间、请求响应总时长。Fiddler 在 Statistics 面板会给出性能数据比如“Request count”“Total bytes sent”“Duration”。定位慢接口时先看总时长然后在时间线Timeline里看是哪个阶段拖了后腿。如果 DNS 就花了 3 秒那和接口本身没关系是本地 DNS 配置的问题如果 TTFB 很长但接收字节很快那就是服务端处理逻辑慢可以腾出手去查数据库或者远程调用。典型场景是 WebSocket 连接无法建立。此时会话列表出现的是 101 状态码这不算错误表示协议切换成功。如果抓包看到 101 之后马上断开重点看响应头里的 Sec-WebSocket-Accept 是否正确、代理是否对 Upgrade 头做了拦截。Fiddler 默认能处理这类流量但如果你开了某些过滤规则把头部改了就容易破坏握手。3. HTTPS流量解密证书的安装与信任链逻辑3.1 为什么默认抓不到HTTPS明文HTTPS 的“S”代表安全套接层它让传输内容加密第三方即使截获数据包也读不出明文。Fiddler 想看到明文必须把自己变成客户端信任的“合法”服务器。做法是Fiddler 生成一个根证书客户端安装并信任这个根证书后Fiddler 再为每个访问域名临时签发一张子证书从而完成对目标服务器的“李代桃僵”。你可能担心这是不是有风险。公平地说任何中间人代理方案都有信任风险Fiddler 只是在调试场景下让你主动选择信任它。个人测试自己的应用完全没问题前提是你清楚自己在做什么并且不要在他人不知情的情况下截取其设备流量。这里设置边界很重要安装证书的设备必须是你的设备目标系统必须是你有权限调试的系统。安全边界抓包工具不能用来获取别人账号信息、绕过他人授权或入侵不属于你的系统。它只是一个调试工具用途应当在合法授权范围内。3.2 电脑端证书安装与信任第一次开启解密时Fiddler 会在“HTTPS”设置页生成DO_NOT_TRUST_FiddlerRoot这样的根证书。在电脑上安装时务必通过系统证书管理入口导入到“受信任的根证书颁发机构”不要只导入到“个人”证书。装错位置的典型症状是浏览器打开提示证书错误但 Fiddler 会话里又确实有流量。因为中间人证书不被信任客户端就会在 TLS 握手阶段拒绝连接。安装完成后建议先重启 Fiddler 和浏览器再访问一个启用 HTTPS 的站点。如果看到 URL 前面带锁会话列表里也不再是Tunnel to而是具体的GET请求说明解密成功。若仍然只能看到 CONNECT 隧道请依次检查解密开关是否勾选证书是否在受信任根列表浏览器是否启用了“安全 DNS”或“跳过本地代理”等干扰设置。3.3 移动端证书安装与授权设置手机端抓包比电脑端麻烦但逻辑相同手机要连电脑的代理同时要安装并信任 Fiddler 的根证书。证书传递一般有两种方式一是通过手机浏览器访问http://电脑IP:8888下载证书二是把FiddlerRoot.cer通过文件传输工具传到手机再点击安装。安装后还有一步容易漏不同系统的信任机制不一样有些需要在“证书信任设置”里为 Fiddler 根证书开启完全信任有些需要把它加入系统证书存储区。如果你只做了安装没有信任Chrome 类浏览器可能仍然拒绝连接原生 App 则可能直接忽略证书。我见过很多人卡在“证书装了但 App 依然超时”这一步其实就是没去“信任证书”设置里手动打开开关。还有一点移动端 App 可能使用了证书绑定Certificate Pinning也就是客户端内置固定了服务器证书指纹。这种情况下即使安装了根证书App 也不会认 Fiddler 动态签发的证书表现为页面直接无法打开或者报证书错误。这并不是你配置错了而是应用刻意防代理。常规调试遇到这种情况需要优先确认自己是否有权修改该应用或该设备否则不要轻易尝试绕过。3.4 解密规则的开启与核对默认情况下Fiddler 可以对所有 HTTPS 会话解密。为了性能和管理方便你可以在解密设置里添加例外规则比如只解密example.com或者排除所有指向某个 IP 的流量。规则写的是通配符路径用错了会影响匹配范围我见过有人写*facebook*结果该域名下的所有子域都被解密列表刷到卡顿。每次改完解密规则记得清空一次会话列表CtrlX再重新验证。因为旧会话里已经记录了未解密或已解密的报文不清理的话你会误以为规则没生效。另外一个高频操作是“记住客服端证书”如果你在做双向 TLS 验证的调试需要额外配置客户端证书这个功能在解密选项里很少人用但遇到银行类接口调试时就是刚需。4. 断点与篡改让流量“中途停车”改数据4.1 断点机制的触发原理Fiddler 的断点分为“请求前断点”和“响应前断点”。请求前断点发生在客户端请求发出后、Fiddler 转发到服务器前此时你可以修改请求头、请求体、URL 参数响应前断点发生在服务器响应已返回、Fiddler 交还给客户端之前此时你可以修改响应状态码、响应头和响应体。这两类断点相互独立可以同时开启。最简单的开启方式是在 Fiddler 菜单选择 Rules Automatic Breakpoints勾选“Before Requests”或“After Responses”。更灵活的方式是结合 QuickExec 命令比如输入bpu example.com只有匹配该地址的请求才断点输入bpa响应断点bps状态码断点。这种精准断点非常适合只拦截一条接口其他流量正常放行。4.2 修改请求头与请求体模拟不同客户端修改请求头最常用的场景是伪装 User-Agent 或改造参数版本。比如你测试现网环境没有 Android 类客户端入口但服务端逻辑区分端别你就可以把抓到的请求复制到 Composer修改 User-Agent 后重放观察返回差异。操作路径是右键会话 Add to Composer然后在底部的 Composer 面板里编辑头部。注意 Fiddler 的 Composer 默认可能带Content-Length你修改请求体之后要手动更新长度或让 Fiddler 自动重算否则服务器会因长度不匹配而拒绝请求。请求体的修改比头部更简单直接在 WebForms 或 Raw 面板里改字段再“Breakpoint”放行。这里有个细节如果你修改的是 JSON 格式 body建议在 Text 视图里改改完确认一下 JSON 合法。曾经有人把响应里的status从success改成success多打了一个空格导致前端 JSON.parse 直接抛异常而他还以为是前后端 bug。4.3 修改响应体制造前端临界场景前端调试空状态、错误状态、超长列表时最讨厌的就是等后端造数据。响应前断点可以让你直接把后端返回改掉。比如你想模拟一个 500 错误就在响应前断点点中会话修改状态行为 500再把响应体换成自定义错误 JSON然后放行。客户端看到的就和真实故障一模一样。我更常用的场景是超时和无响应开启响应前断点后不点击“放行”而是把会话一直挂在那里观察前端是否会走超时逻辑。这比单纯改状态码更贴近真实弱网环境。还有一种玩法是修改响应头里的 Cache-Control把no-cache改成max-age3600验证前端命中缓存后是不是不再发请求。这些操作虽然简单但能让后端还没开发完成时前端就能按约定字段开发界面。4.4 断点模式下容易翻车的地方断点最坑人的点是“忘了放行”。开了一堆自动断点后你在页面上点了十几次刷新每次都停在断点状态然后你去看别的代码几分钟后回来发现 Fiddler 假死原因是会话积压过多。解决方法是养成习惯用ShiftF11取消所有请求前断点用AltF11取消所有响应后断点或者直接重启 Fiddler。生产环境特别不建议开着全局断点很容易把一个正常业务卡成“服务瘫痪”。我曾经在联调环境下忘记关闭响应断点导致整个测试团队大面积超时自那以后我改完数据一定第一时间关掉 Breakpoint 开关。还有一点修改响应体后Fiddler 会自动重新计算 Content-Length但如果你直接改的是压缩后的响应体例如 gzip修改内容会乱码。正确做法是先把响应头里的Content-Encoding: gzip移除让 Fiddler 以明文处理修改完再按需重新压缩。这个细节容易被忽视也是“我改了响应怎么企业微信返回乱码”的常见原因。5. 移动端与跨网络抓包真机调试的那些配置细节5.1 同一局域网下的代理设置手机与电脑必须处于同一局域网并且电脑防火墙要允许 8888 端口对外监听。Fiddler 默认监听所有网络接口但你需要在设置里确认“Allow remote computers to connect”是勾选状态否则手机连代理会立刻失败。电脑的局域网 IP 获取方式不同系统也有差异但核心是确保 IP 正确。在手机 Wi-Fi 设置里找到“代理”选择手动填写电脑 IP 和端口 8888。此时打开手机任意网页电脑上应该马上出现新增会话。如果不出现用浏览器访问代理 IP 和端口能打开 Fiddler 自带的证书下载页说明代理层通了打不开则多半是防火墙或局域网隔离策略拦截。5.2 不同手机系统的证书信任差异手机装完根证书后“信任”这一步在两类系统上思路不同。一类系统要求用户在证书详情里手动开启高级信任开关另一类系统需要额外导入为系统级证书普通用户模式导入的是用户证书对部分 App 默认不受信。如果你只是调试浏览器流量用户证书基本够用但调试一些安全等级较高的 App你会发现请求直接报证书错误。遇到这种情况先别想歪路子。正确做法第一步是确认应用是否允许用户证书第二步是看应用是否开启代理检测。很多 App 会对 HTTP 代理敏感检测到系统代理后直接拒绝访问。此时你可以尝试改用透明代理或者把流量转发到端口绕开系统代理检测。但这些手段都只限于调试自己负责的应用不能用来跳过别人服务的防护机制。最后不要为了方便而在生产环境长期关闭验证。5.3 抓包工具连不上网常见原因排查顺序手机连上 Fiddler 后发现所有请求都超时我按以下顺序排查检查 Fiddler 是否开启“Allow remote computers”没开的话手机代理直接被拒。电脑和手机 ping 一下同网段不通就移过去相连的网络别在两级路由器下折腾。关掉电脑上的杀毒软件防火墙或者单独放行 Fiddler 进程。在手机浏览器下载证书页面能打开说明 HTTP 层通打不开说明代理被系统拦截。抓取 HTTPS 解密失败时重新确认证书安装与信任步骤。最容易被忽略的是电脑上有多个网络适配器Fiddler 监听的是有线网卡的 IP而手机连接的是无线网卡的 IP两者不在同一网段。你在命令行ipconfig看到的可能是无线 IP但 Fiddler 绑定的是有线。解决方式是直接给 Fiddler 监听地址绑定成0.0.0.0所有接口都监听手机配 IP 时用电脑当前连接路由的那个 IP。5.4 安全边界只抓自己的设备流量抓包工具本身是中性技术就像一把螺丝刀可以用来修设备也可以用来拆设备。作为从业者我给自己立了三条规则第一只抓自己拥有或有明确授权的设备流量第二不把解密能力用于收集他人密码、Cookie、账号信息第三调试结束后及时移除代理配置和根证书尤其是公用电脑和公用测试机。这不仅是合规问题也是职业底线。公司里调试生产环境也要先确认是否有相关授权和监控要求。Fiddler 的日志会保存所有流量包括明文密码和 Token因此保存的 .saz 文件必须妥善处置不要随手放到公开共享目录。我记得有次一个同事把带 token 的会话文件传到了公共网盘结果第二天 token 被刷爆整个项目组加班换密钥。这个教训值得每个用抓包工具的人记住。6. 从调试到自动化Composer、AutoResponder和脚本扩展6.1 Composer手工构造请求当你已经清楚一个接口所有参数后可以直接用 Composer 构造请求而不必总是重复打开页面触发。把已有的请求拖进 Composer你可以改成别的 URL、改请求方法、改 header、改 body然后点 Execute 发送。这个能力在做接口回归、给后端做冒烟测试时非常高效。需要注意的是 Composer 发送的请求默认会走当前代理也就是会出现在同一个会话列表里所以你能看到它的完整响应。它还支持输入原始 HTTP 报文很多人在做自定义协议调试时都是先把报文头写好再用 Composer 里的“Raw”标签直接粘贴执行。这里有个小技巧CtrlR切换 Inspectors 时Focus 在 Composer 的 URL 框可直接写 URL回车就能发请求。6.2 AutoResponder实现“假接口”与Mock环境AutoResponder 是前端开发最爱的功能。它允许你把某个 URL 的响应替换成本地文件、另一个 URL 或者一个自定义字符串。配置好后页面请求到达 Fiddler 时不转发到服务器而是直接返回你指定的内容。用这个功能你可以在后端接口未完成时就完成前端联调也可以把耗时接口临时替换成固定返回让测试环境摆脱依赖。我常用它造三种场景一是“先显示 Loading再返回成功数据”二是“接口异常时返回 500 和错误提示”三是“图片请求全部替换成本地占位图”。每一种都只需要简单的规则和文件路径关键是把匹配规则写准确。规则支持正则初学者可以用通配符比如regex:.*\.png$匹配所有 png 图片。但要注意规则列表是有先后顺序的越靠前优先级越高。我踩过坑写了一条/api/的规则结果把api/login和api/user全返回了同一个 JSON调试了好一会儿才发现是规则树逻辑问题。6.3 FiddlerScript改动响应的小玩法FiddlerScript 是 Fiddler 的脚本机制你可以把它理解成“插件钩子”在事件函数里写代码对经过的会话做自动化处理。虽然很多人觉得脚本有门槛但只要你会一点点函数规则就能做出很实用的工具。最经典的例子是自动修改某个接口的响应 header在OnBeforeResponse函数里判断 URL然后直接给 header 增加字段。我写过一个小脚本专门给静态资源加Cache-Control: no-cache避免开发时反复清缓存。还写过在OnBeforeRequest里自动加Authorization头的脚本省去每次手动填 Token 的麻烦。FiddlerScript 使用的是类似语法和事件模型初次上手不要求写复杂逻辑从改一个 header 开始慢慢就能扩展成自己的调试助手。6.4 会话保存与回归对比抓包不只是在出问题时用也应该沉淀成团队资产。Fiddler 可以把当前所有会话保存成 .saz 文件保存后重新打开会话列表、响应内容、时间戳全都保留。我习惯在项目每个版本发布前把关键流程抓一份 .saz 存到版本档案里下次测试如果发现接口行为变了直接拿新旧两份会话做对比立刻能看出是请求参数变了还是响应结构变了。对比时可以用 Fiddler 自带的对比功能或导出文本后用协作工具比对。推荐先把感兴趣的会话右键导出为文本再用文本对比工具查看差异。这个流程比口头沟通“好像返回不一样”可靠得多。另外保存会话时注意去掉安全性敏感字段如 Cookie、Authorization、Token 等可以用脚本在导出前清洗一遍。最后再分享一点个人经验抓包不是越全越好而是越“聚焦”越好。我在处理线上问题时第一步永远是开host:过滤只保留目标域名第二步才开 HTTPS 解密第三步根据需求开断点。这样做能让会话列表保持清爽不会在三千条请求里迷路。Fiddler 的快捷键和命令很多但你先记住CtrlX清空列表、CtrlF查找响应内容、AltF11取消断点这三个足够覆盖 90% 的日常操作。工具终究是工具真正发挥价值的关键是你能不能把眼前这条流量理解成一条完整的业务故事。
