干测试这行，手里没个趁手的抓包工具，遇到接口问题真的是寸步难行。前后端扯皮的时候、App突然没数据的时候、线上接口报错复现不了的时候，Fiddler永远是第一个被我拉出来救场的工具。平时大家搜“Fildder”或者“抓包工具fiddler”，其实就是这个老牌工具——注意正确拼写是 Fiddler，两个 d，不是 Fildder。这篇文章我就把自己这些年用 Fiddler 抓包、调试接口、Mock 数据的完整经验整理出来，从工具原理、环境配置到高频问题排查全部讲透，适合刚入门测试和开发的新手，也适合想把手里的 Fiddler 用得更溜的老手。
1. 先搞清楚：Fiddler 到底在干什么
1.1 抓包抓的到底是什么
很多人刚接触抓包工具时，一打开 Fiddler 看到满屏的英文会话列表就懵了。说白了，抓包抓的就是你电脑或手机发出的每一个网络请求，以及服务器返回的每一个响应。一个完整的 HTTP 请求包含请求行、请求头、请求体三部分，响应则包含状态码、响应头、响应体。比如你在浏览器里登录一个网站，前端会发一条 POST 请求到登录接口，里面带着用户名和密码；服务器验证通过后，会返回一组 JSON 数据和一个 Session ID。整个过程如果出了问题，前端会让你找后端，后端让你看日志，而实际上只要一条抓包记录就能定位到问题出在请求没发出去、参数传错、还是响应被拦截了。
我习惯把抓包理解成快递中转站的安检扫描仪。你的每一个网络请求都是一个包裹，Fiddler 就是个敬业的安检员，每一件包裹都要从它手里过一遍，它能看到包裹上的所有标签（请求头、状态码），也能打开包裹检查里面的内容（JSON、HTML、图片）。通过这种方式，你能把原本封装得严严实实的网络通信过程，拆解成一条条可读、可复制、可修改的记录。这就是抓包的核心价值。
1.2 为什么我在测试环境里首选 Fiddler
市面上的抓包工具不少，Charles、Wireshark、浏览器自带的 F12 开发者工具都能干这活，但 Fiddler 在我日常工作中用得最多，主要原因有三个。
首先是免费且功能完整。Fiddler Classic 对 Windows 用户完全免费，而且抓包、断点、改包、Mock、性能分析这些核心功能一个不缺。相比 Charles 需要付费授权，Fiddler 对个人学习和小团队测试来说几乎没有门槛。其次是操作直观，上手成本低。F12 开发者工具虽然也能看请求，但它只能看浏览器发出的请求，App 里的流量你截不到；Wireshark 虽然能抓到所有包，但它展示的是十六进制底层数据，对 HTTP 层面的调试很不友好。Fiddler 正好卡在中间：既能抓系统全局的 HTTP/HTTPS 流量，又能以树形结构展示请求响应细节，双击就能看到格式化后的 JSON。
第三个原因是可以改包和 Mock。Fiddler 的 AutoResponder 和断点功能可以完全接管接口响应，这在后端接口没准备好的时候帮了大忙。我举个例子：前端页面依赖一个订单列表接口，后端说还要三天才能给数据，前端等不起。我在 Fiddler 里加一条规则，把线上同款接口的响应保存成本地 JSON 文件，再映射给前端调用的地址，页面立刻就有数据可联调了。这种能力 Charles 也有，但 Fiddler 用起来更顺，尤其是在 Windows 环境上几乎没有兼容性问题。当然，如果你主要用 Mac，Charles 或 Fiddler Everywhere 会更顺手，工具选型要结合团队环境，不能一刀切。
1.3 Fiddler 的核心工作机制：本地中转与 HTTPS 解密
Fiddler 能在测试中发挥这么大作用，底层依赖的是一场“中间人”魔术。默认情况下，Fiddler 启动后会监听本机的 8888 端口，把自己注册成系统 HTTP 代理。所有从浏览器或 App 发出的请求都不会直接发给目标服务器，而是先交到 Fiddler 手里，再由 Fiddler 转发给真正的服务器；服务器返回的数据同样先回到 Fiddler，再由它传回给客户端。这就是它能看清所有流量的根本原因。
这里就引出一个关键问题：普通 HTTP 流量是明文传输，Fiddler 截获后直接能看；但 HTTPS 流量是加密的，Fiddler 凭什么能解密？答案是证书机制。Fiddler 在本地生成了一张根证书，当你信任并安装这张证书后，Fiddler 会在你和服务器之间扮演这样一个角色：它用自己伪造的证书跟你建立加密连接，同时用它手上的真实信息和服务器建立另一条加密连接。你发给服务器的数据，Fiddler 先解密、再重新加密转发；服务器返回的数据，Fiddler 同样先解密再加密传给你。你信任了 Fiddler 的根证书，就当它不存在一样，全程数据对它透明。
这个机制听起来有点“偷窥”的味道，但它是完全合法的本地调试手段，只作用于你自己的设备和流量，不会影响任何其他人的数据安全。搞懂这一点，后面配置 HTTPS 解密时你就能理解为什么要安装证书，为什么有的 App 会检测到“中间人”并拒绝通信。
2. 环境准备与第一次抓包配置
2.1 版本选择：Fiddler Classic 还是 Fiddler Everywhere
第一次下载 Fiddler 的人通常会被两个版本搞迷糊：Fiddler Classic 和 Fiddler Everywhere。Fiddler Classic 是老牌的 Windows 桌面应用，免费开源，界面朴素，但胜在稳定、轻量、文档多。Fiddler Everywhere 则主打跨平台，支持 Windows、macOS、Linux，界面更现代，但要付费订阅。我的建议很直接：如果你主要用 Windows 电脑做测试，Fiddler Classic 完全够用，网上绝大多数的教程和踩坑经验也都基于 Classic 版本；如果你需要在 Mac 上抓包或者团队需要协同共享抓包记录，再考虑 Everywhere。
安装时还有两个细节值得注意。第一，安装路径不要带中文和空格，否则个别版本的证书导入和命令行工具会出问题。第二，安装完成后如果系统提示“是否安装证书”或者安全软件弹窗拦截，不要急着点掉，后续我会细说证书怎么处理。Fiddler 安装完成后，默认会弹出主界面，左侧是会话列表，右侧是功能面板。第一次打开不用慌，先按下 F12 键确认底部状态栏显示 Capturing 状态，这才是正常工作状态。
2.2 打开 HTTPS 抓包开关：Tools > Options 配置
Fiddler 默认只能看 HTTP 流量，如果不做任何设置，所有 HTTPS 请求都会显示成灰色隧道，点开也看不到内容。要让 Fiddler 解密 HTTPS，需要手动开启开关。进入 Tools > Options > HTTPS，勾选 Capture HTTPS CONNECTs 和 Decrypt HTTPS traffic，弹出证书信任提示时点 Yes。这里有个大部分人都踩过的坑：勾选完只对新建的会话生效，已经存在的会话不会自动解密。我每次配置完都会顺手关掉再重新打开一次浏览器，让所有连接重建，确保后面的抓包记录都是可读的。
证书安装成功后，Windows 会提示导入到“受信任的根证书颁发机构”。如果安装时不小心点掉了，可以在 Fiddler 的 HTTPS 设置里点击 Export Root Certificate to Desktop，把证书导出为 .cer 文件，然后双击这个文件手动安装到“本地计算机 > 受信任的根证书颁发机构”中。安装完证书后重启浏览器和 Fiddler，这一步能解决绝大多数 HTTPS 抓包看不到内容的问题。
2.3 手机端抓包：Android 与 iOS 配置要点
PC 端配置好之后，抓手机 App 的流量才是 Fiddler 最有价值的场景之一。配置思路很简单：电脑和手机连同一个局域网，在手机 WiFi 设置里把 HTTP 代理指到电脑的 IP 和 Fiddler 的端口（默认 8888）。比如电脑 IP 是 192.168.1.100，那手机代理就填 192.168.1.100，端口 8888。电脑网络IP查询用 ipconfig，Mac/Linux 用 ifconfig 或者 ip addr。
Android 用户的坑主要在证书信任上。Android 7.0 之后，系统默认不再信任用户安装的 CA 证书，所以很多 App 就算你装了 Fiddler 证书，它依然会拒绝连接，报错提示类似“无法与服务器建立安全连接”。解决办法有三种：如果你的测试机是 root 过的调试机，可以把证书复制到系统证书目录 /system/etc/security/cacerts/ 然后重启；如果你用的是可以解锁 Bootloader 的手机，可以刷入带证书的 Magisk 模块；如果你只是日常测试普通的网页和少数不校验证书的 App，装用户证书也能顶上。iOS 端相对友好一些，安装证书后需要去“设置 > 通用 > 关于本机 > 证书信任设置”里，把 Fiddler 证书的开关打开，否则 Safari 和部分 App 会弹“证书无效”的警告。
还有一个好用的小技巧：Android 模拟器访问宿主机的 IP 要用 10.0.2.2。我早期在模拟器里抓包一直不通，折腾半天才发现模拟器的 localhost 指向的是它自己，不是宿主机电脑。换成 10.0.2.2 后，代理配置立刻生效。
2.4 验证抓包链路有没有打通
配置好环境后，第一件事不是急着看数据，而是验证链路是否真正打通。在 PC 端验证很简单，浏览器访问几个常用网站，回到 Fiddler 看会话列表是否出现大量条目，再双击一条 HTTPS 请求看 Inspector 里是否能看到完整的请求头、响应头和响应正文。如果能看到，说明 HTTPS 解密成功。
手机端验证稍微复杂一点。手机连上代理后，打开浏览器访问一个 HTTP 网站，例如 http://neverssl.com，看 Fiddler 是否出现手机发出的流量。如果手机流量没出现，先检查手机和电脑是否在同一网段，然后看电脑防火墙是否拦截了 8888 端口。Windows 上第一次运行 Fiddler 时通常会自动弹出防火墙授权窗口，如果不小心点了取消，去“控制面板 > Windows Defender 防火墙 > 允许应用通过防火墙”，把 Fiddler 加入允许列表，并且一定要把“专用”和“公用”两个复选框都勾上，否则手机从外部网络访问时流量会被挡在门外。
链路验证通过之后，还需要设置一个卫生习惯：不用 Fiddler 时，把手机上的手动代理删掉，或者直接退出 Fiddler。我见过很多新手抓完包忘了关代理，结果手机所有 App 都无法上网，还以为手机坏了。
3. 抓包后的日常操作：会话列表、检查器与命令行
3.1 看懂会话列表：状态码、图标与排序
Fiddler 左侧的会话列表是日常最常盯着看的地方。每一行代表一个请求会话，列名包括 Result（状态码）、Protocol（协议）、Host（主机）、URL（路径）、Body（响应大小）、Caching（缓存）、Content-Type（内容类型）。状态码是最先需要培养敏感度的：2xx 代表成功，4xx 代表客户端错误，5xx 代表服务端错误。这里面有几个高频场景：看到 404 先检查 URL 路径是否正确；看到 401/403 优先怀疑 token 过期或权限不足；看到 500 则大概率是后端代码异常，抓包记录直接甩给后端同事，省去一长串的口头描述。
会话列表顶部的图标也有讲究。蓝色双向箭头表示普通 HTTP/HTTPS 请求；灰色的隧道图标表示 HTTPS CONNECT 握手，这个隧道本身不包含可读内容，真正的加密数据会在隧道下面的子会话里展示；红色的感叹号图标通常表示请求出错，比如证书校验失败、连接被拒绝，这些都是调试时最先需要关注的对象。排序列我建议把时间和耗时列加进去：右键列表头部空白处，选择 Customize Columns，把 Server IP 和 Time Taken 加进来，定位接口慢的问题特别好用。
3.2 Inspector 检查器：最常用的几种视图
双击会话列表里的任意一条记录，右侧会弹出 Inspector 面板，上半部分是请求检查器，下半部分是响应检查器。检查器里的视图模式很多，但日常用得最多的是这几个：Headers 看当前端到端的请求头、Cookie、Token 等信息；TextView 和 WebForms 适合看表单参数和纯文本响应；JSON 视图直接格式化 JSON 数据，接口联调时看这个最舒服，不用再复制到其他工具里格式化；Raw 视图看最原始的数据流，当 XML 或自定义格式解析不对劲时可以切到这个模式找原因。
我调试接口问题有个固定套路：先切到 JSON 视图看响应体是不是符合预期结构，再看 Headers 里的 Content-Type 和 Set-Cookie，最后看原始请求的 body 是否和后端接口文档一致。有一次前端同事说“接口返回了我看不懂的错误码”，我抓包后把响应的 JSON 一格式化，发现根本不是什么错误码，是请求头里少传了一个 X-App-Version 字段，导致后端走了旧逻辑分支。抓包的价值就在于把这种“双方各执一词”的问题，迅速转换成一段黑白分明的数据证据。
3.3 QuickExec 命令行：日常调试的加速器
Fiddler 底部有一条黑色的 QuickExec 命令行，很多老手都忽略了它，但它其实是我日常操作频率最高的入口。命令行语法简洁，输入后回车立即执行。我用得最多的几个命令如下：
- bpa + 关键字：在 URL 包含该关键字的请求上设置断点，暂停请求发出前；再次输入 bpa 不加关键字取消。
- bps + 状态码：在指定状态码的响应上设置断点，用于拦截 404、500 等异常响应。
- bpu + 关键字：只对包含关键字的 URL 设置请求断点，比 bpa 更精细。
- cls：清空左侧会话列表。
- ? + 字符串：筛选 URL 中包含该字符串的会话。比如输入 ?login，列表就只剩下带 login 的请求。
- select + 内容类型：筛选指定类型的响应。select json 能快速把所有 JSON 响应挑出来。
命令行看着不起眼，但在你连续调试几十个接口时，它的效率优势立刻显现。鼠标点半天 Filters 还不如敲一条命令来得快，这也是我建议新手从第一天就养成命令行习惯的原因。命令行标准格式是直接在底部输入框敲命令，回车后生效，不需要加斜杠，这一点和很多工具的命令行习惯不太一样，别搞混了。
4. 接口调试与 Mock：Composer、AutoResponder 与断点
4.1 用 Composer 手动构造请求
Composer 模块可以让你完全绕过页面，手动构造一个 HTTP 请求发给服务器。这在测试接口入参异常、复现线上 Bug、快速验证后端接口是否有问题时特别实用。进入方式有几种：点工具栏上的 Composer 标签，按 Ctrl+R，或者在会话列表里右键一条记录选择 Replay > Reissue，修改里面的参数后发送，基本思路都一样。
Composer 界面支持 Parsed 和 Raw 两种输入模式。我建议新手先用 Parsed 模式：把请求方式选成 POST，填上 URL，在 Request Headers 区域把默认的 User-Agent、Content-Type 写入，然后在 Request Body 区域填 JSON 或表单数据。注意，如果接口要求 Content-Type: application/json，那 body 区域必须是标准 JSON 字符串，同时 Header 里的 Content-Type 也要对应，这两个不匹配时后端很容易解析失败，返回 415 或 400。
用 Composer 还有一个很省时间的场景：在会话列表里右键一条 POST 请求，选择 Replay > Reissue Unmodified，Fiddler 会用完全一样的参数重新发送一次请求，用于确认是不是偶发性问题。如果修改后再发送，就用 Replay > Reissue and Edit，或者直接拖拽会话到 Composer 标签里，参数会自动填好。这个方法在做接口幂等性测试、重放攻击验证时特别顺，比自己去 Postman 里重新填一堆参数高效得多。
4.2 用 AutoResponder 做本地 Mock 与响应替换
AutoResponder 是 Fiddler 里最能提升幸福感的功能之一。它可以拦截匹配规则的请求，然后直接返回你指定的内容，完全不用经过真实服务器。典型场景是：后端接口还没开发完、测试环境不稳定、某些错误态难以触发，前端又急着联调，这时候 AutoResponder 就能把不可能变成可能。
操作步骤：先正常抓一次目标接口，右键这个会话选择 Save > Response > Save Entire Response，把响应保存成本地文件；然后在 AutoResponder 标签页勾选 Enable rules，把该会话拖进去，规则会自动生成类似EXACT:http://api.example.com/order/list的匹配表达式；右侧 Rule Editor 里把行动改为*redir:file路径，或者直接在本地选择一个模拟响应文件。
这里我强烈建议用regex:开头做模糊匹配，而不是用 EXACT 精确匹配。因为接口地址里通常带着时间戳、token 等动态参数，精确匹配很容易失效。比如规则写成regex:.*/api/order/list.*，就能匹配所有以这个路径结尾的请求，不管查询参数怎么变都能命中。匹配规则和行动之间是“条件-动作”的关系，几个常见动作如下：
*redir重定向到指定 URL 或文件。*delay:500模拟该请求延迟 500 毫秒后返回。*flag给匹配的会话打标记，用于调试确认规则是否生效。*drop直接把请求丢弃，模拟服务端无响应。
最后一步，记得在 AutoResponder 界面下方勾选 Unmatched requests passthrough，这样不匹配规则的请求还是正常转发，不会被拦住。如果不勾，所有其他请求都会被卡住，页面直接瘫痪，我第一次用的时候就在这上面吃了亏。
4.3 断点修改请求和响应
AutoResponder 能满足“静态替换”需求，但如果你想动态地改请求参数再放行，或者手动篡改响应看前端表现，就该用断点功能。Fiddler 的断点分为请求断点和响应断点两种。请求断点在请求发出前拦截，你可以修改 URL、Headers、Body 后再点 Run to Completion 放行；响应断点在服务器返回后、客户端接收到之前拦截，你可以改响应状态码、响应头、响应体，再造出一种“假的成功”或“假的失败”场景。
快速设置断点用命令行最省事：bpu login 代表只对 URL 里带 login 的请求设置请求断点，bpafter 加响应关键字设置响应断点。也可以去菜单 Rules > Automatic Breakpoints 里选择 Before Requests 或 After Responses，但那是全局断点，会把所有请求都拦住，调试时烦得很，不如命令行精准。断点命中后，请求会话会变成红色停止状态，双击打开 Inspector 编辑完，点绿色按钮 Run to Completion 继续放行，点蓝色按钮直接丢弃这次请求。
这种动态改包能力在做异常场景测试时是神器。比如我要测前端对“余额不足”提示的展示，而当前账号余额充足，正常流程根本触发不了这个分支。我就在响应断点里把响应 JSON 里的balance: 100改成balance: 0，同时把 status 改成对应的错误码，重新放行后前端立刻进入余额不足的提示逻辑。整个过程不需要改任何后端数据，也不需要等测试环境造数据，十分高效。
5. 高频问题排查：抓不到包、HTTPS 异常与手机连不上
5.1 抓不到包？按这个顺序排查
“Fiddler 开了但什么都抓不到”是评论区和读者提问里最多的一类问题。我按出现频率从高到低给你排个排查顺序，照着做基本都能解决。
先看状态栏是否显示 Capturing。很多人以为打开 Fiddler 就开始抓了，实际上可能误按了 F12 暂停了抓包，状态栏会从 Capturing 变成 Not Capturing，这时候一条流量都进不来。再看系统代理是否被设置为 Fiddler 的 8888 端口。有些浏览器装了代理插件（如 SwitchyOmega）会把代理固定指向某个地址，不跟随系统代理，这种情况下浏览器流量会绕过 Fiddler，你得在插件配置里加一条规则让目标网站也走 127.0.0.1:8888。
接着看会话列表的 Filters 是否过滤掉了内容。Filters 面板里如果勾选了 Use Filters 且 Host 过滤条件写得不全，某些域名就会被隐藏，表现就是“明明访问了，列表里却没有”。最后还要考虑浏览器是否启用了 QUIC 协议，也就是 HTTP/3。HTTP/3 走的是 UDP，Fiddler 默认只监听 TCP 的 HTTP 流量，所以面对启用了 HTTP/3 的网站（比如谷歌系站点），Fiddler 会直接抓不到内容。临时解决办法是在浏览器地址栏输入 chrome://flags，搜索 QUIC 并禁用，或者换一个不用 HTTP/3 的测试地址。把上述五项按顺序检查完，抓不到包的场景我碰到的几乎都能解决。
5.2 HTTPS 显示灰色或证书报错
如果你的会话列表里 HTTPS 请求全是一条条灰色隧道，点开没有内容，大概率是 HTTPS 解密没开启或证书没装成功。重新去 Tools > Options > HTTPS 里确认 Decrypt HTTPS traffic 是勾选状态，然后点 Export Root Certificate to Desktop 导出证书，在系统里双击安装到“受信任的根证书颁发机构”，再重启浏览器。这一步能解决大部分灰色隧道问题。
如果证书安装成功但还是报错，比如浏览器提示“证书不受信任”或者 App 直接断连，那就要考虑两个原因：一是安全软件拦截了 Fiddler 的证书注册，360、火绒、公司统一装的安全管控软件都干过这种事，检查安全软件的证书拦截或信任列表；二是某些 App 做了 SSL Pinning，也就是把服务器的证书指纹写死在代码里，Fiddler 的证书不在信任名单内，连接就被主动掐断。面对 SSL Pinning，常规 Fiddler 配置解决不了，只能借助专门的抓包框架或者改 App 的调试配置，这已经是另一个技术层面的问题了。
5.3 手机连不上 Fiddler，流量为 0
手机端问题可以分成两类。第一类是手机能上网但 Fiddler 里看不到手机流量，排查顺序是：确认电脑和手机连的是同一个 WiFi 且没有开启 AP 隔离；确认手机代理 IP 填的是电脑在局域网里的实际 IP，不是 127.0.0.1，手机里的 localhost 指向手机自己；确认电脑防火墙放行了 8888 端口。第二类是手机设置代理后完全无法上网，这通常是因为代理指向错误或 Fiddler 没在运行，删掉代理设置恢复网络后，再重新按正确步骤配置。
Android 7.0 及以上还有一个特殊的证书信任问题：普通 App 不信任用户级证书，即使你装了 Fiddler 证书，App 请求照样失败。排查时可以先在手机浏览器里访问一个 HTTP 网站，如果浏览器能出包而 App 不能，那基本就是证书信任或 SSL Pinning 问题，而不是链路配置问题。日常测试工作里，我建议 Android 组专门留一台 root 过的公共测试机，装上系统级证书，能省掉大量因安卓版本差异而导致的抓包时间浪费。
5.4 几个能明显提升效率的小习惯
最后分享几个我自己用下来的高效习惯，不算什么高深技巧，但确实能让日常抓包体验舒服很多。
第一，合理使用 Filters。在左侧 Filters 面板勾选 Use Filters，把 Host 填成当前要调试的域名，这样其他噪音流量全部被滤掉，会话列表干干净净，眼睛不累，排查问题也快。第二，学会用 Statistics 面板看性能。选中一条请求，点 Statistics 标签，能直接看到 DNS 解析时间、TCP 连接时间、请求发送时间和响应接收时间。接口慢的时候，先用这个定位慢在哪个环节，再决定找网络、找前端还是找后端，别上来就一顿人肉排查。第三，养成保存会话的习惯。File > Save > All Sessions 可以把当前所有抓包记录保存成 .saz 文件，遇到线上疑难问题先存一份，再慢慢分析。第四，没事就清一下会话列表。长时间挂着 Fiddler，列表里堆几百上千条记录，想找目标请求会很折磨，用命令行敲个 cls 或者按 Ctrl+X 一键清空，清爽得多。第五，把常用断点和 Mock 规则沉淀下来。一个项目调试阶段常用的 AutoResponder 规则、过滤条件、命令行片段，我会写进项目 wiki 里，换台电脑或者新同事接手时直接抄作业，省得重复摸索。
我个人在实际操作中最深的体会是：抓包工具不是用来“看”的，而是用来“证”的。每次遇到前端后端互相甩锅、线上问题复现不了的情况，我的第一反应永远是打开 Fiddler 抓一条完整记录，把请求参数、请求头、响应状态码、响应体原样截图扔到群里。一条记录出来，绝大多数争论都会迅速降温，问题边界直接清晰。这个经验我受用多年，也希望你用上 Fiddler 之后，能少走这些沟通弯路。
