Requestly规则使用技巧：前端联调、接口Mock与网络请求调试实战

Requestly规则使用技巧：前端联调、接口Mock与网络请求调试实战

导读：这篇文章不罗列 Requestly 的所有按钮，而是围绕日常开发中最常见的几个问题，讲清楚规则怎么匹配、怎么组合，以及规则没生效时应该从哪里排查。
适用版本：Requestly HTTP Interceptor 浏览器扩展与 Desktop App，内容依据 2026 年 7 月 30 日可访问的官方文档整理。Requestly 会持续更新界面，菜单文字可能调整，但本文涉及的规则类型和匹配思路仍然适用。

---

一、我为什么会在联调时用 Requestly

前端联调经常卡在一些很琐碎的问题上：

• 测试环境接口还没部署，页面却需要继续开发；
• 一个请求应该指向本地服务，其他请求仍然访问测试环境；
• 后端暂时返回不了异常状态，前端没法验证错误提示；
• 某个请求缺少 Header，改代码、重新构建又太慢；
• 想验证慢接口、超时、资源加载失败时页面是否还能正常操作；
• 线上问题只在特定响应数据下出现，需要临时修改返回值复现。

Chrome DevTools 能查看和重放请求，但遇到需要持续改写请求的场景，我通常会使用 Requestly。它的核心能力是给 HTTP 流量配置规则：请求经过浏览器或代理时，按条件匹配，然后执行重定向、替换、修改、延迟或阻断。

一个典型规则可以理解成：

当 URL 满足某个条件
并且请求方法、资源类型等附加条件也满足时
对请求或响应执行指定操作

这种方式有两个实际好处：

1. 不需要修改业务代码，不会把临时调试逻辑提交到仓库；
2. 规则可以开关、分组、导出和共享，复现场景比口头描述稳定得多。

---

二、先选对使用方式：浏览器扩展还是 Desktop App

Requestly 当前把 API Client 和 HTTP Interceptor 区分为不同用途。本文讨论的是 HTTP Interceptor 的规则能力。

使用方式	更适合的场景	我通常怎么选
浏览器扩展	Chrome、Edge 等浏览器中的网页请求	普通前端开发优先使用，安装和启停都比较方便
Desktop App	桌面应用、移动设备、模拟器、Node.js、终端和系统级流量	调试浏览器之外的流量，或者需要代理级拦截时使用
API Client	主动发送 API、管理集合、环境变量和测试脚本	更接近 Postman 的工作方式，不用于网页流量的透明改写

如果只是调试当前浏览器打开的前端项目，装浏览器扩展通常就够了。调试 Electron、移动 App、模拟器、终端 curl 或 Node.js 进程时，再使用 Desktop App。

⚠️ 浏览器扩展看不到的请求，不代表规则写错了。请求如果根本没有经过扩展所在的浏览器，就应该检查是否需要 Desktop App 和代理配置。

---

三、规则能不能用好，关键在 Source Condition

我踩过最多的坑并不是"不会改响应"，而是规则匹配范围写得太宽或者太窄。Requestly 将规则入口条件称为 Source Condition，常见匹配方式包括 Contains、Equals、Wildcard、Regex，并且可以叠加高级过滤条件。

3.1 Contains：日常使用频率最高

假设要匹配订单详情接口：

https://test-api.example.com/api/orders/20260730001

可以配置：

URL Contains /api/orders/

它适合路径中包含稳定片段、ID 会动态变化的接口。

优点是简单，缺点是容易误伤。例如下面这些地址都会匹配：

/api/orders/20260730001
/api/orders/export
/api/orders/statistics

所以我的习惯是：Contains 只负责初步缩小范围，再叠加请求方法或资源类型。

URL Contains /api/orders/
Method Equals GET

3.2 Equals：适合固定资源和精确接口

如果只想改一个固定配置文件：

https://static.example.com/config/app.json

直接使用：

URL Equals https://static.example.com/config/app.json

Equals 最安全，但 URL 一旦带有时间戳或动态查询参数就可能失效：

https://static.example.com/config/app.json?t=1785388800

遇到这种情况，我会改用 Contains，或者通过正则明确处理查询参数。

3.3 Wildcard：适合一组有规律的地址

例如同时匹配用户模块下的多个接口：

https://test-api.example.com/api/users/*

Wildcard 比正则更容易读，规则分享给同事后也更容易维护。能用 Wildcard 表达清楚时，我不会急着写正则。

3.4 Regex：复杂匹配要写边界

如果只匹配数字订单 ID，而不匹配 /export：

^https://test-api\.example\.com/api/orders/\d+(\?.*)?$

这段正则做了几件事：

• ^ 和 $ 限制完整 URL；
• \. 表示普通的点号；
• \d+ 只接受数字订单 ID；
• (\?.*)? 允许存在查询参数。

❌ 容易误匹配的写法：

/api/orders/.*

✅ 边界更明确的写法：

^https://test-api\.example\.com/api/orders/\d+(\?.*)?$

💡 Requestly 提供规则测试能力。正则写完不要只凭肉眼确认，把"应该命中"和"不应该命中"的 URL 都测一遍。

3.5 高级过滤条件能少建很多重复规则

同一个 URL 可能同时承载不同方法：

GET /api/users/1001
PUT /api/users/1001
DELETE /api/users/1001

如果只想修改 PUT 请求体，就应该增加 Method 条件，而不是让规则命中所有请求。类似地，还可以根据资源类型等条件缩小范围。

我给规则加条件时会遵循一个原则：URL 负责圈定业务范围，高级过滤器负责锁定请求性质。

---

四、Redirect、Replace、Map Local 怎么选

这几个规则都会改变请求去向，但适用场景并不相同。

4.1 Redirect：一个明确地址跳到另一个明确地址

假设前端请求测试环境：

https://test-api.example.com/api/profile

本地已经启动服务：

http://localhost:8080/api/profile

创建 Redirect Rule：

Source:
https://test-api.example.com/api/profile

Destination:
http://localhost:8080/api/profile

这适合单个接口或者固定资源。

另一个常见用法是把 CDN 上的 JavaScript 文件临时切到开发版本：

https://cdn.example.com/assets/app.min.js

重定向为：

https://dev-cdn.example.com/assets/app.js

4.2 Replace：保留 URL 其他部分，只替换其中一段

如果一整个 API 域名都要从测试环境切到本地，逐条创建 Redirect 很麻烦。Replace Rule 更合适：

Replace:
https://test-api.example.com

With:
http://localhost:8080

原请求：

https://test-api.example.com/api/orders/20260730001?detail=true

会变成：

http://localhost:8080/api/orders/20260730001?detail=true

路径和查询参数得以保留。

我的选择标准很直接：

需求	推荐规则
固定 A 地址跳到固定 B 地址	Redirect
批量替换域名、路径片段或版本号	Replace
用本地文件替换线上 JS、CSS、JSON 等资源	Map Local
将请求映射到另一个远程资源	Map Remote

4.3 Map Local：直接验证本地资源修改

Map Local 很适合下面这种情况：

1. 线上页面加载 https://cdn.example.com/assets/app.js；
2. 本地修改了 app.js；
3. 不想重新发布 CDN；
4. 希望刷新页面就看到本地修改效果。

这时可用 Map Local 把远程资源映射为本地文件。相比启动临时静态服务器再配置 Redirect，它减少了一层准备工作。

⚠️ Map Local 涉及本地文件访问与流量拦截，浏览器扩展和 Desktop App 的可用范围可能不同。如果界面中没有对应能力，应根据当前官方说明改用 Desktop App。

---

五、Modify Headers：联调认证和跨域问题

Header 修改规则可以对请求头或响应头执行 Add、Remove、Override。它很适合临时注入认证信息、模拟不同租户，或者验证响应 Header 对前端行为的影响。

5.1 给测试接口增加认证 Header

例如前端尚未接入登录流程，但接口需要 Bearer Token：

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.requestly-demo.signature

配置思路：

Source:
URL Contains https://test-api.example.com/api/

Operation:
Request Header -> Override

Header:
Authorization

Value:
Bearer eyJhbGciOiJIUzI1NiJ9.requestly-demo.signature

⚠️ 不要把生产 Token 放进共享规则、截图或导出文件。调试凭证应该使用低权限测试账号，并设置较短有效期。

5.2 临时增加租户或灰度标识

X-Tenant-Id: tenant-10086
X-Feature-Flag: checkout-v2

这种规则适合验证后端按 Header 分流的逻辑。建议一个业务场景建一个规则组，不要把多个不相关 Header 全塞进"万能规则"。

5.3 CORS 不能只靠加一个响应头

很多人第一次用 Modify Headers，会尝试加：

Access-Control-Allow-Origin: *

有时页面能继续访问，但涉及凭证请求、预检请求或者服务端拒绝 OPTIONS 时，仅增加一个响应头并不能解决完整的 CORS 流程。

排查时至少要看：

• 是否发起了 OPTIONS 预检；
• Access-Control-Allow-Methods 是否包含目标方法；
• Access-Control-Allow-Headers 是否包含自定义请求头；
• 使用 Cookie 时是否配置了 Access-Control-Allow-Credentials；
• Allow-Origin: * 是否与凭证模式冲突。

Requestly 可以帮助本地调试，但最终的跨域策略仍应在服务端正确配置。

---

六、Modify Query Params 与 Modify Request Body

6.1 Query 参数：快速切换分页、语言和开关

假设页面请求：

https://test-api.example.com/api/products?page=1&pageSize=20

可以用 Modify Query Params：

Override pageSize = 100
Add locale = zh-CN
Remove cache = true

它适合测试：

• 超大分页对页面布局的影响；
• 不同语言或地区参数；
• 灰度开关；
• 删除缓存参数，确认缓存是否影响问题复现。

这里要注意 URL 编码。参数值包含中文、空格、分号或嵌套 URL 时，应该在 Network 面板确认最终请求地址，不要只看规则编辑器里的原始值。

6.2 Request Body：构造边界输入

例如页面正常发送：

{
  "productId": 10001,
  "quantity": 1,
  "couponCode": "NEW10"
}

为了验证数量上限，可以把请求体修改为：

{
  "productId": 10001,
  "quantity": 99999,
  "couponCode": "NEW10"
}

适合验证的边界场景包括：

• 必填字段缺失；
• 数值为 0、负数或极大值；
• 字符串超长；
• 枚举值非法；
• GraphQL variables 发生变化；
• 前端暂时无法操作出的状态组合。

静态 JSON 适合固定数据。需要根据原请求动态处理时，可以使用 JavaScript 方式修改，但脚本要尽量保持短小，并明确处理解析失败。

下面是一段更稳妥的通用思路：

// 先确认请求体可以解析为 JSON，再修改目标字段。
const body = JSON.parse(requestData);
body.quantity = 99999;
body.debugSource = "requestly";
return JSON.stringify(body);

具体脚本上下文变量以当前 Requestly 规则编辑器提供的示例和提示为准，避免直接复制旧版本文章里的变量名。

---

七、Modify API Response：前端开发最好用的一类规则

后端还没准备好、异常数据难构造、线上问题难复现时，我最常用的是 Modify API Response。

7.1 静态替换：快速造一个确定响应

把用户接口替换成：

{
  "code": 0,
  "message": "success",
  "data": {
    "id": "10001",
    "name": "Requestly Test User",
    "roles": ["admin"],
    "firstLogin": true
  }
}

这适合页面骨架开发和稳定复现。如果前端还依赖响应状态码或 Header，也要同步配置，别只修改 Body。

7.2 动态修改：保留真实响应，只动一个字段

很多时候我并不想完全 Mock，只想保留后端返回的数据，把某个权限开关改掉。例如真实响应是：

{
  "code": 0,
  "data": {
    "userId": "10001",
    "canExport": false,
    "maxExportCount": 100
  }
}

目标响应：

{
  "code": 0,
  "data": {
    "userId": "10001",
    "canExport": true,
    "maxExportCount": 10000
  }
}

动态修改比整段静态覆盖更接近真实环境，也不容易因为后端新增字段导致 Mock 数据过时。

示意脚本如下：

// 示例逻辑：保留原响应，仅打开导出能力。
const response = JSON.parse(responseBody);
response.data.canExport = true;
response.data.maxExportCount = 10000;
return JSON.stringify(response);

同样，responseBody 等脚本变量名应以当前规则编辑器内置模板为准。

7.3 不要只测成功响应

我会为关键页面准备一组异常场景：

场景	状态码或响应示例	重点检查
未登录	401	是否跳登录，是否出现循环跳转
无权限	403	是否给出明确提示，按钮是否提前隐藏
数据不存在	404	空状态和返回入口是否正常
参数冲突	409	是否保留用户已填写内容
服务异常	500	是否出现可重试提示
空数组	{"data":[]}	空状态布局是否稳定
字段缺失	删除非必填字段	前端是否错误地强依赖字段
超长文本	返回数百字名称	是否溢出或遮挡

这些规则可以放进"订单页异常测试"分组，需要时整组启用。

---

八、Delay 与 Cancel：几分钟补上弱网和失败测试

8.1 Delay Rule：检查 Loading 是否真的可靠

本地网络太快时，一些问题很难暴露：

• Loading 一闪而过，设计和交互没被认真检查；
• 用户重复点击提交按钮；
• 请求返回顺序变化后，旧数据覆盖新数据；
• 页面切走后异步回调仍修改状态；
• 超时提示或取消请求逻辑从未真正执行。

可以对订单提交接口增加 5000 毫秒延迟：

URL Contains /api/orders/submit
Method Equals POST
Delay 5000 ms

然后检查：

1. 提交按钮是否禁用；
2. 是否会产生重复请求；
3. 用户能否取消；
4. 页面是否有明确进度反馈；
5. 超时后是否可以重试；
6. 请求最终成功后状态是否正确恢复。

8.2 Cancel Request：验证资源或接口彻底失败

Cancel Rule 会直接阻断匹配请求。它适合模拟：

• 埋点脚本加载失败；
• 图片、字体或第三方 SDK 不可用；
• 某个接口完全断网；
• 广告或非核心资源被浏览器扩展拦截；
• 页面初始化时一个并行请求失败。

例如阻断统计脚本：

URL Contains /analytics.js
Resource Type Equals Script

如果阻断统计脚本后页面也打不开，说明非核心依赖和主流程耦合得太紧。

💡 Delay 用于"请求很慢但最终有结果"，Cancel 用于"请求根本不会成功"。这两个场景应该分别测试。

---

九、Insert Scripts：临时验证页面行为

Insert Scripts Rule 可以向页面注入 JavaScript 或 CSS。它很适合验证一个想法，但我不会把它当成长久方案。

9.1 注入 CSS 检查布局

例如给所有可点击元素增加轮廓：

button,
a,
[role="button"] {
  outline: 2px solid #ff3b30 !important;
  outline-offset: 2px !important;
}

可以快速检查点击区域分布，也能发现一些用普通 div 模拟按钮的实现。

9.2 注入 JavaScript 观察事件

document.addEventListener(
  "click",
  (event) => {
    const target = event.target.closest("button, a, [role='button']");
    if (target) {
      console.log("[Requestly click]", target);
    }
  },
  true
);

它适合临时排查点击事件被谁拦截、动态 DOM 是否如预期生成。

⚠️ 页面内容安全策略 CSP 可能限制脚本注入。规则未生效时，要同时检查 DevTools Console 中的 CSP 报错。

---

十、把规则管理好，比多写规则更重要

规则少时随便命名问题不大。积累到几十条后，如果没有管理习惯，很容易出现"忘记关规则，误以为测试环境数据有问题"。

10.1 名称里写清环境、模块和动作

我常用这种命名方式：

[LOCAL][订单] API域名切换到localhost
[TEST][用户] 强制开启导出权限
[TEST][登录] 模拟401响应
[ALL][资源] 阻断analytics.js

看到名称就能知道作用范围。

10.2 按场景分组，不按规则类型分组

❌ 不太实用的分组：

所有Header规则
所有Response规则
所有Redirect规则

✅ 更适合开发工作的分组：

订单页面本地联调
登录异常场景
支付页弱网测试
用户权限组合

一个联调场景往往同时包含 Redirect、Header 和 Response 规则。按场景分组后，可以一次启停完整环境。

10.3 同一时间尽量只启用当前需要的组

启用规则越多，排查成本越高。尤其是多个规则命中同一个请求时，最终结果可能受到执行顺序或组合效果影响。

我的习惯是：

1. 默认关闭历史规则；
2. 开始任务时只启用一个场景组；
3. 用完立即关闭；
4. 临时规则名称加日期或 TEMP；
5. 每周清理已经不再使用的规则。

10.4 共享前先去掉敏感数据

规则可以导出、通过 Workspace 或 Shared List 分享。分享前重点检查：

• Authorization、Cookie 和内部 Token；
• 内网域名和 IP；
• 用户手机号、邮箱和真实业务数据；
• Mock 响应中的身份证号等个人信息；
• 带密码保护参数的 File Server 地址；
• 仅自己电脑可访问的本地路径。

---

十一、规则不生效时，我按这个顺序排查

11.1 先确认规则是否真的命中

不要先怀疑缓存或框架。先使用 Requestly 的 Test This Rule、规则执行状态提示或验证功能，确认目标 URL 是否匹配。

建议准备两条测试数据：

应该命中：
https://test-api.example.com/api/orders/20260730001

不应该命中：
https://test-api.example.com/api/orders/export

11.2 再看请求是否经过当前拦截器

• 请求是不是从安装扩展的浏览器发出；
• 是否使用了 Desktop App 但代理没有启用；
• 移动设备是否正确设置代理和证书；
• 是否把目标域名加入了排除列表；
• Requestly 是否处于 Pause 状态。

11.3 检查规则开关和分组状态

规则自身开启，但父级分组关闭，也可能没有效果。团队 Workspace 中还要注意规则状态同步策略。

11.4 排除 Service Worker 和缓存

网页可能从 Service Worker、Memory Cache 或 Disk Cache 读取资源，导致看起来"请求根本没被修改"。

在 Chrome DevTools 中可以尝试：

Network -> Disable cache
Application -> Service Workers -> Bypass for network

然后执行硬刷新。

11.5 检查多个规则是否互相影响

同一个请求可能同时命中 Replace、Redirect、Modify Headers 和 Modify Response。排查时先关闭其他规则，只保留一条最小规则，确认后再逐个恢复。

11.6 看 DevTools Console 和 Network 的最终结果

不要只看 Requestly 编辑器，应确认：

• Request URL 最终变成了什么；
• Request Headers 是否真的添加；
• Request Payload 是否改变；
• Response Status、Headers、Body 是否符合预期；
• Console 是否出现 CSP、CORS、证书或扩展错误。

---

十二、三个可以直接照着配置的实战方案

12.1 方案一：测试环境页面调用本地后端

目标：

页面仍打开 https://test-web.example.com
订单接口改走 http://localhost:8080
其他测试环境接口保持不变

规则：

Rule Type: Replace
Source URL Contains: https://test-api.example.com/api/orders/
Replace: https://test-api.example.com
With: http://localhost:8080

如果本地接口还需要测试环境 Token，再增加一条 Modify Headers Rule：

Request Header Override:
Authorization = Bearer test-user-short-lived-token

12.2 方案二：前端独立开发列表页

先在 File Server 创建 JSON 响应：

{
  "code": 0,
  "message": "success",
  "data": {
    "total": 2,
    "list": [
      {
        "id": "20260730001",
        "title": "Requestly规则调试",
        "status": "PROCESSING"
      },
      {
        "id": "20260730002",
        "title": "接口Mock验证",
        "status": "COMPLETED"
      }
    ]
  }
}

然后创建 Redirect Rule：

Source:
URL Equals https://test-api.example.com/api/tasks?page=1&pageSize=20

Destination:
Requestly File Server生成的JSON地址

File Server 还可以设置状态码、Content-Type、响应 Header 和 Latency，很适合构造稳定、可共享的 Mock。

12.3 方案三：一次测试完整的加载失败体验

创建一个规则组"首页异常测试"：

规则1：用户接口延迟3000ms
规则2：推荐接口返回500
规则3：阻断analytics.js
规则4：头像接口返回404

重点检查：

• 首屏是否一直白屏；
• 核心功能是否被非核心接口拖住；
• 图片失败是否有占位图；
• 错误提示是否明确；
• 重试按钮是否只重试失败请求；
• 页面是否产生重复请求。

这种组合场景比单独测一个 500 更接近真实网络问题。

---

十三、Requestly规则速查表

规则	典型用途	使用建议
Redirect	固定请求跳转到另一个地址	单接口、固定资源优先
Replace	批量替换域名、路径或版本号	环境切换最省规则
Map Local	用本地文件替换远程资源	调试 JS、CSS、JSON
Map Remote	映射到另一个远程资源	测试不同 CDN 或远程版本
Modify Headers	添加、删除、覆盖请求/响应 Header	Token、租户、灰度和 CORS 调试
Modify Query Params	修改 URL 查询参数	分页、语言和功能开关
Modify Request Body	修改提交数据	构造边界值和非法输入
Modify API Response	修改状态码、Header 或响应体	Mock、异常场景和权限组合
Delay	增加指定毫秒延迟	Loading、超时和竞态测试
Cancel Request	阻断请求	断网、资源失败和降级验证
Modify User-Agent	模拟浏览器或设备 UA	兼容性与服务端分流测试
Insert Scripts	注入 JavaScript 或 CSS	临时验证页面行为和样式

---

十四、常见问题

Q：规则已经打开，为什么刷新页面还是原来的结果？

先检查规则是否命中，再关闭缓存和 Service Worker。若是静态资源，浏览器缓存是最常见原因；若是 API，则检查请求是否经过当前浏览器扩展或 Desktop App 代理。

Q：Redirect 和 Replace 到底有什么区别？

Redirect 更像完整地址映射，适合一个明确入口到一个明确目标；Replace 是替换 URL 中的一段，更适合批量切换域名、路径和版本号。

Q：可以用 Requestly 解决线上 CORS 吗？

它适合本地调试和验证，但不应该代替服务端正式配置。尤其涉及预检请求和凭证模式时，最终仍需后端或网关正确返回 CORS Header。

Q：为什么修改响应后页面报 JSON 解析错误？

检查响应 Body 是否为合法 JSON、Content-Type 是否仍为 application/json、脚本是否返回了字符串，以及是否错误地把 JavaScript 对象直接作为响应文本。

Q：浏览器扩展和 Desktop App 应该同时开吗？

一般不需要。普通网页流量用扩展即可；跨浏览器、移动设备、桌面应用和终端流量使用 Desktop App。两套拦截同时生效会增加排查难度。

Q：团队成员怎样复现同一套规则？

可以使用 Workspace、Shared List 或规则导出。推荐按业务场景分组，并在分享前删除 Token、Cookie、内网地址和真实用户数据。

---

十五、我的使用建议

Requestly 的学习成本不在规则数量，而在匹配边界和场景管理。日常开发中掌握下面几类已经能解决大部分问题：

1. 用 Contains、Wildcard 和 Regex 精确圈定请求；
2. 用 Replace 做环境切换；
3. 用 Modify Headers 和 Modify Body 构造请求条件；
4. 用 Modify API Response 与 File Server 完成 Mock；
5. 用 Delay 和 Cancel 补齐弱网及失败测试；
6. 用 Test This Rule 和 DevTools 验证最终效果；
7. 按业务场景分组，用完及时关闭。

我最推荐的做法是从一个真实痛点开始，例如"订单接口临时切到本地"，先创建一条范围足够小的规则。确认生效后，再逐步增加 Header、响应 Mock 和异常场景。这样规则始终可解释，出现问题时也容易拆开排查。

---

参考链接

• Requestly HTTP Interceptor 官方概览
• Requestly HTTP Rules 官方说明
• Source Conditions 官方文档
• Redirect Rule 官方文档
• Modify Headers 官方文档
• Modify Request Body 官方文档
• Modify API Response 官方文档
• Delay Rule 官方文档
• Test This Rule 官方文档
• Cloud-based Mocks 官方文档

---

如果这篇文章帮你理清了 Requestly 的规则选择和排查方法，可以点个赞、收藏一下。你在联调中还有哪些必须靠改请求才能复现的场景，也欢迎放到评论区交流。