Fiddler抓包实战：调试HTTPS与接口分析技巧

又到抓包环节了，Fiddler 到底怎么选？

最近在做移动端接口调试，老问题又来了：本地怎么代理手机流量？我试过好几种方案，有 Fiddler Classic、Fiddler Everywhere，还有直接用 Charles。说实话，每种都有坑，但也有各自的爽点。今天就从一个真实开发者的角度，聊聊这几个工具在实际项目中的表现，不整虚的，只讲我踩过的雷和亲测有效的组合。

谁更灵活？谁更省事？

先说结论：如果你是 Windows 用户，且主要调试 HTTP/HTTPS 接口，我比较喜欢用 Fiddler Classic。它免费、轻量、插件生态成熟，而且脚本能力极强。虽然界面老得像 2005 年的 IE，但功能一点不落伍。

而 Fiddler Everywhere 呢？跨平台、UI 现代，但要付费（虽然有试用），而且某些高级功能藏得深，调试起来反而不如 Classic 直接。Charles 功能全面，但 Mac 上才香，Windows 下体验一般，而且证书配置有时候抽风。

所以我的选型逻辑很简单：Windows + 免费 + 能写脚本 → Fiddler Classic；Mac + 不差钱 + 团队协作 → Charles；跨平台但愿意付费 → Fiddler Everywhere。看场景，我一般选 Classic，因为够用、快、不用等加载动画。

核心代码就这几行（别被吓到）

很多人以为 Fiddler 配置很复杂，其实核心就三步：开代理、装证书、写规则。以调试手机请求为例，假设你要拦截 https://jztheme.com/api/user 的返回，改成 mock 数据。

在 Fiddler Classic 里，你只需要打开 Rules → Customize Rules，然后在 OnBeforeResponse 函数里加几行 JS：

static function OnBeforeResponse(oSession: Session) {
    if (oSession.HTTPMethodIs("GET") && oSession.uriContains("jztheme.com/api/user")) {
        oSession.utilCreateResponseAndBypassServer();
        oSession.oResponse.headers.SetStatus(200, "OK");
        oSession.oResponse.headers.Add("Content-Type", "application/json");
        oSession.utilSetResponseBody('{"id": 999, "name": "Mock User"}');
    }
}

保存后，手机连上电脑的 Wi-Fi，设置代理为电脑 IP 和 8888 端口，再访问那个接口，直接返回 mock 数据。亲测有效，改完立马生效，不用重启。

对比一下 Fiddler Everywhere：它也有类似功能，但得在 GUI 里点“Rules”→“Add Rule”，然后填匹配条件、响应体，操作路径长，还不能直接写 JS 逻辑。想实现“如果参数包含 debug=1 就返回错误”这种动态逻辑？Classic 一行 if (oSession.uriContains("debug=1")) 就搞定，Everywhere 得建两条规则，或者用它的 Scripting 模块——但那玩意儿文档少，调试还不直观。

踩坑提醒：这三点一定注意

第一，HTTPS 解密。很多人配完代理发现手机打不开 HTTPS 网站，其实是证书没装。Fiddler Classic 会生成一个根证书，你得在手机浏览器里访问 http://<电脑IP>:8888，下载并安装 FiddlerRoot.cer。这里注意：Android 7 以上默认不信任用户安装的 CA 证书，除非你 root 或者用调试版 APK。iOS 倒是友好，装完去“通用→关于本机→证书信任设置”里手动开启就行。我在这上面折腾过半天，后来直接用测试机绕过。

第二，端口冲突。Fiddler 默认用 8888，但有时候被其他程序占了（比如某些 Docker 服务）。这时候别慌，去 Tools → Options → Connections 改个端口就行，比如 8889，记得手机代理也跟着改。

第三，规则缓存。Classic 的脚本改完有时不生效，不是代码错了，是 Fiddler 缓存了旧规则。解决方法：关掉 Fiddler 重开，或者按 Ctrl+R 强制重载脚本。这个坑我踩过好几次，一度以为自己写错了逻辑。

性能对比：差距比我想象的大

别看都是抓包工具，实际跑起来差别不小。我在同一台 Win11 笔记本上同时开了三个工具，分别代理同一个手机流量：

• Fiddler Classic：内存占用 80MB 左右，启动 3 秒，规则响应几乎无延迟
• Fiddler Everywhere：内存飙到 300MB+，启动要 10 秒，界面偶尔卡顿
• Charles：内存 200MB，启动 6 秒，但过滤器功能确实好用

对于日常快速调试，Classic 的轻量优势太明显了。Everywhere 虽然 UI 好看，但资源消耗大，笔记本风扇一响，我就知道该切回 Classic 了。

我的选型逻辑

总结一下我的偏好：

• 日常开发、快速 mock、写复杂规则 → Fiddler Classic（免费 + 脚本自由）
• 团队共享规则、需要图形化协作 → Fiddler Everywhere（但得接受付费和性能代价）
• Mac 用户、重度依赖断点调试 → Charles（它的 Breakpoints 确实比 Fiddler 直观）

说实话，Fiddler Classic 虽然界面丑，但胜在“够用就好”。我不需要花里胡哨的仪表盘，只要能快速改个响应、拦个请求就行。而且它的 AutoResponder 功能（自动返回本地文件）配合脚本，做前端联调简直神器——比如把 /api/config 指向本地 config.json，改完保存就生效，不用等后端发版。

当然，Classic 也不是完美。比如不支持 WebSocket 详细解析（只能看到原始帧），这时候我会临时切 Charles。但 90% 的场景，Classic 足够了。

最后说两句

以上是我个人对 Fiddler 相关方案的对比总结，全是实战中踩出来的经验。工具没有绝对好坏，关键看是否匹配你的工作流。如果你也在用 Fiddler Classic，不妨试试在 CustomRules.js 里加个时间戳日志，方便追踪请求顺序；如果用 Everywhere，记得定期清理历史记录，不然它会越来越卡。

有不同看法欢迎评论区交流——比如你有没有发现 Fiddler Everywhere 的隐藏技巧？或者有更好的免费替代方案？我很乐意听听。毕竟，抓包这事儿，能省一分钟是一分钟，谁不想少加班呢？