Fiddler断点改包与AutoResponder伪造响应实战

一个接口在页面里返回的数据永远少一个字段后端说自己测着是好的前端说自己拿到的就是没有——这种扯皮光靠只读抓包工具是断不了案的。你需要的是把一个 HTTP(S) 请求在半路上按暂停、随手改写、甚至凭空捏造一个响应的能力Fiddler 在数据包拦截、断点、改包、伪造与自动响应这一整套能力上恰好就是一个可以随时介入的沙盘。这篇文章不讲安装、不讲界面汉化只讲我从实际联调和排障里总结出来的干预手法请求断点和响应断点分别在链路的哪一环卡住、命令行怎么把断点打准、改完包为什么浏览器会转圈、AutoResponder 配好了却不生效到底卡在哪、以及什么时候该用脚本而不是鼠标。适合已经能抓到包、但还没把 Fiddler 用出手术刀感觉的前端、后端、测试和做客户端联调的同学新手跟着做也能一步步跑通。1. 从看到改抓包工具的分水岭在哪1.1 只读抓包能回答的问题和回答不了的问题只读抓包擅长回答发生了什么请求发出去了吗、Header 带了什么、响应体长什么样、状态码是多少、耗时分布如何。这些在排查接口 500、定位慢请求、确认参数有没有传对的时候已经够用了。但只要你遇到下面这三类问题只读抓包就彻底失效。第一类是我要复现别人的现场。前端同学说后端返回的某个字段偶尔是 null导致页面白屏。你抓了十次包十次都是正常的。这时候你需要主动把那个字段改成 null看页面到底会不会崩、崩在哪一行——这属于人为制造异常只读工具做不到。第二类是后端接口还没好但我得先往下走。前端要联调一个还没发布的接口测试要写用例但服务还没部署。这时候你需要凭空造一个响应出来让调用方能拿到符合约定的数据。第三类是我要在某一个请求上停下来慢慢看。比如怀疑某个请求的 token 是用旧的你需要把它卡住对比它和另一个正常请求的差异甚至把它复制出来单独重放。这三类问题的共同点是你不满足于观察你要干预。Fiddler 的断点、改包、伪造、自动响应本质上就是四种不同粒度的干预手段。1.2 四种干预手段的粒度对比我把它们按干预的持久性和灵活性排一下你选工具的时候可以对着看。手段生效方式典型用途灵活性可复用性断点手动触发逐条处理定位问题、临时验证最高无一次性的手工改包断点后编辑内容改参数、改返回值高无AutoResponder规则匹配自动替换前端联调、Mock 数据中高可导出给同事FiddlerScript脚本逻辑处理批量改造、弱网、动态响应最高高但要懂代码一个经验排查期用断点联调期用 AutoResponder需要条件和计算的时候才上脚本。很多人一上来就写脚本结果为了调一个 mock 数据花了半小时其实 AutoResponder 里贴一段 JSON 三十秒就能搞定。2. 断点机制拆解Before Requests 和 After Responses 卡在哪一环2.1 请求断点在数据离开本机之前把它按住打开请求断点后Fiddler 收到浏览器发出的请求不会立刻转发给服务器而是把这个会话挂起来在会话列表里标成暂停状态同时在右侧 Inspectors 面板顶部出现提示条。此刻这个请求还停留在你的机器上服务器根本不知道它存在过。这个时机的价值在于你可以改的东西非常彻底请求行里的方法和 URL、所有请求头Cookie、Authorization、User-Agent、Referer、自定义头、请求体JSON、表单、二进制甚至连发不发都由你决定——点 Abort 就是直接掐掉浏览器会收到连接被中断的错误。我在排查鉴权问题的时候经常用请求断点把一个已经过期的 Cookie 换成新的看服务端是不是按预期返回 401 还是 200。这比改代码重新登录快得多。2.2 响应断点服务器已经处理完但浏览器还没看到响应断点晚一步。请求已经正常发给服务器并且拿回了响应Fiddler 在这里拦住等你处理完再交给浏览器。所以你能改的是状态行、响应头、响应体改不了请求请求已经发出去了。这个时机特别适合改返回值把 500 改成 200 看前端会不会因为缺字段崩掉、把列表里的数据删掉两条看分页逻辑、把时间戳改成未来时间看倒计时组件的行为、把金额字段改大看数字格式化有没有溢出。一个关键区分点请求断点影响的是服务端行为响应断点影响的是客户端行为。你想验证后端逻辑用请求断点你想验证前端逻辑用响应断点。2.3 三种状态的切换与快捷键Fiddler Classic 里断点有三种状态通过快捷键或者 Rules 菜单下的 Automatic Breakpoints 切换。F11切换 Before Requests请求断点Alt F11切换 After Responses响应断点Shift F11关闭所有断点这三个键请务必记牢。我见过不止一次有人开着请求断点去开会回来一看浏览器几十个标签页全卡死在加载中第一反应是断网了。Shift F11 是三秒钟的自救。2.4 放行与终止会话被挂住之后怎么处理会话被卡住后选中它Inspectors 面板顶部会出现一排操作按钮最常用的是Run to Completion绿色的那个意思是带着我改完的内容继续走完流程。旁边还有 Break on Response意思是这次先放行请求但到响应时再拦一次用来临时给某个请求补一个响应断点。还有一个 Abort直接终止这个会话。注意开着请求断点时放行一个会话如果你同时也开着响应断点它会在响应阶段被第二次拦住。这就是为什么有人觉得我明明放行了怎么还卡着——其实它卡在第二个断点上。还有一个容易被忽略的细节响应断点如果卡在的是页面主文档或者某个同步加载的 JS 上整个页面会一直转圈而且浏览器可能已经开始超时计时。所以响应断点最好配合 URL 精确匹配来用别全局开。3. 把断点打准命令行与过滤器的配合3.1 QuickExec 命令行比快捷键更精准的断点方式左下角那个黑框就是 QuickExec输入命令回车即生效。它对断点这件事的价值极大因为它能按条件打断点而不是全部卡住。命令作用示例bpu对匹配 URL 的请求打断点bpu /api/order/createbpafter对匹配 URL 的响应打断点bpafter /api/user/infobps按响应状态码打断点bps 404bpv按请求方法打断点bpv POSTbpm按响应类型打断点bpm text/html不带参数的 bpu 或 bpafter 表示清除该类型的断点。比如你输入一个光秃秃的bpu所有基于 URL 的请求断点就被清掉了但它不会关掉全局的 F11 开关这两件事是独立的别搞混。bpv 和 bpm 的匹配条件比较宽bpv POST会把所有 POST 请求都拦住用的时候要小心很容易把整个页面的表单提交全卡死。我一般只在很短的时间窗口内用看完就 Shift F11。3.2 Filters 面板的一个常见误解很多人以为在 Filters 面板里勾上 Use Filters、配好 Hosts 白名单断点就只会作用于白名单里的域名。这是个误解。Filters 主要控制的是会话列表里显示哪些会话它是个显示层的过滤器。被隐藏掉的会话在后台依然会被断点拦住依然会卡在加载中。所以正确的姿势是Filters 用来清理你不想看的噪音比如统计埋点、字体文件、图片断点范围用命令行来精确控制。两件事分开做。3.3 断点打多了的自救流程如果你已经把浏览器搞卡了按这个顺序处理先按Shift F11关掉全局断点开关防止新的请求继续被拦。在 QuickExec 里输入bpu回车再输入bpafter回车清掉所有 URL 级断点。回到会话列表把还处于暂停状态的会话逐个选中点 Run to Completion 放行如果数量太多直接重启 Fiddler 也行浏览器会自己重试。刷新页面确认恢复正常。这套流程我在带新人的时候让他们练过两遍基本就不会再出现开着断点去吃饭的事故了。4. 改包实战请求侧和响应侧分别改什么4.1 请求侧能改的东西比你想的多选中一个被拦住的请求右侧 Inspectors 面板上半部分是请求。常用的几个视图Headers看和改所有请求头。改 User-Agent 模拟不同客户端、改 Referer 绕过来源校验、改 Cookie 换身份、加自定义头验证灰度逻辑都在这里。WebForms如果请求体是表单或者 JSONFiddler 会解析成键值对直接改值最省事不用关心格式。TextView原始文本视图适合改非 JSON 的文本体比如 XML 或者纯文本。Raw完整的原始报文包括请求行。改 URL 路径、改请求方法只能在这里改。改 URL 有个小技巧如果你想测的是同一个接口的不同路径别在 Raw 里改整行容易把 HTTP 版本号那一截误删。直接把地址栏里的目标路径复制出来对一下只替换中间那段。4.2 响应侧改包从状态码到响应体响应侧最常改的是三类。状态码。把 500 改成 200或者反过来把 200 改成 500、404看前端有没有兜底。改状态码之前先想清楚前端是基于状态码判断还是基于响应体里的业务码判断很多项目是 HTTP 200 加业务码 5001 的组合改错层等于白改。响应体的 JSON 字段。这是最高频的操作。增删字段、把值改成 null、把数组清空、把数字改大、把日期改成跨年的边界值都是常规验证手段。在 WebForms 或者 JSON 视图里改最安全因为它们会帮你保证格式合法。如果你直接在 TextView 里手写 JSON一个多余的逗号就会让前端直接解析失败然后你会花十分钟怀疑是前端代码的问题。重定向。把 Location 头改成一个你指定的地址可以用来验证前端对 302 的处理、验证登录失效跳转、验证跨域跳转的携带信息行为。4.3 改完就卡住Content-Length、编码与压缩这是改包最经典的翻车点值得单独说。HTTP 响应体会带一个 Content-Length 头声明这个体的字节数。你把响应体从 200 字节改成 50 字节如果 Content-Length 还是 200浏览器会一直等剩下的 150 字节表现就是页面永远加载不完。好消息是通过 Inspectors 里的 WebForms、TextView、JSON 等视图修改响应体并点 Run to CompletionFiddler 一般会帮你重算 Content-Length。真正容易出问题的是你直接编辑 Raw 视图的时候那里面的一切都要你自己负责。第二个坑是Content-Encoding。如果原响应是 gzip 压缩的Fiddler 在展示给你之前已经解压了你看到的是明文。但如果你改了体之后Content-Encoding: gzip 这个头还留着浏览器会拿明文当 gzip 去解压结果就是乱码或者直接报错。提示改响应体的时候顺手看一眼响应头里有没有 Content-Encoding。如果 Fiddler 没有自动移除它手动删掉这一行再放行能省掉很多排查时间。第三个坑是分块传输Transfer-Encoding: chunked。这种响应没有 Content-Length体是按块拼的。改起来风险高建议改成明确的 Content-Length 并且在头里加一行 Content-Length 的值或者干脆用 AutoResponder 直接替换整个响应绕开这个麻烦。4.4 Raw 编辑的风险与建议Raw 视图给了你完整的控制权也把所有的责任交给了你。除了 Content-Length还有两件事要注意头的顺序一般无所谓但头之间的空行不能少空行下面是体行尾必须是 CRLF用某些编辑器粘贴进来的内容可能是 LFFiddler 有可能处理不了。我的习惯是能用 WebForms 就用 WebForms能用 TextView 就用 TextView只有必须改方法或者改 URL 路径的时候才碰 Raw并且改完立刻回到 Headers 视图核对一遍长度和编码相关的头。5. Composer 构造请求与 AutoResponder 伪造响应5.1 Composer把接口当积木手工拼出来Composer 标签页是 Fiddler 里被严重低估的功能。它让你从零构造一个 HTTP 请求并发出去不依赖浏览器。三种编辑模式各有用途Parsed结构化输入。选方法、填 URL、逐行加 Header、写 Body。最直观适合日常手搓请求。Raw整段粘贴原始报文。从会话列表右键 Copy Just URL 或者直接用 Raw 视图复制过来改两个参数就能重放。Scratchpad草稿区可以放多条请求随时挑一条执行。实际用途上我最常用 Composer 做三件事一是复现某个只在特定参数下出现的 Bug把参数改成那个值直接发二是接口还没上线的后端联调我按约定的格式手搓请求确认服务端能不能正确解析三是做简单的边界测试把 Body 里的数字改成极大值、负数、超长字符串快速看服务端的容错。5.2 AutoResponder 的四要素匹配、动作、延迟、开关AutoResponder 标签页的规则区本质上是一张如果……那么……的表。理解它只需要抓住四个要素。匹配表达式。默认是按 URL 前缀/通配匹配也支持EXACT:前缀做精确匹配REGEX:前缀做正则匹配NOT:前缀做取反。写规则的时候建议先从会话列表里把完整的 URL 复制过来看看它带不带查询串、端口号、末尾斜杠这几处不一致就会导致匹配失败。动作。可以选择一个本地文件作为响应体也可以直接在 Rule Editor 的下半部分填入响应内容。填内容的方式更灵活因为你可以同时指定状态码和响应头。延迟。右键任意一条规则选择 Set Latency单位是毫秒。这个功能在模拟慢接口的时候非常好用比改脚本延迟简单得多。但要记得勾选上面的 Enable Latency否则延迟设置不会生效——这个坑我踩过。开关。顶部有三个勾选框Enable rules启用规则、Unmatched requests passthrough未匹配的请求直接放行、Enable Latency启用延迟。三个都要检查尤其是第一个。5.3 用本地文件搭一个假服务器对于联调期需要几十个接口的场景最省事的做法是建一个目录按接口路径的层级关系放一堆 .json 文件然后在 AutoResponder 里用规则指向它们。这样做有两个好处一是 JSON 文件可以放进版本管理需求变了改文件就行不用改规则二是新同事拉下代码后只需要导入一份规则文件AutoResponder 支持导入导出规则集就能跑起一套完整的 Mock 环境不需要本地起服务。不过用本地文件有几个细节要处理。文件路径别放在中文目录或者带空格的目录下Fiddler 处理路径的时候容易出问题。文件用 UTF-8 保存无 BOM否则中文可能乱码。还有就是 Content-Type如果拿到响应后发现浏览器把它当文件下载了而不是当 JSON 解析在 Rule Editor 里显式加一行Content-Type: application/json; charsetutf-8就能解决。5.4 跨域、缓存、Content-Type 三个高频翻车点跨域。你在 AutoResponder 里伪造的响应浏览器依然要过 CORS 校验。如果这是一个跨域请求你的伪造响应里必须带Access-Control-Allow-Origin否则浏览器会直接拒绝这个响应控制台只报一个 CORS 错误看起来像是 Mock 没生效。这一点在联调阶段最容易让人迷惑。缓存。如果请求带了 If-None-Match 或 If-Modified-Since服务端有可能返回 304304 是没有响应体的你改什么都不会有反应。Mock 的时候建议在伪造响应里加Cache-Control: no-store同时把浏览器的开发者工具打开、勾上禁用缓存。注意开发者工具的禁用缓存只在开发者工具打开时有效这个限制要知道。Content-Type。伪造的响应类型必须和原接口一致。原本是application/json的你给了text/plain前端拿到的可能是字符串而不是对象报错信息会指向一个完全不相干的地方。改之前先看一眼原响应头照抄过来最稳。6. 用 FiddlerScript 处理重复劳动6.1 CustomRules.js 的位置与两个关键钩子Fiddler Classic 的脚本入口在 Rules 菜单下的 Customize Rules会打开 ScriptEditor实际编辑的是 CustomRules.js保存在文档目录下的 Fiddler2\Scripts\ 里。这个文件是纯 JavaScript但里面会用到 .NET 的一些对象写起来需要一点适应。最常用的两个钩子OnBeforeRequest(oSession)请求发出之前调用。适合改请求、拦截特定请求、直接构造响应。OnBeforeResponse(oSession)响应返回之后调用。适合改响应、统计耗时、注入内容。脚本和 AutoResponder 的分工是AutoResponder 处理静态的、固定的替换脚本处理需要条件判断、需要计算、需要动态生成的场景。6.2 直接构造响应跳过服务器有一类需求是 AutoResponder 也能做、但写起来很啰嗦的根据请求参数动态返回不同内容。比如按 id 返回不同的用户信息。这种用脚本几行就搞定。// 在 OnBeforeRequest 里 if (oSession.uriContains(/api/mock/user/)) { // 从 URL 里抠出 id var idx oSession.url.lastIndexOf(/); var uid oSession.url.substring(idx 1); // 造一个响应不再去请求服务器 oSession.utilCreateResponseAndBypassServer(); oSession.responseCode 200; oSession.oResponse.headers.Add(Content-Type, application/json; charsetutf-8); oSession.oResponse.headers.Add(Access-Control-Allow-Origin, *); oSession.utilSetResponseBody({id: uid ,name:用户 uid ,vip:false}); }utilCreateResponseAndBypassServer()是关键它告诉 Fiddler这个会话不用发到服务器了我自己给响应。utilSetResponseBody()会自动处理 Content-Length比手工拼字符串省心。提示脚本里如果用了中文CustomRules.js 必须保存为 UTF-8 编码否则返回给浏览器的中文会变成乱码。这是个非常隐蔽的坑因为脚本本身跑起来没有任何报错。6.3 弱网模拟用 trickle delay 控制节奏Fiddler 的弱网模拟不是真的限速而是往数据流里插入延迟效果上更像网络卡顿而不是带宽不足。核心是两个会话变量// 在 OnBeforeRequest 里只对特定域名生效 if (oSession.HostnameIs(api.example.com)) { oSession[request-trickle-delay] 200; // 每 KB 请求延迟 200ms oSession[response-trickle-delay] 300; // 每 KB 响应延迟 300ms }单位是毫秒每 KB。数值越大卡顿感越明显。用来验证前端的加载状态、骨架屏、超时重试逻辑非常合适。要注意的是这两个参数加在一个会阻塞的日志上报接口上可能把整个页面的加载拖慢因为它虽然不阻塞其它会话但你观察到的总时长会被拉长。所以建议按域名过滤只对你要测的那个接口生效。6.4 脚本报错之后怎么恢复CustomRules.js 写错一个分号Fiddler 启动时会弹一个错误框提示脚本编译失败而且这个错误会持续存在直到你改回来——更麻烦的是脚本一旦编译失败所有基于脚本的逻辑包括一些内置的默认规则都会失效表现得像是Fiddler 突然变傻了。恢复流程建议按这个顺序走用 Rules Customize Rules 打开编辑器看错误提示的行号。最常见的错因是缺少分号、括号不配对、字符串引号写成了中文引号。如果一时找不到问题把 CustomRules.js 先备份重命名重启 Fiddler它会生成一份默认脚本功能立即恢复。把备份里的自定义代码一段一段挪回默认脚本里每挪一段重启一次验证很快就能定位到出问题的那一段。养成一个习惯改脚本之前先复制一份 CustomRules.js.bak。这个动作花三秒能省半小时。7. 那些让人怀疑人生的现场7.1 AutoResponder 配好了却毫无反应六个排查点这个问题的出现频率高到可以单独成节。按下面这个顺序检查基本一比一个准。检查项现象处理Enable rules 未勾选规则列表里有规则但完全不起作用勾上顶部第一个复选框规则顺序被宽泛规则抢占明明加了精确规则命中的却是另一条精确规则拖到列表最上方Fiddler 从上往下匹配第一条命中即停止URL 匹配不完整部分请求命中部分不命中从会话列表复制完整 URL 再改注意末尾斜杠和查询串未勾选 Unmatched requests passthrough未命中的请求全部失败看起来像接口挂了勾上它让未命中的请求走真实服务器HTTPS 未解密会话列表里只有 CONNECT 隧道看不到内容在 HTTPS 选项里开启抓取 CONNECT 并解密流量装好根证书缓存或 304规则生效了但页面没变化伪造响应加 no-store开发者工具禁用缓存第六个还有一个变种规则指向的本地文件被移动或删除了。Fiddler 不会报错只会返回一个空响应或者失败响应表现和规则没生效一模一样。所以拿到一份别人给的规则集导入后第一件事是检查文件路径。7.2 关掉 Fiddler 之后浏览器打不开网页这个问题的根因是系统代理没有被还原。Fiddler 启动时会把系统代理指向本机的监听端口正常退出时它会自动还原但如果它是被强制结束、崩溃退出的这个设置就留在那里了浏览器仍然把流量往一个已经不存在的代理上送。处理方式到系统的代理设置里看手动代理那一项把它关掉或者确认它指向的地址端口对应的服务是否还在运行。Windows 上对应的是 Internet 选项里的局域网设置其它系统在各自网络设置里找代理项。有一个变体值得注意有时候代理设置是对的但 Fiddler 刚启动还没完全监听浏览器会短暂打不开页面等几秒就好。还有一种情况是 Fiddler 监听的端口被别的程序占用了这时候它启动会报端口占用需要改监听的端口号。7.3 HTTPS 与移动端联调的两个前置条件桌面端要抓 HTTPS必须在设置里开启抓取 HTTPS 连接并解密流量然后安装 Fiddler 的根证书到系统信任区。没有这一步你看到的只是 CONNECT 隧道改不了任何内容。移动端要多两步手机和电脑在同一个局域网手机的 Wi-Fi 设置里手动指定代理地址是电脑的内网 IP端口是 Fiddler 的监听端口然后在手机浏览器里访问http://电脑IP:端口从那个页面下载并安装证书。这里有一个很多人卡住的地方从 Android 7.0 开始应用默认不再信任用户安装的证书只信任系统证书。所以如果目标应用没有做额外的配置用户区装的证书对它是不生效的抓包里会看到连接失败或者证书错误。这个属于系统层面的限制处理方式取决于你是否有对设备的完整控制权限常规做法是在开发环境里直接用测试包配合应用自带的调试配置。8. 改包的边界与经验收尾8.1 只在你有权限的系统上动手Fiddler 的改包能力本质上是一种中间人能力用在你自己负责的系统、你有明确授权的测试环境里它是效率工具用在别人的系统上性质就完全变了。这个界限要自己心里清楚。我给自己定了一条线只在自建环境、测试环境、以及明确拿到书面授权的范围内做拦截和改包生产环境只做只读观察绝不修改任何请求或响应。8.2 生产数据要当场脱敏即使只是只读抓包生产流量里也会带真实的用户信息、手机号、地址、身份标识。如果你需要把会话导出或者截图发给同事务必先处理一遍。Fiddler 的会话导出是文本格式用编辑器全局替换掉敏感字段比事后补救容易得多。我的习惯是涉及生产的会话处理完当场清掉不留在本地。8.3 把 Mock 规则沉淀成团队资产最后分享一个我觉得最有价值的做法。AutoResponder 的规则集是可以导出的把一整套联调用的规则导出一个文件连同对应的 JSON 数据目录一起放进代码仓库配上几行说明。新同事拉下来导入五分钟就能跑起来一套完整的 Mock 环境不用等后端、不用起本地服务。这套东西积累下来比写文档有用得多因为它不会过期——数据变了改文件就行规则不用动。8.4 我个人常用的一条操作顺序如果只能记一条流程我建议记这条先 Shift F11 确保断点是关的然后在 QuickExec 里bpu 目标路径精确打请求断点卡住后先在 Headers 里核对 Content-Length 和 Content-Encoding改完点 Run to Completion验证通过后bpu清除断点把这次改法整理成一条 AutoResponder 规则固化下来。断点用来探索规则用来固守这个分工会让你在联调期越来越轻松。另外把改包验证出来的那些边界情况——字段为 null、数组为空、数字超长、状态码异常——反馈给开发写成单元测试或者接口测试用例这才是改包这件事真正的长期回报。改一百次包不如把一次改包换成一条永久生效的测试。