Fiddler（标题里写成 Fidder 也不影响，指的就是它）是我平时做接口联调、定位线上 bug 时用得最多的工具。一个不起眼的小窗口，却能把我电脑和手机发出去的每一个 HTTP/HTTPS 请求记录下来，请求头、请求体、返回内容全都摊开在面前；还能手工改参数重新发一遍请求，把线上接口临时映射到本地文件，在请求发出前或响应返回前拦一手。做后端、前端、客户端、测试的同学，只要跟接口打交道，迟早会用到它。这篇文章我不打算念说明书，而是按我自己实际使用习惯来写：先说工具到底靠什么原理工作，再讲环境怎么一步步配好，然后挑几个日常最高频的操作手把手演示，最后列一些我踩过的坑。第一次拿到 Fiddler 的人，按这个顺序走一遍，基本能独立上手。1. 先搞清楚 Fiddler 到底干了件什么事1.1 它本质是一个“中间代理站”Fiddler 启动后，会在你电脑上开一个监听端口（默认 8888）。它会修改系统的网络代理设置，让浏览器、客户端程序发出的所有 HTTP 请求，都先流经这个 8888 端口，而不是直接发往目标服务器。这个过程可以理解成快递中转站：正常情况下你直接把包裹寄给收件人，但现在所有包裹都先拉到中转站，中转站拆开看一眼、登记一下、甚至换掉里面东西，再重新封装寄出去。Fiddler 就是那个中转站，既能看，也能改。也正因为它是代理，所以你不仅能让电脑上的流量经过它，也能把手机、平板配置成代理指向这台电脑，用同一个工具查看移动端应用发出的请求。这一点很重要，很多人以为 Fiddler 只能抓浏览器请求，其实它是整个网络出入口的“话务监听台”。只要对方流量愿意走这个代理端口，Fiddler 就能看到。后面我会专门讲手机怎么配，那是移动端调试里特别常用的场景。1.2 为什么抓 HTTPS 要先装证书如果你只听不改，那 HTTP 请求直接就能看到明文内容。但现在的网站基本都是 HTTPS，流量是加密的。Fiddler 默认情况下能看到的东西很有限，你会看到一行行这样的记录：CONNECT api.demo.com:443这表示客户端和目标服务器之间建立了 HTTPS 隧道，Fiddler 只知道你连了哪个域名，完全看不到里面的请求路径、参数、响应内容。要解开这层壳，就需要在设备上安装 Fiddler 的根证书。原理是这么回事：Fiddler 自己生成一对根证书。你安装并信任了它的根证书后，当客户端请求 HTTPS 网站时，Fiddler 会临时伪造一张目标网站的证书，用自己的根证书签名。客户端因为信任这个根证书，就接受了这张伪造证书；而 Fiddler 再拿着真正的客户端身份去和服务器通信。于是客户端和服务器之间那段加密链路，被 Fiddler 从中间“拆”成了两段，两边都以为自己在正常通信，实际上 Fiddler 在中间看得一清二楚。这也是它被称为“中间人代理”的原因。实际配置时，只需要勾选一次解密开关并安装证书，后面所有 HTTPS 流量默认都能解开。2. 五分钟把抓包环境跑起来2.1 下载安装和界面速览Fiddler 有两个版本，老牌的是 Fiddler Classic，只能在 Windows 上跑，功能齐全，绝大多数教程讲的都是它；另外还有一套跨平台的 Fiddler Everywhere，界面更现代，但部分高级脚本能力受到限制。如果你只是日常调试，建议直接用 Classic 版本，稳定、资料多、插件也多。装的时候一路默认即可，装完启动，桌面上会出现一个深色的小窗口。初次打开界面，不要被密密麻麻的区域吓到。你需要先认识的只有几个核心区域：左侧是 Web Sessions 列表，所有经过代理的请求都在这里一行一行列出来；右侧上方是 Inspectors 面板，点左侧任意一条请求，这里会显示详细请求和响应内容；右下角是 QuickExec 命令行，直接输入命令可以快速操作；底部状态栏会显示当前是否在捕获流量、是否已开启 HTTPS 解密等。装完先不要急着点任何东西，下一步把 HTTPS 解密打开，否则你抓到的全是那几行 CONNECT。2.2 打开 HTTPS 解密并正确安装证书在主界面菜单里找到 Tools -> Options，切到 HTTPS 标签页，勾选“Decrypt HTTPS traffic”。如果系统弹出提示框问你是否信任这个证书，选择是。此时 Fiddler 会把它的根证书动态安装进系统证书区。这里我建议再做一步：回到同一界面，点右边的“Export Root Certificate to Desktop”，导出一份证书文件到桌面，便于后面在手机上安装。导出后，在 Windows 上双击这个 .cer 文件，选择“安装证书”，存储位置选“受信任的根证书颁发机构”。为什么推荐手动装一遍？因为有些情况下，Fiddler 自动装的是“受信任人”或当前用户范围，新版浏览器默认使用系统证书库，信任范围不一致时会弹警告。装完后，在界面上随便访问一个网站，比如打开百度或任意 HTTP/HTTPS 页面。左侧列表里应该能看到大量绿色小锁图标的请求，点开一条，右边的 Inspectors 里就能看到完整的请求头、Cookie、表单数据和响应内容。出现绿色锁，说明解密成功了。2.3 手机抓包的快捷配置手机抓包是我使用频率最高的场景之一，联调 App 接口时必须用。操作分两步：第一步，让手机和电脑连同一个局域网，然后确认电脑的局域网 IP。命令行输入 ipconfig 或者在图形界面网络设置里都能看到，形式一般是 192.168.x.x。第二步，在手机 Wi-Fi 设置里找到手动代理配置：打开 Wi-Fi，长按当前网络或点右侧箭头进入代理设置，选“手动”，服务器地址填电脑 IP，端口填 8888。配置完成后，用手机浏览器访问http://电脑IP:8888。页面上有一个 Fiddler 证书下载链接，下载并按系统流程安装。需要特别提醒的是，Android 7 及以上的应用默认不信任用户的 CA 证书，也就是说你装好证书后，浏览器可以正常抓，但很多 App 的 HTTPS 请求可能还是失败或者显示空白。这个时候要么改应用自身的网络安全配置，要么换用支持设置用户证书的方法，这些问题我放在第 5 节详细展开。苹果设备装完描述文件后，记得要去 设置 -> 通用 -> 关于本机 -> 证书信任设置 里，把 Fiddler 证书的“完全信任”开关打开，否则微信、Safari 这些应用会直接拒绝连接。3. 日常高频实操：从一个真实接口调试说起3.1 快速定位你想看的那条请求环境配好，流量会源源不断地刷屏。如果不做任何过滤，左侧列表刷得飞快，找目标请求跟大海捞针一样。我常用的定位方式有三种，按效率排序：过滤器 Filter。在界面菜单打开 Filters 开关，默认使用 Use Filters。下面有一个 Host 输入框，填上目标域名，比如api.demo.com，列表就只显示这个域名的请求，其他全部隐藏。这个方式最稳定，适合长时间观察某几个接口。QuickExec 命令行搜索。直接在右下角输入?user，即可在列表里高亮所有 URL 包含 user 字样的请求；输入?s=login可以按关键词搜索请求体内容。速度很快，适合临时找一条请求。底部状态栏的抓包开关。当你只需要看某个时刻的流量，可以先把捕获开关关掉，清空列表，再打开捕获，然后去 App 里执行一次操作。这样列表里只有你刚操作时触发的请求，干净了很多。定位到目标请求后，点击它，右侧 Inspectors 里默认展示了大概信息。实际最常用的是这几个子页签：Headers：请求头、响应头，看 Content-Type、Cookie、token 之类的关键信息；WebForms：如果是表单 POST，这里会直接列出表单字段名和值；JSON：响应内容是 JSON 时，这里格式化展示，层级清晰；Raw：展示完整原始报文，适合拿出去给同事看或对比。我第一次用 Fiddler 时，找接口参数全是在 Raw 里硬看，后来才发现 WebForms 和 JSON 页签这么方便。遇到一段特别长的 JSON，先在 JSON 页签里看结构，再复制到本地格式化，效率能高不少。3.2 用 Composer 手工构造请求并回放排到一条接口出问题时，最常见的操作思路是：复制这条请求，改几个参数，再发一次，看后端返回什么。这一步正是 Composer 面板的主场。操作很简单：从左侧请求列表里，把目标 Session 直接拖到右侧 Composer 标签页，它会自动把请求方式、URL、请求头、请求体都填好。你只需修改想改的部分，点右上角的 Execute，请求就发出去了，新的响应会在左侧列表新增一条，点开即看结果。我经常用 Composer 做这样一个场景：给后端同学报 bug 时，先删除掉一些和问题无关的请求头（比如测试环境可能不需要的真实 Cookie），保留最核心的 POST 数据和必要认证头，重新执行。这样能把问题缩减到一个最小复现集，后端定位会快很多。如果是想完全从零构造一个请求，也可以在 Composer 里手动填写，方式很简单：POST http://api.demo.com/login HTTP/1.1 Content-Type: application/json {"username":"test","password":"123456"}注意请求头和请求体之间要有一行空行，这是 HTTP 协议的规定。填完点 Execute 即可。实测下来，用这个方式模拟登录、模拟提交订单这类接口互调特别方便，尤其是你手头没有现成客户端的时候。3.3 AutoResponder：把线上请求悄悄换成本地数据另一个我很常用的功能是 AutoResponder，它的作用是：当某个请求命中你设定的规则时，Fiddler 不把请求真正发到服务器，而是直接返回一个预设好的响应。一个典型的联调场景：前端正在开发用户列表页面，后端接口还在排期，只有一份约定的 JSON 示例数据。此时前端可以直接在 AutoResponder 里配置：凡是请求api.demo.com/users，就返回本地目录下的users.json文件内容。前端页面就能拿着这份模拟数据正常开发，不用干等后端。配置步骤：菜单 Rules -> Automatic Options 里勾上“Enable rules”；切到 AutoResponder 标签页，勾选“Enable rules”，再勾选“Unmatched requests passthrough”表示其他请求仍然正常发给服务器；点击 Add Rule，规则位置输入匹配表达式，比如regex:.*api\.demo\.com/users；在右侧下拉框选择响应方式，可以直接选200-SimpleHTML自定义一串内容，也可以选“Find a file”指定本地 JSON 文件路径。这里有个细节：如果你指定的本地文件是 JSON，但下拉框里默认的 Content-Type 可能写的是 text/html，部分前端项目对 Content-Type 校验很严格。解决方法是自定义一行规则响应，手动指定Content-Type: application/json。我第一次用的时候因为没注意这个，前端死活解析不了，后来加上响应头就正常了。3.4 断点调试：在请求发出前和响应返回前拦截AutoResponder 是“替换返回结果”，断点是更灵活的“停下来改内容”。我通常用断点来调试那种需要动态改动参数的场景。开启方式在菜单 Rules -> Automatic Breakpoints 里，有三个选项：Before Requests、After Responses，以及全关的 disabled。Before Requests 表示所有请求在发出去之前会先暂停，After Responses 表示服务器响应返回后、还没交回客户端时暂停。当请求被断住时，Fiddler 会在界面下方出现一个红色高亮的 Session，你可以在右侧 Inspector 里修改请求头、请求体，然后点击 Run to Completion 让它继续发送。对于响应断点，你也可以改完响应内容后再放行，客户端收到的是你改过的数据。这个功能非常适合模拟异常返回。比如我想验证前端对登录接口返回 500 时的处理逻辑，就可以在 After Responses 断住那个登录接口的响应，把响应内容改成HTTP/1.1 500 Internal Server Error，放行后前端立刻进入错误分支。有一点要提醒：断点是对全局生效的，如果开着 Before Requests 断点，所有走代理的请求都会被卡住，网页甚至基本打不开。经验做法是，先用过滤器限定目标 Host，再开断点，实测会顺手得多。也可以不用菜单，直接在 QuickExec 里输入bprequest api.demo.com来设置指定域名的请求断点，更精准。4. 进阶技巧：弱网模拟与脚本扩展4.1 弱网模拟：让传输慢得像地下室信号移动端 App 在弱网环境下的表现，一直是测试的重点，真实弱网环境又不好复现，总不能天天跑去地下室。Fiddler 自带的弱网模拟功能就是我常用的替代方案。菜单 Rules -> Performance -> Simulate Modem Speeds，勾选之后，系统会按模拟拨号上网的速率限制网络延迟和带宽。默认参数大概是这样的效果：上行和下行都会被限制，并有几百毫秒的延迟，体验接近 2G/3G 网络下的加载速度。但默认参数对现在的需求来说偏高。我想自定义成更贴近 4G 弱网的延迟时，就在 FiddlerScript 里调整。菜单 Rules -> Customize Rules 打开脚本，搜索m_SimulateModem，可以找到类似这样的判断逻辑：if (m_SimulateModem) { // Delay sends by 300ms per KB uploaded. oSession["request-trickle-delay"] = "300"; // Delay receives by 150ms per KB downloaded. oSession["response-trickle-delay"] = "150"; }这里的“request-trickle-delay”和“response-trickle-delay”分别控制上行和下行网络中的每 KB 数据延迟时间，单位是毫秒。想模拟更差的环境就把数字调大，比如改成 1000 和 500。保存脚本后需要重新勾选一次 Simulate Modem Speeds 才生效。我实际测过，300/150 这个组合对大多数接口联调够用，页面加载有明显的等待感但不会彻底卡死。做更极端的弱网测试时，我还会配合断点功能手动拖慢个别请求。4.2 QuickExec 命令行：用几个命令省掉一半点击QuickExec 是 Fiddler 右下角那个只显示单行输入框的小区域，很多人没注意到，但它继承了命令行工具的精髓，一行命令能干不少事。我最常用的几个：cls：清空左侧会话列表，相当于点一下清屏，开抓之前敲一下很方便；?s=：搜索请求内容中包含指定字符串的请求；select json：高亮所有响应类型是 JSON 的请求；bps/bpafter：设置断点或取消断点；后面跟域名可以只对指定域名的请求断点；stats：打开当前会话的统计信息面板，看各请求耗时。组合一下就是一套高效操作流：先cls，然后在 App 里复现一次问题，接着?s=error快速定位含 error 关键字的请求，右键直接把 Session 导出或者拖进 Composer。这套流程我每天都能用上，比鼠标点来点去快一大截。4.3 用 FiddlerScript 给请求自动加标记除了界面操作，Fiddler 还支持用脚本深度定制行为，最典型的是在 FiddlerScript 中修改OnBeforeRequest这个函数。这个函数会在每个请求发出去之前执行，我经常用它往特定请求头上加调试标记。举个例子，我想让所有发往api.demo.com的请求自动带上一个X-Simulate: debug请求头，方便后端识别测试环境的流量：static function OnBeforeRequest(oSession: Session) { if (oSession.HostnameIs("api.demo.com")) { oSession.RequestHeaders["X-Simulate"] = "debug"; } }保存脚本后立即生效，不需要重启 Fiddler。类似还可以做自动保存请求内容、自动改某些路径的响应等。脚本语言是类 JavaScript 语法，有一定前端基础的话上手不算难。我不会刻意说脚本功能有多神，但碰到那种“每个请求都要带一个动态签名头”的场景，手改请求头十次绝对会疯，写一条规则在入口统一加，一劳永逸。5. 常见问题与排查实录5.1 抓不到流量时的排查清单“为什么我打开 Fiddler，列表里什么都没有？” 这个问题我遇到不下十次，基本上按下面的清单排查一遍都能解决。代理有没有生效？打开系统设置，确认代理地址确实指向127.0.0.1:8888或localhost:8888。有些安全软件或网络加速工具会重置代理设置，关了重开 Fiddler 即可。有没有开着其他抓包工具或加速器？多个代理工具共用 8888 端口会冲突，先全部退出其他工具。浏览器是否忽略系统代理？新版浏览器默认采用系统代理，但如果浏览器里装了代理扩展（切换代理的那种插件），流量可能被插件带到别处，需要把插件关闭。是不是只抓到了 CONNECT？如果是，说明 HTTPS 解密没开或者证书没被信任，按第 2 节重装一遍证书基本能解决。手机连不上？先确认手机和电脑在同一个网段，再用电脑上的命令验证监听端口是否正常。可以用另一台电脑访问电脑IP:8888，看到 Fiddler 的证书下载页就说明监听着正常。大多数“抓不到”都出在前两项，真正需要找问题的场景反而少。5.2 证书信任失败的几种典型情况证书问题是最容易让人卡住的环节，典型表现是：开了 HTTPS 解密后，浏览器访问任何网站都提示证书不安全，或者 App 直接报“无法连接服务器”。三种常见情况和对策我整理如下：手机下载证书后安装时报错“CA 证书已存在”或找不到安装入口。这种情况通常是系统版本较高，需要去“设置 -> 安全 -> 加密与凭据 -> 安装证书 -> CA 证书”里手动选择文件。iOS 装完描述文件，Safari 抓取正常但 App 内请求失败。多半是没开“完全信任”，去证书信任设置里打开即可。部分安卓应用明确不信任用户证书。原因是 Android 7.0 之后，应用默认只信任系统证书。需要应用自身配置允许，或者选一台可以 root 的测试机把证书装进系统证书目录。这个属于上手难度比较高的操作，建议非必要不折腾。5.3 抓包工具相关的安全习惯用 Fiddler 能看到很多东西，但也因为能看到很多东西，有些习惯必须养成。我自己在使用时，始终遵守几条原则：抓包只针对自己有权调试的应用和接口，不碰没有授权的流量；涉及密码、验证码、支付信息等敏感数据时，尽量用虚拟账号或测试环境，避免在抓包过程留下真实凭据；把抓包结果分享给他人时，对 token、手机号等隐私字段做脱敏处理再截图或导出。这些不是多余的谨慎。抓包本质是把你的流量拆开来看，拆开的过程中，凡是经过代理的数据都可能在电脑磁盘或日志里留下副本，一旦电脑被他人操作或者记录被外泄，造成的问题会远远超出技术本身。6. 关于 Fiddler，我的几点使用体会用了这么多年抓包工具，最大的感受是：它真正值钱的能力不是“能把流量抓出来”，而是“能让你理解一条请求完整走过了哪些环节”。很多前后端联调问题，表面上是接口报错，本质是请求头带错了、参数格式不对、响应结构变了，而这些全都能在 Fiddler 一条 Session 里看清楚。一个小技巧收尾：线上出问题时，把 Fiddler 的会话列表完整导出成.saz文件，连同客户端操作步骤一起发给相关开发，对方用 Fiddler 一键导入，就能按时间线一步步还原当时的请求链路。这比在 IM 里粘贴一张模糊截图有效得多。我这两年能快速帮同事定位问题，靠的基本上就是这个习惯。
Fiddler（标题里写成 Fidder 也不影响，指的就是它）是我平时做接口联调、定位线上 bug 时用得最多的工具。一个不起眼的小窗口，却能把我电脑和手机发出去的每一个 HTTP/HTTPS 请求记录下来，请求头、请求体、返回内容全都摊开在面前；还能手工改参数重新发一遍请求，把线上接口临时映射到本地文件，在请求发出前或响应返回前拦一手。做后端、前端、客户端、测试的同学，只要跟接口打交道，迟早会用到它。这篇文章我不打算念说明书，而是按我自己实际使用习惯来写：先说工具到底靠什么原理工作，再讲环境怎么一步步配好，然后挑几个日常最高频的操作手把手演示，最后列一些我踩过的坑。第一次拿到 Fiddler 的人，按这个顺序走一遍，基本能独立上手。1. 先搞清楚 Fiddler 到底干了件什么事1.1 它本质是一个“中间代理站”Fiddler 启动后，会在你电脑上开一个监听端口（默认 8888）。它会修改系统的网络代理设置，让浏览器、客户端程序发出的所有 HTTP 请求，都先流经这个 8888 端口，而不是直接发往目标服务器。这个过程可以理解成快递中转站：正常情况下你直接把包裹寄给收件人，但现在所有包裹都先拉到中转站，中转站拆开看一眼、登记一下、甚至换掉里面东西，再重新封装寄出去。Fiddler 就是那个中转站，既能看，也能改。也正因为它是代理，所以你不仅能让电脑上的流量经过它，也能把手机、平板配置成代理指向这台电脑，用同一个工具查看移动端应用发出的请求。这一点很重要，很多人以为 Fiddler 只能抓浏览器请求，其实它是整个网络出入口的“话务监听台”。只要对方流量愿意走这个代理端口，Fiddler 就能看到。后面我会专门讲手机怎么配，那是移动端调试里特别常用的场景。1.2 为什么抓 HTTPS 要先装证书如果你只听不改，那 HTTP 请求直接就能看到明文内容。但现在的网站基本都是 HTTPS，流量是加密的。Fiddler 默认情况下能看到的东西很有限，你会看到一行行这样的记录：CONNECT api.demo.com:443这表示客户端和目标服务器之间建立了 HTTPS 隧道，Fiddler 只知道你连了哪个域名，完全看不到里面的请求路径、参数、响应内容。要解开这层壳，就需要在设备上安装 Fiddler 的根证书。原理是这么回事：Fiddler 自己生成一对根证书。你安装并信任了它的根证书后，当客户端请求 HTTPS 网站时，Fiddler 会临时伪造一张目标网站的证书，用自己的根证书签名。客户端因为信任这个根证书，就接受了这张伪造证书；而 Fiddler 再拿着真正的客户端身份去和服务器通信。于是客户端和服务器之间那段加密链路，被 Fiddler 从中间“拆”成了两段，两边都以为自己在正常通信，实际上 Fiddler 在中间看得一清二楚。这也是它被称为“中间人代理”的原因。实际配置时，只需要勾选一次解密开关并安装证书，后面所有 HTTPS 流量默认都能解开。2. 五分钟把抓包环境跑起来2.1 下载安装和界面速览Fiddler 有两个版本，老牌的是 Fiddler Classic，只能在 Windows 上跑，功能齐全，绝大多数教程讲的都是它；另外还有一套跨平台的 Fiddler Everywhere，界面更现代，但部分高级脚本能力受到限制。如果你只是日常调试，建议直接用 Classic 版本，稳定、资料多、插件也多。装的时候一路默认即可，装完启动，桌面上会出现一个深色的小窗口。初次打开界面，不要被密密麻麻的区域吓到。你需要先认识的只有几个核心区域：左侧是 Web Sessions 列表，所有经过代理的请求都在这里一行一行列出来；右侧上方是 Inspectors 面板，点左侧任意一条请求，这里会显示详细请求和响应内容；右下角是 QuickExec 命令行，直接输入命令可以快速操作；底部状态栏会显示当前是否在捕获流量、是否已开启 HTTPS 解密等。装完先不要急着点任何东西，下一步把 HTTPS 解密打开，否则你抓到的全是那几行 CONNECT。2.2 打开 HTTPS 解密并正确安装证书在主界面菜单里找到 Tools -> Options，切到 HTTPS 标签页，勾选“Decrypt HTTPS traffic”。如果系统弹出提示框问你是否信任这个证书，选择是。此时 Fiddler 会把它的根证书动态安装进系统证书区。这里我建议再做一步：回到同一界面，点右边的“Export Root Certificate to Desktop”，导出一份证书文件到桌面，便于后面在手机上安装。导出后，在 Windows 上双击这个 .cer 文件，选择“安装证书”，存储位置选“受信任的根证书颁发机构”。为什么推荐手动装一遍？因为有些情况下，Fiddler 自动装的是“受信任人”或当前用户范围，新版浏览器默认使用系统证书库，信任范围不一致时会弹警告。装完后，在界面上随便访问一个网站，比如打开百度或任意 HTTP/HTTPS 页面。左侧列表里应该能看到大量绿色小锁图标的请求，点开一条，右边的 Inspectors 里就能看到完整的请求头、Cookie、表单数据和响应内容。出现绿色锁，说明解密成功了。2.3 手机抓包的快捷配置手机抓包是我使用频率最高的场景之一，联调 App 接口时必须用。操作分两步：第一步，让手机和电脑连同一个局域网，然后确认电脑的局域网 IP。命令行输入 ipconfig 或者在图形界面网络设置里都能看到，形式一般是 192.168.x.x。第二步，在手机 Wi-Fi 设置里找到手动代理配置：打开 Wi-Fi，长按当前网络或点右侧箭头进入代理设置，选“手动”，服务器地址填电脑 IP，端口填 8888。配置完成后，用手机浏览器访问http://电脑IP:8888。页面上有一个 Fiddler 证书下载链接，下载并按系统流程安装。需要特别提醒的是，Android 7 及以上的应用默认不信任用户的 CA 证书，也就是说你装好证书后，浏览器可以正常抓，但很多 App 的 HTTPS 请求可能还是失败或者显示空白。这个时候要么改应用自身的网络安全配置，要么换用支持设置用户证书的方法，这些问题我放在第 5 节详细展开。苹果设备装完描述文件后，记得要去 设置 -> 通用 -> 关于本机 -> 证书信任设置 里，把 Fiddler 证书的“完全信任”开关打开，否则微信、Safari 这些应用会直接拒绝连接。3. 日常高频实操：从一个真实接口调试说起3.1 快速定位你想看的那条请求环境配好，流量会源源不断地刷屏。如果不做任何过滤，左侧列表刷得飞快，找目标请求跟大海捞针一样。我常用的定位方式有三种，按效率排序：过滤器 Filter。在界面菜单打开 Filters 开关，默认使用 Use Filters。下面有一个 Host 输入框，填上目标域名，比如api.demo.com，列表就只显示这个域名的请求，其他全部隐藏。这个方式最稳定，适合长时间观察某几个接口。QuickExec 命令行搜索。直接在右下角输入?user，即可在列表里高亮所有 URL 包含 user 字样的请求；输入?s=login可以按关键词搜索请求体内容。速度很快，适合临时找一条请求。底部状态栏的抓包开关。当你只需要看某个时刻的流量，可以先把捕获开关关掉，清空列表，再打开捕获，然后去 App 里执行一次操作。这样列表里只有你刚操作时触发的请求，干净了很多。定位到目标请求后，点击它，右侧 Inspectors 里默认展示了大概信息。实际最常用的是这几个子页签：Headers：请求头、响应头，看 Content-Type、Cookie、token 之类的关键信息；WebForms：如果是表单 POST，这里会直接列出表单字段名和值；JSON：响应内容是 JSON 时，这里格式化展示，层级清晰；Raw：展示完整原始报文，适合拿出去给同事看或对比。我第一次用 Fiddler 时，找接口参数全是在 Raw 里硬看，后来才发现 WebForms 和 JSON 页签这么方便。遇到一段特别长的 JSON，先在 JSON 页签里看结构，再复制到本地格式化，效率能高不少。3.2 用 Composer 手工构造请求并回放排到一条接口出问题时，最常见的操作思路是：复制这条请求，改几个参数，再发一次，看后端返回什么。这一步正是 Composer 面板的主场。操作很简单：从左侧请求列表里，把目标 Session 直接拖到右侧 Composer 标签页，它会自动把请求方式、URL、请求头、请求体都填好。你只需修改想改的部分，点右上角的 Execute，请求就发出去了，新的响应会在左侧列表新增一条，点开即看结果。我经常用 Composer 做这样一个场景：给后端同学报 bug 时，先删除掉一些和问题无关的请求头（比如测试环境可能不需要的真实 Cookie），保留最核心的 POST 数据和必要认证头，重新执行。这样能把问题缩减到一个最小复现集，后端定位会快很多。如果是想完全从零构造一个请求，也可以在 Composer 里手动填写，方式很简单：POST http://api.demo.com/login HTTP/1.1 Content-Type: application/json {"username":"test","password":"123456"}注意请求头和请求体之间要有一行空行，这是 HTTP 协议的规定。填完点 Execute 即可。实测下来，用这个方式模拟登录、模拟提交订单这类接口互调特别方便，尤其是你手头没有现成客户端的时候。3.3 AutoResponder：把线上请求悄悄换成本地数据另一个我很常用的功能是 AutoResponder，它的作用是：当某个请求命中你设定的规则时，Fiddler 不把请求真正发到服务器，而是直接返回一个预设好的响应。一个典型的联调场景：前端正在开发用户列表页面，后端接口还在排期，只有一份约定的 JSON 示例数据。此时前端可以直接在 AutoResponder 里配置：凡是请求api.demo.com/users，就返回本地目录下的users.json文件内容。前端页面就能拿着这份模拟数据正常开发，不用干等后端。配置步骤：菜单 Rules -> Automatic Options 里勾上“Enable rules”；切到 AutoResponder 标签页，勾选“Enable rules”，再勾选“Unmatched requests passthrough”表示其他请求仍然正常发给服务器；点击 Add Rule，规则位置输入匹配表达式，比如regex:.*api\.demo\.com/users；在右侧下拉框选择响应方式，可以直接选200-SimpleHTML自定义一串内容，也可以选“Find a file”指定本地 JSON 文件路径。这里有个细节：如果你指定的本地文件是 JSON，但下拉框里默认的 Content-Type 可能写的是 text/html，部分前端项目对 Content-Type 校验很严格。解决方法是自定义一行规则响应，手动指定Content-Type: application/json。我第一次用的时候因为没注意这个，前端死活解析不了，后来加上响应头就正常了。3.4 断点调试：在请求发出前和响应返回前拦截AutoResponder 是“替换返回结果”，断点是更灵活的“停下来改内容”。我通常用断点来调试那种需要动态改动参数的场景。开启方式在菜单 Rules -> Automatic Breakpoints 里，有三个选项：Before Requests、After Responses，以及全关的 disabled。Before Requests 表示所有请求在发出去之前会先暂停，After Responses 表示服务器响应返回后、还没交回客户端时暂停。当请求被断住时，Fiddler 会在界面下方出现一个红色高亮的 Session，你可以在右侧 Inspector 里修改请求头、请求体，然后点击 Run to Completion 让它继续发送。对于响应断点，你也可以改完响应内容后再放行，客户端收到的是你改过的数据。这个功能非常适合模拟异常返回。比如我想验证前端对登录接口返回 500 时的处理逻辑，就可以在 After Responses 断住那个登录接口的响应，把响应内容改成HTTP/1.1 500 Internal Server Error，放行后前端立刻进入错误分支。有一点要提醒：断点是对全局生效的，如果开着 Before Requests 断点，所有走代理的请求都会被卡住，网页甚至基本打不开。经验做法是，先用过滤器限定目标 Host，再开断点，实测会顺手得多。也可以不用菜单，直接在 QuickExec 里输入bprequest api.demo.com来设置指定域名的请求断点，更精准。4. 进阶技巧：弱网模拟与脚本扩展4.1 弱网模拟：让传输慢得像地下室信号移动端 App 在弱网环境下的表现，一直是测试的重点，真实弱网环境又不好复现，总不能天天跑去地下室。Fiddler 自带的弱网模拟功能就是我常用的替代方案。菜单 Rules -> Performance -> Simulate Modem Speeds，勾选之后，系统会按模拟拨号上网的速率限制网络延迟和带宽。默认参数大概是这样的效果：上行和下行都会被限制，并有几百毫秒的延迟，体验接近 2G/3G 网络下的加载速度。但默认参数对现在的需求来说偏高。我想自定义成更贴近 4G 弱网的延迟时，就在 FiddlerScript 里调整。菜单 Rules -> Customize Rules 打开脚本，搜索m_SimulateModem，可以找到类似这样的判断逻辑：if (m_SimulateModem) { // Delay sends by 300ms per KB uploaded. oSession["request-trickle-delay"] = "300"; // Delay receives by 150ms per KB downloaded. oSession["response-trickle-delay"] = "150"; }这里的“request-trickle-delay”和“response-trickle-delay”分别控制上行和下行网络中的每 KB 数据延迟时间，单位是毫秒。想模拟更差的环境就把数字调大，比如改成 1000 和 500。保存脚本后需要重新勾选一次 Simulate Modem Speeds 才生效。我实际测过，300/150 这个组合对大多数接口联调够用，页面加载有明显的等待感但不会彻底卡死。做更极端的弱网测试时，我还会配合断点功能手动拖慢个别请求。4.2 QuickExec 命令行：用几个命令省掉一半点击QuickExec 是 Fiddler 右下角那个只显示单行输入框的小区域，很多人没注意到，但它继承了命令行工具的精髓，一行命令能干不少事。我最常用的几个：cls：清空左侧会话列表，相当于点一下清屏，开抓之前敲一下很方便；?s=：搜索请求内容中包含指定字符串的请求；select json：高亮所有响应类型是 JSON 的请求；bps/bpafter：设置断点或取消断点；后面跟域名可以只对指定域名的请求断点；stats：打开当前会话的统计信息面板，看各请求耗时。组合一下就是一套高效操作流：先cls，然后在 App 里复现一次问题，接着?s=error快速定位含 error 关键字的请求，右键直接把 Session 导出或者拖进 Composer。这套流程我每天都能用上，比鼠标点来点去快一大截。4.3 用 FiddlerScript 给请求自动加标记除了界面操作，Fiddler 还支持用脚本深度定制行为，最典型的是在 FiddlerScript 中修改OnBeforeRequest这个函数。这个函数会在每个请求发出去之前执行，我经常用它往特定请求头上加调试标记。举个例子，我想让所有发往api.demo.com的请求自动带上一个X-Simulate: debug请求头，方便后端识别测试环境的流量：static function OnBeforeRequest(oSession: Session) { if (oSession.HostnameIs("api.demo.com")) { oSession.RequestHeaders["X-Simulate"] = "debug"; } }保存脚本后立即生效，不需要重启 Fiddler。类似还可以做自动保存请求内容、自动改某些路径的响应等。脚本语言是类 JavaScript 语法，有一定前端基础的话上手不算难。我不会刻意说脚本功能有多神，但碰到那种“每个请求都要带一个动态签名头”的场景，手改请求头十次绝对会疯，写一条规则在入口统一加，一劳永逸。5. 常见问题与排查实录5.1 抓不到流量时的排查清单“为什么我打开 Fiddler，列表里什么都没有？” 这个问题我遇到不下十次，基本上按下面的清单排查一遍都能解决。代理有没有生效？打开系统设置，确认代理地址确实指向127.0.0.1:8888或localhost:8888。有些安全软件或网络加速工具会重置代理设置，关了重开 Fiddler 即可。有没有开着其他抓包工具或加速器？多个代理工具共用 8888 端口会冲突，先全部退出其他工具。浏览器是否忽略系统代理？新版浏览器默认采用系统代理，但如果浏览器里装了代理扩展（切换代理的那种插件），流量可能被插件带到别处，需要把插件关闭。是不是只抓到了 CONNECT？如果是，说明 HTTPS 解密没开或者证书没被信任，按第 2 节重装一遍证书基本能解决。手机连不上？先确认手机和电脑在同一个网段，再用电脑上的命令验证监听端口是否正常。可以用另一台电脑访问电脑IP:8888，看到 Fiddler 的证书下载页就说明监听着正常。大多数“抓不到”都出在前两项，真正需要找问题的场景反而少。5.2 证书信任失败的几种典型情况证书问题是最容易让人卡住的环节，典型表现是：开了 HTTPS 解密后，浏览器访问任何网站都提示证书不安全，或者 App 直接报“无法连接服务器”。三种常见情况和对策我整理如下：手机下载证书后安装时报错“CA 证书已存在”或找不到安装入口。这种情况通常是系统版本较高，需要去“设置 -> 安全 -> 加密与凭据 -> 安装证书 -> CA 证书”里手动选择文件。iOS 装完描述文件，Safari 抓取正常但 App 内请求失败。多半是没开“完全信任”，去证书信任设置里打开即可。部分安卓应用明确不信任用户证书。原因是 Android 7.0 之后，应用默认只信任系统证书。需要应用自身配置允许，或者选一台可以 root 的测试机把证书装进系统证书目录。这个属于上手难度比较高的操作，建议非必要不折腾。5.3 抓包工具相关的安全习惯用 Fiddler 能看到很多东西，但也因为能看到很多东西，有些习惯必须养成。我自己在使用时，始终遵守几条原则：抓包只针对自己有权调试的应用和接口，不碰没有授权的流量；涉及密码、验证码、支付信息等敏感数据时，尽量用虚拟账号或测试环境，避免在抓包过程留下真实凭据；把抓包结果分享给他人时，对 token、手机号等隐私字段做脱敏处理再截图或导出。这些不是多余的谨慎。抓包本质是把你的流量拆开来看，拆开的过程中，凡是经过代理的数据都可能在电脑磁盘或日志里留下副本，一旦电脑被他人操作或者记录被外泄，造成的问题会远远超出技术本身。6. 关于 Fiddler，我的几点使用体会用了这么多年抓包工具，最大的感受是：它真正值钱的能力不是“能把流量抓出来”，而是“能让你理解一条请求完整走过了哪些环节”。很多前后端联调问题，表面上是接口报错，本质是请求头带错了、参数格式不对、响应结构变了，而这些全都能在 Fiddler 一条 Session 里看清楚。一个小技巧收尾：线上出问题时，把 Fiddler 的会话列表完整导出成.saz文件，连同客户端操作步骤一起发给相关开发，对方用 Fiddler 一键导入，就能按时间线一步步还原当时的请求链路。这比在 IM 里粘贴一张模糊截图有效得多。我这两年能快速帮同事定位问题，靠的基本上就是这个习惯。