干这一行久了就会发现电脑里装得再满的工具箱真正每天熟练打开的可能也就那么几个。对我这种主要跟接口、页面、数据打交道的人来说抓包工具就是其中之一而 Fiddler 又是其中最顺手的一个。标题里的“Fildder”其实是 Fiddler 的手滑写法搜的时候别被带偏了。这篇文章写给刚入门的测试、前端和运维同学也写给那些已经装了 Fiddler 但只会在界面上看个响应码的人。我会从抓包工具的工作原理讲起再从安装、HTTPS 解密、手机抓包到请求重放、断点、弱网模拟这些实战操作一步步把 Fiddler 这个工具拆开揉碎讲清楚。你跟着做一遍基本就能应付日常 80% 的调试需求。1. Fiddler 是个什么样的抓包工具1.1 一句话说清楚它到底干了什么事Fiddler 本质上是一个本机代理工具。它在你的电脑上开启一个监听端口默认是 8888所有走了这个代理的 HTTP/HTTPS 请求都会先经过 Fiddler再由它转发给真正的服务器。响应回来时也一样先经过 Fiddler再送回给客户端。也就是说它站在客户端和服务器之间像个透明的裁判把两边交换的数据全部记录了。我经常拿快递中转站做类比。你下单买了个东西卖家如果没有直接把货送给你而是先发给一个中转站中转站拆开检查、拍照存档再重新打包送到你手上——那你不仅能知道包裹里是什么还能知道它什么时候发出来的什么时候到的。Fiddler 就是这个中转站只是它管的是网络请求。理解了这一点后面所有操作你都不会再晕因为你做的所有配置本质上都是在跟这个“中转站”说什么流量要过你什么流量不过你过你的时候要不要检查、要不要篡改。1.2 为什么它让你既看得到数据也看得懂数据抓包工具不少但 Fiddler 有自己很明显的优势。它把强项做在了 HTTP 协议上而今天不管是 Web 前端、小程序、App、还是混合应用底层网络通信大部分依然是 HTTP/HTTPS。你只要能抓到这一层的数据就可以排查大部分请求参数、响应结果、状态码、响应时间的问题。Fiddler 的界面虽然最初看起来有点“程序员味”但功能分区其实特别直接左侧是会话列表抓到的所有请求都按时间排在这里右侧上方是请求详情下方是响应详情再往右还有断点、AutoResponder、弱网模拟这些高阶操作面板。不像某些工具要把功能藏得很深Fiddler 的关键入口基本都是可见的你哪怕只摸过一两次也能找到想找的东西。还有一个被很多人忽略的点Fiddler 自带脚本能力可以让你按规则自动修改请求或响应甚至可以写一套自动化校验逻辑。这一点我后面会专门讲因为它不是炫技是真能省下你大量重复操作的时间。2. 安装、启动与第一次抓包2.1 下载、安装和版本选择的那些坑关于抓包工具 Fiddler你搜的时候会看到两个容易混淆的名字Fiddler Classic 和 Fiddler Everywhere。前者是传统的 Windows 桌面版轻量、启动快、一直免费其实对绝大多数测试场景已经够用了后者是跨平台版本界面新一些支持 Windows、macOS、Linux但免费版有配额限制很多高级功能要走付费或者订阅才能舒服地用。我个人建议如果你主要用 Windows 且是新手直接装 Fiddler Classic 就好。安装过程没什么特殊选项一路默认。唯一要注意的一点是它默认会修改系统代理设置。装完以后你打开任意浏览器访问网页Fiddler 列表里会立刻出现一堆请求这说明它已经接管了你的网络流量。如果你打开 Fiddler 却一个请求都没有大概率是系统代理没被设置上或者你用了某些不读系统代理的程序。另外第一次启动时如果弹窗提示“Windows 防火墙”允许访问建议放行。不然 Fiddler 可能只能监听本机手机或者其他设备连不上你的代理端口后面抓手机包的时候你会被卡住。2.2 第一次打开 Fiddler 应该先盯哪几个地方启动后你会看到一个默认界面顶部是工具栏左侧是会话列表右侧是功能页签。第一次上手我建议你别急着乱点先设置好久没变过的几个基础项菜单栏 Tools - Options - HTTPS勾选 Decrypt HTTPS traffic弹出的证书信任提示选择“是”再切到 Connections确认监听端口是 8888并勾选 Allow remote computers to connect。这两个配置是后续抓 HTTPS 包和抓手机包的基石。设置完以后回到左侧列表随便访问一个 https 网站你会看到一条条会话记录每条前面有一个小锁图标说明这条请求被成功解密了。双击任意会话右侧会分成上下两块上面是请求的 Headers、Body、Cookies下面是响应内容。你可以在这里直接看到接口返回的 JSON不需要再去浏览器控制台翻半天。别忘了试试最常用的右键菜单Copy - Headers 可以快速把请求头复制成各种格式Save - Response 可以把响应保存成文件。这些都是帮你减少重复工作的细节操作做了几次你就知道了。3. 核心配置HTTPS 解密和手机真机抓包3.1 为什么要装证书不装行不行很多人第一次开抓包工具发现 HTTP 请求都能看到一碰到 HTTPS 就只看到一串 CONNECT然后抓不到具体内容。这不是 Fiddler 不行而是 HTTPS 本身就是加密的Fiddler 的代理功能只能看到加密前的原始流量要想看到明文必须让它成为客户端信任的“中间人”。这个操作就是安装 Fiddler 生成的根证书。装上证书后Fiddler 会给每个 HTTPS 连接动态生成一份它自己的证书替代服务器证书客户端的请求先发给 FiddlerFiddler 解密后再以真正的客户端身份连服务器服务器返回的数据 Fiddler 先解密再用自己的证书加密发给客户端。因为客户端信任了 Fiddler 的根证书整个流程就能顺畅跑通。这就是为什么你要在 Tools - Options - HTTPS 里勾选 Decrypt HTTPS traffic。第一次勾选时 Fiddler 会弹窗提示确认后它会把证书装到系统里。你可以在 Options - HTTPS 里找到 Certificates 按钮点击后用“导出证书到桌面”的方式备份一份特别适合你要给手机安装的时候用。3.2 手机、模拟器抓包从同步证书到设置代理手机抓包是测试人员的高频需求但也最容易踩坑。先说标准流程第一确保手机和电脑连接同一个局域网第二在 Fiddler 的 Options - Connections 里确认 Allow remote computers to connect 是勾选状态第三用电脑的局域网 IP命令行输 ipconfig 能看到加上端口 8888作为手机上的代理地址。这里要处理一个很多人忽略的细节手机还需要安装并信任 Fiddler 的根证书。简单做法是在手机浏览器里访问电脑代理地址的“下载证书页面”。比如你电脑的 IP 是 192.168.1.100那就在手机浏览器里访问http://192.168.1.100:8888点击页面上的 FiddlerRoot certificate 链接下载后安装。iOS 系统安装完还要到“设置 - 通用 - 关于本机 - 证书信任设置”里手动开启信任开关不少人的手机抓包失败就是卡在这一步。Android 和 iOS 还有一个隐藏问题高版本系统的 App 不再信任用户安装的证书。如果你的 App 只信任系统证书那即使你装了 Fiddler 证书也解不开包。这属于应用层的安全策略并非 Fiddler 问题。遇到这种情况一种方式是使用 Android 7.0 模拟器配合可调试的应用另一种是看 App 是否开启了网络安全配置信任用户证书。但这些都是应用侧的限制需要开发配合才能解决。3.3 为什么 localhost 和本机流量抓不到还有一类高频问题Fiddler 明明开着但你在浏览器里访问http://localhost:8080列表里却找不到请求。原因是大多数浏览器对 localhost 地址默认不走系统代理。Fiddler 自己也清楚这一点所以提供了一个特殊域名把localhost改成localhost.fiddler请求就会自动被 Fiddler 接管。这个方法用起来很省心调试本地服务时特别常用。如果你不想改 URL也可以试试勾选 Tools - Options - Connections 里的 “Use PAC script” 之类的选项或者直接把 Fiddler 的监听代理固定成127.0.0.1:8888再手动配置到客户端。不过最让我省心的还是改 URL 的办法几乎零成本记下来就行。4. 进阶玩法APICloud 调试和生产回归必备的几把刷子4.1 断点调试让请求停在你想要的时刻Fiddler 的断点功能是我觉得它比大多数抓包工具更“变态”的地方。你可以让请求停在发出之前也可以让响应在返回途中被拦住然后在界面上直接改数据再放行。比如我想测试前端对金额字段的展示后端明明返回 100但我临时把响应里的金额改成 10000就能立刻看到页面崩没崩。这比反复让后端改数据、等发布要快得多。操作也很简单菜单栏里的 Rules - Automatic Breakpoints选 Before Requests 就是拦截请求选 After Responses 就是拦截响应。更精细的做法是在 QuickExec 框里输入命令比如bpu /api/order表示只对 URL 里包含/api/order的请求打断点这个命令是 Fiddler 老玩家的日常操作比全局断点好用得多不会打断其他无关请求。4.2 AutoResponder把后端按在地上摩擦的模拟神器AutoResponder 面板是我提过很多次的功能它可以把一个请求直接映射到另一个响应实现“假接口真调试”。比如后端还没开发完但前端页面已经写好了只需要接口返回固定数据。传统做法是本地起一个 Mock 服务但有了 AutoResponder你连 Mock 服务都可以省用 Fiddler 抓一次真实接口或随便一个请求拖到 AutoResponder 面板勾选 Enable rules 和 Unmatched requests passthrough然后修改 Response Body 为 JSON 文件内容前端请求来时就会直接命中你预设的响应。这个方案对测试也很有用。回归测试时如果某个第三方接口不稳定你可以临时把响应改成固定值避免因为外部依赖把用例跑挂。它真的是抓包工具里最被低估的功能之一很多人根本没动过。还有个小技巧AutoResponder 支持正则匹配 URL所以你可以对某个路径下的所有请求统一返回同一个模拟数据。这在做故障演练、压测联调时尤其高效。4.3 Composer手工构造请求模拟各种边界状态左侧工具栏里有个 Composer 页签在里面可以手工输入请求方法、URL、请求头、Body点击 Execute 直接发出去。这个功能的本质是一个轻量级的接口调试工具不需要你额外打开 Postman。尤其当你已经抓到了一条线上真实请求想在它基础上改一个参数试试直接把原始会话拖到 Composer 里改掉想要的位置再 Execute整个过程不超过五秒。用多了你会形成一种习惯遇到接口报错先抓包看原始请求长什么样然后拖到 Composer 里把参数改得极端一点比如传一个超长字符串、传负数、传空对象看后端会不会崩溃。这是做前后端边界测试最顺手的路径。4.4 弱网模拟让页面在慢网络下现形弱网测试是移动端和 Web 端都绕不开的需求Fiddler 里也有现成的入口。在工具栏找到 Simulate Modem Speeds 这个开关勾上以后 Fiddler 会人为延迟所有请求的响应时间。虽然这个延迟数值不一定等同于真实运营商网络但用来验证页面的加载状态、超时处理、Loading 展示是够用的。如果你想要更精准的弱网参数比如只延迟图片请求、或者模拟 3G 网络的丢包就需要修改脚本了。打开 FiddlerScript菜单 Rules - Customize Rules搜索 OnBeforeRequest 或 OnBeforeResponse在函数里加入延迟逻辑。比如在OnBeforeResponse里针对某些 MIME 类型设置System.Threading.Thread.Sleep(2000)就能只对这个类型的资源增加 2 秒延迟。理解了这个思路你甚至可以自己做出自定义弱网策略。5. 抓不到包、解密失败、乱码问题排查实录5.1 最常见的五个“废人操作”和三分钟急救法我见过太多人第一次用抓包工具就差点劝退但复盘下来基本都是小问题。我建议你按这个顺序排查先看系统代理是否生效。最简单的方法是关掉 Fiddler看浏览器还能不能正常上网。如果不能十有八九是代理残留去系统代理设置里清掉。再看 Fiddler 左下角是否显示Capturing如果没开启会话列表就是空的点一下右下角的按钮即可。接下来看 HTTPS 会话是不是只有 CONNECT如果是回到 Tools - Options - HTTPS 勾选 Decrypt HTTPS traffic并确认证书已安装。如果手机设备连不上就检查电脑防火墙是否放行 8888 端口以及手机和电脑是不是同一网段。这套排查流程我屡试不爽。抓包工具没抓到包90% 以上都是这三个点出错代理没走对、证书没装好、端口或网段隔离。5.2 证书失效、乱码和重定向问题的处理经验证书类的坑比较隐蔽我单独拎出来说。Fiddler 的根证书是有有效期的用了一段时间后可能过期手机或者浏览器显示“证书无效”。解决办法是在 Tools - Options - HTTPS - Actions 里重置证书Reset Certificates重置后记得重新在电脑和手机上安装一次。另一个让人烦躁的问题是抓到的响应中文乱码。这通常不是 Fiddler 的问题而是显示了原始字节流没有按正确的字符集解码。你可以在右侧 Inspectors 里切换到 Raw 标签或者在 TextView 下方选择正确的编码比如 UTF-8。如果接口返回的是压缩过的 gzip 内容需要确认 Fiddler 是否自动解压了。一般来说它自己会处理但如果你在响应里看到一堆二进制乱码那就是没解压成功。可以检查一下请求的 Accept-Encoding 头把 gzip、br 这些压缩格式暂时去掉再试。重定向问题也常见。你抓到一条 302 响应想知道它到底跳到了哪可以在 Inspectors 的 Headers 里查看 Location 字段然后在 Composer 里手动跟着跳或者直接在会话右键选 ReplayFiddler 会自动重新请求新的地址。5.3 有些应用不走系统代理怎么办最后聊一个进阶问题不少桌面应用、命令行工具、或者一些安全要求很高的 App会忽略系统代理设置。这就意味着你把 Fiddler 开着它也走自己的直连通道你自然什么都抓不到。针对这类场景思路是让流量强制经过 Fiddler。在 Windows 上你可以尝试将应用依赖的 HTTP 连接重定向到本机代理比如在启动命令里设置环境变量http_proxyhttp://127.0.0.1:8888、https_proxyhttp://127.0.0.1:8888大部分基于标准网络库的应用都会遵守这个变量。如果你要抓的是手机 App且它绕开了代理那就要看 App 是不是做了代理检测。我不建议一上来就折腾检测绕过这样的复杂方案因为很多 App 之所以检测代理是为了不放行明文中间人流量强行绕过去效率低且可能违反使用原则。自己公司的测试包一般可以要求开发给一个“可调试”的版本或者提供允许代理的模式这比逆向环境更稳妥。6. 把这些技能串成一个测试习惯6.1 每一次上线前用 Fiddler 做一次“请求体检”老测试人都会有自己的一套上线前检查动作我的习惯里有一环是用 Fiddler 做快速体检。打开抓包工具清空会话列表然后完整走一遍核心业务链路比如从登录、首页、列表页到提交订单。走完以后按 URL 分组看一遍所有请求重点检查几个地方有没有重复请求有没有无意义的图片资源有没有接口状态码异常响应体大小是不是超出了正常范围。这个动作能发现很多自动化用例漏掉的问题比如某个页面加载时调了十个一样的查询接口又比如有一张图片超了 5MB。你不会希望用户把你的 App 当内存大户用到发烫。Fiddler 的统计面板能直接告诉你每个请求的传输大小和耗时配合左侧列表的耗时排序一分钟就能定位性能瓶颈。6.2 配合 Postman 和自动化测试放大抓包价值很多人把抓包工具和其他接口工具当成两个独立软件其实它们应该配合起来。我在用到 Fiddler 时的一个习惯是先在 Fiddler 里抓一条成功的请求右键导出成 HAR 文件再在 Postman 里导入这条请求转成日常调试参数。HAR 文件包含完整的请求头、请求体和时间线导入到 Postman 后连 Cookie 都给你带进去省掉了手工录入一大堆请求头的时间。做自动化测试也一样。我写接口自动化脚本时用例里的参数很多时候不是拍脑袋造的是从 Fiddler 抓到的真实流量里抽出来的。你只有见过系统真实产生的数据长什么样才可能写出一份贴近生产的测试用例。而且通过 Fiddler 的会话筛选你可以按域名、状态码、耗时这些维度快速找到高风险接口再针对它们做专门的数据驱动测试。6.3 定期清理证书和代理设置避免程序后遗症当然也要提醒几个善后问题。Fiddler 用久了可能在系统里留下过期的证书和残留的代理设置。尤其是你曾经用 Fiddler 做过 HTTPS 解密后来又卸载了软件但浏览器可能依然在信任一个不存在的根证书导致上网时出现证书警告。正确做法是重装或升级 Fiddler 后重新安装证书确定不再使用抓包工具时在 Fiddler 里通过 Options - HTTPS - Actions - Remove Certificates 清掉证书并关闭系统代理。如果实在已经卸载了软件但代理还残留就去系统的“Internet 属性 - 连接 - 局域网设置”里把代理服务地址清空。这些都是很基础但很容易被忽略的事花不了几分钟但能避免几天后的莫名网络故障。最后再分享一个小技巧如果你经常抓某个系统的包可以先用 Filter 面板设置域名过滤只显示你关心的主机。比如只填一个example.com左侧会话列表就再也不会被百度和新闻的请求淹没。等你熟练了这个工具会发现它不只是“抓包”更像是一面镜子把系统的真实行为和隐藏问题清清楚楚地照出来。我的经验是工具功能可以一点一点学但最好从第一次用它解决问题的那一刻起就养成带着疑问去抓包的习惯。多抓几次很多网络调试的直觉自然就有了。