Fiddler抓包实战：调试HTTPS与排查前端网络问题的高效技巧

项目初期的技术选型

上个月接了个移动端 H5 项目，主要是做一套动态表单配置系统，前端要能实时预览不同字段组合的渲染效果。后端接口还没完全 ready，但 UI 和交互逻辑得先跑起来。这时候我就想到用 Fiddler 做本地 mock，绕过后端依赖。

其实一开始也考虑过 Mock.js 或者直接写死 JSON，但这个项目有几个特殊点：一是接口返回结构复杂，嵌套深；二是需要模拟不同状态（比如加载中、错误、空数据）；三是后期要和真接口无缝切换。Mock.js 虽然灵活，但调试起来麻烦，改个字段得翻半天规则。Fiddler 的 AutoResponder 功能正好能直接替换请求，还能用正则匹配，改完立刻生效，不用重启服务，亲测省事。

核心代码就这几行

配置其实很简单。在 Fiddler 的 AutoResponder 里加一条规则，比如匹配 https://jztheme.com/api/form/config，然后指向本地的 mock/form-config.json 文件就行。但为了更灵活，我用了 FiddlerScript（Rules → Customize Rules）来动态处理。

打开 FiddlerScript 编辑器，在 OnBeforeRequest 函数里加逻辑：

static function OnBeforeRequest(oSession: Session) {
    if (oSession.uriContains("/api/form/config")) {
        // 模拟不同状态：通过 query 参数控制
        if (oSession.fullUrl.indexOf("mock_status=error") > -1) {
            oSession["x-replyfilename"] = "mock/form-error.json";
        } else if (oSession.fullUrl.indexOf("mock_status=empty") > -1) {
            oSession["x-replyfilename"] = "mock/form-empty.json";
        } else {
            oSession["x-replyfilename"] = "mock/form-config.json";
        }
        oSession["ui-backcolor"] = "yellow"; // 标记为黄色，方便识别
    }
}

这样，前端只要在 URL 里加个 ?mock_status=error，就能看到错误状态的 UI，不用改一行代码。本地 mock 文件放在 Fiddler 安装目录下的 Scripts 文件夹里（或者自定义路径），结构示例如下：

{
  "code": 0,
  "data": {
    "fields": [
      {
        "type": "text",
        "label": "用户名",
        "required": true
      },
      {
        "type": "select",
        "label": "城市",
        "options": ["北京", "上海", "广州"]
      }
    ]
  }
}

最大的坑：HTTPS 和证书问题

项目中期，后端接口全切 HTTPS 了。我本地 mock 还是 HTTP，浏览器直接报混合内容错误，根本加载不了。折腾了半天才想起来 Fiddler 默认只解密 HTTP 流量。

解决方法是在 Fiddler 的 Tools → Options → HTTPS 里勾上 “Decrypt HTTPS traffic”，然后安装根证书。但这里有个大坑：iOS 模拟器或真机连 Fiddler 代理时，证书信任设置特别麻烦。Android 还好，手动导入就行；iOS 13+ 之后，即使安装了证书，还得在“通用 → 关于本机 → 证书信任设置”里手动开启完全信任，不然照样失败。

更烦的是，有些同事的 Mac 系统版本旧，Fiddler 生成的证书不被 Safari 信任，反复弹窗。后来我干脆写了个小脚本，用 mkcert 生成本地可信证书，配合 Fiddler 的自定义证书功能，才算勉强搞定。但说实话，这一步还是劝退了不少人，最后团队里只有我和另一个老手能稳定跑起来 HTTPS mock。

另一个头疼的问题：动态参数匹配

项目里有个接口是 /api/form/data?formId=123，不同 formId 返回不同数据。我一开始想用正则：regex:^https://jztheme.com/api/form/data?formId=(d+)$，然后根据捕获组指向不同文件。但 Fiddler 的 AutoResponder 正则不支持引用捕获组！也就是说，没法动态拼出文件名 mock/data-123.json。

查了官方文档和 Stack Overflow，发现只能靠 FiddlerScript 解决。于是重写逻辑：

if (oSession.uriContains("/api/form/data") && oSession.uriContains("formId=")) {
    var url = oSession.fullUrl;
    var formId = /formId=(d+)/.exec(url)[1];
    var filePath = "mock/form-data-" + formId + ".json";
    // 检查文件是否存在，避免 404
    if (System.IO.File.Exists(filePath)) {
        oSession["x-replyfilename"] = filePath;
        oSession["ui-backcolor"] = "lightgreen";
    } else {
        // 文件不存在就放行，走真实接口
        oSession["ui-backcolor"] = "red";
    }
}

这里注意我踩过好几次坑：一是路径分隔符在 Windows 上是反斜杠，但 FiddlerScript 用的是 .NET，得用正斜杠或双反斜杠；二是必须检查文件是否存在，否则 Fiddler 会返回 502，前端直接报错。加了红色标记后，一眼就能看出哪些请求没 mock 到。

最终的解决方案

综合下来，我们的方案是：

• 所有 mock 文件按接口路径组织，比如 mock/api/form/config.json
• FiddlerScript 里统一处理 URI 匹配，优先使用本地文件，不存在则透传
• 通过 URL query 参数控制 mock 状态（正常/错误/空）
• HTTPS 问题靠团队内部共享证书配置文档解决，新成员入职时花 10 分钟配一次

上线前一周，我们把 Fiddler 规则导出成 .saz 文件存到 Git 仓库，新人 clone 后直接导入就能复现所有 mock 场景。虽然有点土，但比写文档靠谱多了。

回顾与反思

这套方案在项目里跑了两个月，整体还算稳。好处是前端完全独立于后端进度，UI 联调效率高；坏处是 Fiddler 配置成了单点依赖，有次我电脑崩了，整个前端组停工两小时等我修好。

另外，mock 数据维护是个隐形成本。后端改了字段，前端经常忘记同步 mock 文件，导致测试时出现奇怪 bug。后来我们加了个校验脚本，启动 dev server 时自动对比 mock 文件和 Swagger 文档的差异，但也没完全解决问题。

现在回头看，如果项目周期更长，可能用 Mock Service Worker (MSW) 会更可持续——毕竟它跑在浏览器里，不用装代理，团队协作也方便。但当时时间紧，Fiddler 上手快，改几行脚本就能跑，符合“最简单能用就行”的原则。虽然最后留了两个小问题：一是 iOS 证书信任偶尔失效，二是动态参数匹配逻辑写得有点糙，但无伤大雅，上线后没再碰过。

以上是我踩坑后的总结，希望对你有帮助。如果你有更好的 Fiddler 技巧，或者用 MSW 替代的实战经验，欢迎评论区交流！