用 Fiddler 模拟弱网环境：从限速原理到脚本实战

你的应用在办公室的千兆网下丝般顺滑，可到了电梯里、地铁上、信号差的老小区，用户就开始抱怨"转圈半天""图片加载不出来""点了没反应"。弱网测试就是要在开发阶段提前暴露这些问题。Fiddler 内置了限速能力，但默认参数很粗糙，真正好用的是它背后的脚本化限速。本文从原理讲到可直接抄用的代码。

一、Fiddler 是怎么"限速"的

Fiddler 的限速机制叫 trickle（涓流）：它不是简单地"整体延迟 N 秒再一次性给数据"，而是把数据切成小块，每传 1 KB 就等待一段固定时间，从而模拟出真实的低带宽——数据一点一点"挤"过来。这两个参数控制它：

  • request-trickle-delay：上行每 KB 的延迟毫秒数（影响你发出去的数据，如上传、提交表单）。
  • response-trickle-delay：下行每 KB 的延迟毫秒数（影响服务器返回的数据，如加载页面、下载图片）。

换算关系很直观：延迟 d 毫秒/KB，等价于带宽约 1000/d KB/s。比如 response-trickle-delay = 100 就是约 10 KB/s（≈80 kbps），接近 2G 的水平。理解这个换算，你就能按目标带宽反推参数，而不是瞎试。

二、最快上手：开启内置限速

  1. 菜单 Rules > Performance > Simulate Modem Speeds 打勾。
  2. 此后所有经过 Fiddler 的流量都会被限速，页面明显变慢。
  3. 测完记得取消勾选，否则你会以为"电脑网怎么这么卡"。

内置限速的默认值大约是上行 300ms/KB、下行 150ms/KB，偏慢且不可直接在界面调整。要精确控制，得改脚本。

三、精确控制：改 FiddlerScript

菜单 Rules > Customize Rules（快捷键 Ctrl+R）打开脚本编辑器，这是 Fiddler 用 JScript.NET 写的规则文件。找到 OnBeforeRequest 函数，Simulate Modem Speeds 相关的代码就在里面，形如：

if (m_SimulateModem) {
  oSession["request-trickle-delay"] = "300";
  oSession["response-trickle-delay"] = "150";
}

把这两个数值改成你要模拟的网络档位即可。下面是几档常用参考值（下行为主，按体验校准）：

  • 2G / 极弱网：response ≈ 120（约 8 KB/s），首屏可能等十几秒，适合测超时与骨架屏。
  • 3G：response ≈ 20（约 50 KB/s），测图片渐进加载、懒加载。
  • 4G 拥塞：response ≈ 5（约 200 KB/s），测中等负载下的流畅度。
  • 上行 request-trickle-delay 一般设成下行的 1.5~2 倍，因为真实移动网络上行通常更慢，这对测上传/提交场景很关键。

改完保存文件，Fiddler 会自动重新加载规则，勾选 Simulate Modem Speeds 后新参数立即生效。

四、进阶：只对某些接口限速

整站限速会让调试很痛苦。更实用的是只对你关心的接口或资源限速，其余保持正常。在 OnBeforeRequest 里加一段判断即可（无需依赖 Simulate Modem Speeds 开关）：

// 只给图片和上传接口限速，模拟弱网下的媒体加载
if (oSession.uriContains("/upload") || oSession.oResponse == null && oSession.url.match(/\.(jpg|png|gif)/i)) {
  oSession["request-trickle-delay"] = "200";
  oSession["response-trickle-delay"] = "120";
}

更简单的做法是配合 AutoResponder 的魔法动作：给目标请求设动作 *delay:3000（固定延迟 3 秒）或 *drop（直接断开，模拟丢包/断流），用来测"某个关键接口很慢/失败时页面会怎样"，无需写脚本。

五、模拟丢包与断流

弱网不只是"慢"，还有"断"。真实场景里请求会随机失败。可以组合手段模拟：

  • 对目标接口用 AutoResponder 设 *drop 或 *reset，制造连接中断。
  • 用响应断点 bpafter 拦下请求后直接不放行，模拟请求永远挂起（测前端超时逻辑是否生效）。
  • 先正常一次、再 drop 一次交替，观察前端的重试与降级策略。

六、弱网测试到底该看什么

限速只是手段，发现问题才是目的。重点观察这几项：

  • 有没有超时兜底：接口设了合理超时吗？超时后是无限转圈，还是给出"网络不佳，请重试"？
  • 首屏体验：慢网下是白屏干等，还是有骨架屏 / loading 占位？关键内容是否优先加载？
  • 图片与大资源：大图是否压缩、是否懒加载、是否有渐进式占位，避免拖垮首屏。
  • 重复提交：提交按钮在慢速请求未返回时是否被禁用？否则用户狂点会造成重复下单。
  • 失败可恢复：请求失败后能否手动重试，而不是让用户刷新整个页面。

七、小结

Fiddler 弱网模拟的核心是 request/response-trickle-delay 这对"每 KB 延迟"参数，用 1000/延迟 ≈ KB/s 就能按目标带宽反推数值。日常测试建议：整站限速用 Simulate Modem Speeds 快速验证，精细场景用脚本按接口限速，断流用 AutoResponder 的 *drop / *delay。 把慢网、丢包、断流都覆盖到，你的应用才算真正经得起真实网络的考验。