# 改网络请求和响应:chrome-use network route 详解

开发的时候,总有几个时刻想临时改一下网络:后端接口还没好,想先拿一份假数据把前端跑通;想试试某个请求带上不同的参数会怎样;想把某个统计/埋点请求直接掐掉。以前干这些,要么改代码加开关,要么起一个 mock server,要么挂个抓包代理(还得装 CA 证书)。都不算重,但都要额外搭点东西。

chrome-use 的 network route 把这件事收进了浏览器本身:直接在你驱动的这个 Chrome 上拦截匹配的请求,mock 掉响应、或者改掉发出去的请求、或者干脆阻断。不用代理、不用证书、不用改被测代码。

四种用法

一条 network route 命令,按你给的参数决定做什么:

# 1) Mock 响应:请求根本不发出去,直接返回你给的假数据
chrome-use network route "*/api/me" --body '{"vip":true}' --status 200 --content-type application/json

# 2) 改请求:请求照发,但改掉方法/头/体/地址,真实响应照常回来
chrome-use network route "*/api/save" --method POST --set-header Authorization="Bearer test"
chrome-use network route "*/v1/*" --rewrite-url https://staging.example.com/v1/thing

# 3) 改真实响应:请求照发,拿到真实响应后再改状态/头/体
chrome-use network route "*/api/me" --edit-status 503 --edit-header X-Env=test --replace 'prod=>staging'

# 4) 阻断:直接掐掉(屏蔽埋点、断网测试)
chrome-use network route "*/analytics" --abort

区分很简单:带 mock 字段(--body / --status / --header / --content-type)就是伪造一个响应,请求被短路、不出网;带请求字段(--method / --set-body / --set-header / --rewrite-url)就是改完再放行、拿真实响应;带编辑字段(--edit-status / --edit-header / --replace 'from=>to')就是放行、等真实响应回来后再改它。mock 和"改真实响应"的区别在这:前者根本不出网、你自己造数据,后者要真实响应回来、你只改其中几处。这几类的头相关参数都能写多次,在原有头上合并覆盖。

命名有意对齐了 Playwright 的 route / fulfill / continue / abort,用过的人不用重新学。

原理:一个已经在讲的协议

这套东西底层就是 Chrome DevTools Protocol 的 Fetch 域:Fetch.enable 挂上匹配规则,命中的请求会停在 Fetch.requestPaused,然后按情况调用 fulfillRequest(返回假响应)、continueRequest(带覆盖参数放行)或 failRequest(阻断)。这不是新造的机制:DevTools 里的 "Local Overrides"、Playwright 的 route,底层给 Chrome 做拦截,包的都是同一个 Fetch 域。

对 chrome-use 来说,关键有两点。

一是它本来就在讲 CDP。chrome-use 用自己的原生 CDP 客户端驱动浏览器,fulfillRequest / continueRequest 这些命令早就在代码里(域名过滤、代理认证都用它)。加 mock 和改请求,基本是把已有的执行能力从命令行透出来,不是从头写一套。

二是它不碰浏览器扩展的权限。chrome-use 连真实 Chrome 走的是扩展的 chrome.debugger 通道,拦截请求就是通过这个通道多发几条 CDP 命令。扩展的 manifest 一个字不用改,不需要 webRequest,更不需要 declarativeNetRequest,而后面这两个恰恰是 Chrome 应用商店重点审查的权限。所以这个功能不引入任何新权限,也就没有连累扩展过审的风险。

顺带说下为什么没有直接集成一个现成的 mock 工具。调研过一圈:mockttp 是进程内的 Node 代理、要自签 CA;mitmproxy 是独立的 Python MITM 代理、也要装证书;MSW 靠往页面注入 Service Worker,这条直接违背 chrome-use "零 JS 注入" 的隐身原则。它们要么重、要么要代理加证书、要么破坏隐身,而给 Chrome 做拦截,它们包的还是那个 CDP Fetch。既然自己已经在讲这个协议,把表层补齐就是最轻的路。

真机跑一遍

拿 httpbin.org(会把请求原样回显)验证两条主路径,起一个隔离浏览器跑。

Mock 响应:给 /get 设一份假数据,再从页面里 fetch 它:

chrome-use --launch --session demo network route "*/get" \
  --body '{"mocked":true,"by":"chrome-use"}' --status 200 --content-type application/json
chrome-use --session demo open https://httpbin.org/
# 在页面里:fetch('/get') → {"mocked":true,"by":"chrome-use"}

返回的是设好的假数据,不是 httpbin 真实的 /get 响应,请求根本没出网。

改请求:给 /headers 加一个自定义头,再 fetch 它(httpbin 会把收到的请求头回显回来):

chrome-use --session demo network route "*/headers" --set-header X-Chrome-Use=hello123
# 在页面里:fetch('/headers') → 回显的 headers 里出现 "X-Chrome-Use": "hello123"

httpbin 回显的请求头里带上了 X-Chrome-Use: hello123,说明这个头是在请求真正发出前被加进去的。

改真实响应用 example.com 验:让请求照常发出、拿到真实页面,再把响应体里的字样替换掉、状态码改成 599、加一个响应头。

chrome-use --launch --session demo network route "*example.com/" \
  --edit-status 599 --edit-header X-Edited=yes --replace 'Example=>EDITED' --resource-type xhr,fetch
chrome-use --session demo open https://example.com/
# 在页面里 fetch('/') → {status:599, xedited:"yes", bodyEdited:true}

拿到的是真实响应被改过的版本:状态码变成 599、多了 X-Edited 头、体里的 Example 被换成 EDITED。这里用 --resource-type xhr,fetch 把编辑限定到接口请求,不去动顶层文档的导航(把导航文档的状态码改成错误码会让页面加载语义变乱)。

当前边界

改真实响应目前是"取回整段响应体、做字符串替换 + 覆盖状态/头"。够日常改字段、造错误态用;更细的结构化改写(比如只改 JSON 里某个字段)现在靠字符串替换顶,后面看需求再说。另外我们本来就能录 HAR,下一步打算让录下来的 HAR 条目直接当 mock fixture 用,录一次、回放时改改就行。

两个仓库:chrome-use 在 github.com/leeguooooo/chrome-use;完整命令 chrome-use skills get core 拉到本地看。