一条规则，让 FAT 前端直连 UAT 后端——不改代码、不改 CORS

它拦截页面发出的 API 请求，并把请求送到别处。在研发场景里，通常就是让一个连着某个后端的前端页面改连另一个环境，于是不改应用代码、不重新部署，也能在 FAT 页面上验证只有 UAT 才有的修复。

页面主世界的拦截器会接管 fetch、XMLHttpRequest 与 WebSocket，相对地址在匹配前先解析为绝对地址。仅重写 URL 的规则会被编译成 declarativeNetRequest 重定向，由浏览器对匹配的各类资源生效：主文档与子框架、XHR、脚本、样式、图片、字体、媒体与其他。

通配符把 * 视为任意字符，并把结尾 * 捕获的内容拼接到目标地址之后；前缀匹配 URL 开头，把剩余部分拼到目标之后；正则要覆盖整个 URL 才能让两条通道结果一致——后台通道只替换模式命中的那一段，网络层则整条替换，因此建议用 ^ 锚定并把结尾写成 (.*)$。多条规则同时命中时，优先级数值小者优先，数值相同则按规则列表里的先后顺序，请给每条规则不同的数值。

内容脚本注入到所有 http 与 https 页面，规则按请求 URL 匹配，因此内网系统、localhost 开发服务、预发域名都适用。chrome:// 页面、Chrome 应用商店与其他扩展页面被浏览器统一限制，任何扩展都无法注入。

免费，没有内购也没有订阅，不需要注册或登录任何账号。扩展没有自有的云端服务——规则、凭据变量与日志只写在你本机的 chrome.storage.local 里。

使用了任一高级能力（请求头覆盖、请求体覆盖、响应覆盖、Mock、延迟、阻断、重试、方法过滤、查询参数注入、携带 Cookie、WebSocket）的规则，由持有主机权限的扩展后台上下文发出请求，页面拿到的是扩展构造的响应，因此不会触发页面侧的 CORS 校验。仅重写 URL 的规则走网络层重定向，浏览器仍会校验重定向后响应的 Access-Control-Allow-Origin。若目标环境不允许你的源，给规则加上任一高级能力（加一个响应头覆盖代价最小）即可切到后台通道。

这是网络层的一条硬边界，实测 Chrome 155：把请求改写到 另一个原点 的纯 URL 重写规则，目标收到的 Origin 是 null，不是你页面自己的源；改写后仍落在同一原点内的规则不受影响。Origin 成了 null，按来源白名单放行的后端就会拒掉这一笔，哪怕它本来就允许你的前端域名，页面侧表现为 net::ERR_FAILED。两条解法：让落点环境放行任意来源，或者给规则加一项高级能力（响应头覆盖代价最小）切到后台代发——后台那一次请求由扩展自己发出，页面侧的 CORS 校验根本不参与。

因为网络层表达不了你想要的行为。不以 * 结尾的通配符、目标地址为空，或者带了任一高级能力，都会被刻意路由到后台通道——若强行编译成重定向，结果会被悄悄改变。URL 匹配测试器会在你依赖某条规则之前，把任意 URL 的转发通道显示出来。

只重写 URL 的规则单请求零 JavaScript 开销，由浏览器网络栈直接完成重定向。走后台通道的请求会多一次扩展内的中转，外加你配置的延迟，单个代理请求有 30 秒上限。用户编写的正则会先做嵌套量词 ReDoS 检测，送往网络层的正则还需通过 Chrome 的 RE2 校验——一条不支持的正则会让整批规则安装失败，因此在同步前就被过滤掉。

网络层重定向不会经过扩展，没有可记录的逐条请求。规则级命中数会出现在「DNR 命中统计」里，统计窗口为最近 5 分钟；Chrome 对该读取接口有配额限制，因此面板按需刷新，超出配额时保留上一次结果并标出统计可能有延迟。后台通道的命中数单独统计。

按这个顺序看：弹窗里的总开关是否开启（关闭时网络层规则会一并卸载）→ 这条规则本身是否处于启用状态 → 这一页是否重新加载过，已经发出的请求不会被追溯改写 → 在「URL 匹配测试」里输入实际请求地址，看它是否被一条优先级更靠前（数字更小）的规则遮蔽 → 用正则时确认它覆盖整条 URL：网络层用替换结果整体替换 URL，后台通道只替换命中的片段，覆盖不全的正则在两条通道上结果不同——扩展里的「URL 匹配测试」会把两个地址一起摆出来，指着那一格说清是在哪一步分的岔。复杂规则还多一处可看——后台确实记下「这一页没接到那次配置推送」时，弹窗会出现一句「此页尚未收到最新配置，刷新这一页通常可恢复」，句子右边就有一枚「刷新这一页」按钮（只在这一次真的问到那一页时才出现，点它等于按浏览器自己的刷新），悬停进一步点名是哪种原因：这一页早于扩展的安装 / 更新 / 重载打开（刷新即可），或该站点禁用了扩展（要在 Chrome 的扩展菜单里为它重新开启）。这句只说它有把握的事：非 http(s) 页、正在加载的文档、以及从没记过这笔账的页面统统保持沉默。还有一种情况是这一页压根没有规则覆盖它：弹窗的「为当前页创建规则」会先把哪几个来源像是被跨域拦下说出来（那些来源在候选里带「疑似」标记、排在最前），读的是这一页自己报错、却没有被任何规则接住的原生请求；被 CORS 拦下、断网、DNS 失败在页面上是同一个形状，所以它是帮你排顺序的线索，不是结论。想一次问完而不是逐条排查，可以按弹窗动作区那颗「自检」（配置页也可直接开 #self-check）：一屏按上面这个顺序摆出五个现成读数——总开关、这一台站点在不在生效范围、后台有没有记下「这一页没收到最近一次配置推送」、这一页的地址命中哪条规则与走哪条通道、网络层规则有没有真的装进浏览器；每一格只复述一个已经在别处算过的判据，读不到或还没判完的，分别画「不知道」与「还没定」，不会替上面任何一步编一个答案。

一条规则可以挂多组条件——URL 正则、HTTP 方法、查询参数——首个命中的条件决定响应体、状态码与 Content-Type，全部不命中时回落到规则的默认响应体。于是一条规则就能替多个接口、或同一接口的多种状态兜底。Mock 请求完全不触网，返回状态码被钳制在 200–599。

阻断让请求以网络故障的方式失败，用来验证离线兜底与重试逻辑；改写响应状态码则给你一个真实的 HTTP 错误码、状态文本与响应头，用来验证依赖状态码的错误渲染。被阻断的请求不会被原生回退重放——否则发出去的正是你要压掉的那个请求。

重试是规则级开关，运行在后台通道。开启后，规则在首次请求之外追加 1 至 5 次尝试，间隔可在 100 至 30000 毫秒之间设置（默认 1000 毫秒）。某次尝试抛出异常（包括触及单请求 30 秒上限被中止）、或返回 5xx 且仍有剩余次数时触发重试；次数用尽后把最后一次响应或错误交回页面。因为重试属于后台通道能力，启用重试的规则永远不会被判定为网络层重定向。

可以。导出为 JSON 配置，默认开启分享模式——自动剔除 Authorization、Cookie 等请求头与响应头、以及 token 类查询参数，需要本机全量备份时取消勾选即可原样导出；同事导入时可选择覆盖，也可与现有规则合并；可把捕获到的流量导出为 HAR 1.2，也可导入别处抓的 HAR 自动生成规则；粘贴一条 cURL 命令（DevTools「复制为 cURL」产物）即可预填规则表单。环境配置快照会保存整套规则的命名副本。规则里的凭据位点写成 {{UAT_TOKEN}} 这样的引用、真值单独存在「设置 → 凭据变量」里之后，导出的配置与环境快照从头到尾没有它，取消分享模式也不会带出去。

最多 200 条规则，最近 500 条请求日志，请求体上限 10 MB，回包正文同样 10 MB 封顶（越界那一笔判失败、不做截断返回；fetch 会按代理失败回退原生再发一次，XHR 不回退、直接以 status 0 报错），延迟 0 至 60000 毫秒，重试默认关闭、开启后追加 1 至 5 次尝试且间隔 100 至 30000 毫秒，单个代理请求 30 秒上限，Mock 与改写的状态码钳制在 200–599，以保证页面总能构造出合法的 Response 对象。

回退行为按通道不同。fetch 在拦截失败或代理失败（超时、超限、后台报错）时回退原生再发一次；XHR 只在同步请求与非字符串请求体这类「代理兑不了」的情况下回退原生，代发本身失败时不会重放，而是把 status 置 0 并派发 error，以免同一个写请求被执行两遍；WebSocket 始终由浏览器原生发出，扩展只改写地址。同步 XHR 与非字符串请求体必须回退，是因为代理要跨上下文往返，兑现不了「send() 返回时结果已就绪」这个契约，异步化只会让页面读到一个空响应。唯一的例外是阻断规则：被阻断的请求绝不会被原生回退重放。

在「试一条规则」面板里点「复制配置 JSON」或「下载 .json」，再打开扩展设置页的「导入/导出配置」，选中这个文件；导入模式选「合并（保留现有，追加新规则）」后确认。合并不会动你现有的规则，也不会替你打开总开关，所以导入后代理还关着的话，去弹窗里打开即可。这份配置里只有一条规则，带匹配类型、匹配模式与目标地址，不含请求头、查询参数或任何凭据。

不能。devServer 的代理按站点内的相对路径（例如 /api）转发，浏览器看到的请求仍然是同源的；要去的后端环境写在 devServer 配置里，从不出现在浏览器实际请求的 URL 上，而扩展的规则按请求 URL 匹配——这份配置里没有一条能对上真实地址，它的字段结构也不是扩展的导入格式。正确做法是按真实 API 来源建一条通配符规则：把 https://fat-api.example.com/* 指向 https://uat-api.example.com，面板里的「用测试地址填匹配模式」可以直接生成这个模式。

不会。规则、日志、环境快照与偏好设置都保存在本机的 chrome.storage.local 里。扩展不含统计埋点、不上传任何数据，也没有自有远程服务，唯一的网络流量就是你让它代理的 API 流量。需要留意的是，请求日志会在本机记录被代理的请求头与请求体（可能含 token），在分享导出的 HAR 或复制的 cURL 命令之前请先检查。

面向 Chrome（Manifest V3）构建与验证。Edge 支持 Chromium 扩展，同一份构建通常可用；Firefox 的 Manifest V3 在 declarativeNetRequest 上存在差异，目前不是支持目标。