浏览器请求头编辑实战：把半小时的手动调试压缩成一条规则

浏览器请求头编辑实战：把半小时的手动调试压缩成一条规则

【免费下载链接】HeaderEditorManage browser's requests, include modify the request headers, response headers, response body, redirect requests, cancel requests项目地址: https://gitcode.com/gh_mirrors/he/HeaderEditor

"又是 401。"这已经是我今天第五次因为缺一个认证头而卡壳。在开发者工具里反复复制粘贴 Token、手动切换环境、被跨域问题折腾到怀疑人生——直到装上 Header Editor 这个开源扩展我才明白：浏览器请求头编辑这件事，完全可以交给规则自动完成。

如果你也每天在接口文档和浏览器控制台之间来回横跳，这篇实战笔记应该能帮你在十分钟内摆脱重复劳动。放心，全程不需要改一行业务代码。

先认识这位"请求管家"

Header Editor 是一个开源免费的浏览器扩展，一句话就能说清它的全部能力：修改请求头、修改响应头、修改响应体、重定向请求、取消请求。

有意思的是，它本身"什么功能都没有"。这话听起来奇怪，但它的设计逻辑很像一把钥匙柜：Header Editor 只提供编写和管理规则的能力，至于你要它做什么，全看你写了什么规则。

这样设计的好处很实在——规则本质是文本，可以复制、分享、备份，换台电脑也不用从零开始。你写的每一条规则，其实都在回答两个问题：管哪些请求？以及怎么管？

我更爱把它想象成住在浏览器里的安检员：每个请求进出都得过一遍他的检查清单，清单上写什么，他就执行什么。

装哪个版本？先看这张表

动手之前搞清楚一件事：Header Editor 分精简版和完整版，别下错了。

DNR（declarativeNetRequest）是浏览器提供的一种声明式规则引擎，性能更好、更省资源；Web Request 模式则功能更全面，代价是性能稍逊。简单说：没有特殊需求，直接用精简版。哪天发现某个功能用不了，官方文档里有完整的版本对比表（见docs/docs/zh-CN/guide/index.md），对照着看就行。

五步，写出人生第一条规则

装好后点浏览器右上角的 HE 图标，管理面板就出现了。右下角那个加号按钮，是之后所有故事共同的起点。

以"给本地开发环境的接口自动加认证头"为例，这条规则只需五步：

1. 点加号新建规则，起个名字，比如"本地 API 自动认证"；
2. 匹配类型选"网址前缀"，填http://localhost:3000/api/；
3. 功能类型选"修改请求头"；
4. 头名称填Authorization，头内容填Bearer dev-secret-123；
5. 保存，并确认规则开关处于打开状态。

就这么简单。从此所有以http://localhost:3000/api/开头的请求都会自动带上认证头，你不再需要每次打开 Postman 复制粘贴，也不用在代码里埋一个"测试专用"的硬编码 Token。

记住这个万能公式：匹配条件 + 执行动作。后面所有高阶玩法，都是它的变体。

匹配条件：给请求写一张"收货地址"

规则要精准生效，匹配条件必须写对。Header Editor 一共提供六种匹配方式：

• 全部：匹配所有 URL，适合全局规则；
• 正则表达式：最灵活的匹配方式，还支持$1这类占位符；
• 网址前缀：包含https://在内的前缀，日常最常用；
• 域名：包含子域名的完整域名；
• 网址：含?及之后所有参数在内的完整地址；
• 请求方法 / 资源类型：GET、POST，或者图片、脚本、XHR 等类型。

勾选多个条件时，必须同时满足才算命中。这就像快递单上的收货地址，省市区层层嵌套，任何一级对不上，包裹就到不了你手里。

正则匹配还能把捕获的内容"搬运"到新地址。比如把京东的 HTTP 请求全部升级成 HTTPS：

匹配：http://(sale|item|www).jd.com 动作：重定向至 https://$1.jd.com

这里的$1会自动取到括号里匹配到的内容，一条规则就把所有子域名的跳转都覆盖了。

另外还有一类排除规则：哪怕请求满足全部匹配条件，只要踩中任何一条排除条件，规则立即失效。"除了登录页全都生效"，这种需求就是它的主场。

小提醒：精简版在排除条件里不支持正则表达式，配置的时候别踩坑。

四种动作，对应四种"管法"

规则可执行的动作有四种，分别作用于请求的不同阶段：

举个"改响应头"的例子：本地调试时前端被跨域卡住，与其去麻烦后端同事改配置，不如自己加一条规则：

匹配：资源类型为 xmlhttprequest 动作：添加响应头 Access-Control-Allow-Origin: *

三秒搞定，前端照常请求，后端一行代码都不用动。同一种手法还能做静态资源长期缓存（Cache-Control: public, max-age=31536000）、给全站补安全头（X-Frame-Options: DENY），操作套路完全一致。

两个藏在细节里的小暗号

用久了你会发现官方文档里写着两个特殊值，我管它们叫"暗号"。

第一个暗号是_header_editor_remove_。把某个请求头或响应头的值设成这串字符，就能直接删除这个头。想干掉网页里的跟踪 Cookie？一条规则的事。

第二个暗号是_header_editor_cancel_。在重定向功能里返回这串字符，就能取消整个请求。比如拦掉所有带utm_source参数的追踪链接：

if (val.includes('utm_source')) { return '_header_editor_cancel_'; }

完整版专属：规则写不出的逻辑，交给自定义函数

普通规则是"填空题"，自定义函数则是"问答题"。完整版支持用 JavaScript 写一段逻辑，动态决定请求的去向或头的内容。它只出现在三种场景：重定向、修改请求头、修改响应头。

函数接收两个参数：val（当前值）和detail（请求详情）。注意，你只需写函数主体，不用管外层包裹。比如给 User-Agent 追加一个版本号：

for (const a in val) { if (val[a].name.toLowerCase() === 'user-agent') { val[a].value += ' HE/2.0.0'; break; } }

detail对象里藏着请求的各种情报：请求方法、资源类型、发起页面、时间戳、代理信息，Firefox 下还能拿到隐私模式的标记。比如"只把 example.com 下的媒体文件重定向到 example.org"，正则很难写，函数一句话：

if (detail.type === "media") { return val.replace("example.com", "example.org"); }

想调试自定义函数，直接打开扩展的后台页面（Chrome 在chrome://extensions/的"检查视图"里，Firefox 在about:debugging里），控制台输出全都在那。详细的函数说明可以看官方文档docs/docs/zh-CN/guide/custom-function.md。

规则攒多了？分组、备份、同步一条龙

规则攒到几十条后，管理就成了新问题。Header Editor 支持按组归类——"认证组""缓存组""调试组"，按项目分、按功能分都行。我的习惯是把临时调试用的规则单独放一组，用完整组一键禁用，清爽又不误伤。

迁移和备份也有完整方案：

• 导入导出：规则本质是 JSON 文件，随时导出留档，换电脑一键恢复，团队协作也能靠它共享配置；
• 云同步：自 4.0.5 起支持，基于浏览器自带的同步机制（Firefox Sync / Chrome Sync），数据存在浏览器厂商的服务器上，不经过第三方，隐私有保障。注意同步容量大约只有 100KB，规则特别多时可能上传失败，这时候老老实实走导入导出；
• 第三方规则：官方文档里整理了一些社区维护的规则包，比如 Google 资源重定向，下载导入即可用，适合不想从零写的人。

避坑指南：我替你踩过的五个坑

与其看干巴巴的 FAQ，不如看看我实际踩过的坑，能帮你省不少排查时间。

坑一：改完响应头，开发者工具里却"没变化"这是假象。Chrome 和 Firefox 的开发者工具都不会显示扩展修改后的响应头，请以实际效果为准。把content-type改成text/plain，页面真的会变成纯文本，但工具里可能仍显示text/html。

坑二：头名称怎么全变小写了？这是 4.0.0 之后的正常行为。HTTP 规范（RFC 2616）规定头名称不区分大小写，扩展索性统一转成小写，符合规范，不用慌。

坑三：头内容留空，两个浏览器行为不一样Chrome 会保留一个空头，Firefox 则会直接移除。想让两边行为一致，请使用删除暗号_header_editor_remove_。

坑四：某些地址死活改不动Chrome 及同类浏览器不允许扩展修改chrome.google.com/webstore开头的请求，这是浏览器的硬性限制，规则写得再对也没用。

坑五：启用修改响应体后，Chrome 弹了个调试提示别慌，这是正常的。修改响应体在 Chrome 上依赖 debugger API，所以会提示"已开始调试此浏览器"。不想看到它，可以在选项里关掉该功能，或给 Chrome 加--silent-debugger-extension-api参数启动。

规则不生效时，按这个顺序排查：先看规则开关有没有开，再看匹配条件是否过宽或过窄，用网络面板确认请求真的走了，最后检查是不是被排除规则拦了。

免费、开源、无追踪，还能自己动手改

最后说点让人安心的事：Header Editor 完全免费、无广告、不上传任何用户数据，所有规则都保存在本地浏览器里。作为开源项目（GPL 协议），它的代码完全公开、接受社区审查——对在意隐私的人来说，这一点比功能本身更重要。

想自己构建或贡献代码？几步就好：

git clone https://gitcode.com/gh_mirrors/he/HeaderEditor pnpm i --frozen-lockfile npm run build:chrome_v2 # Chrome 完整版 npm run build:chrome_v3 # Chrome 精简版 npm run build:firefox_v2 # Firefox 完整版 npm run build:firefox_v3 # Firefox 精简版

对技术实现感兴趣的话，请求处理的核心代码在src/pages/background/request-handler/目录，规则、自定义函数、修改响应体的完整文档则在docs/docs/zh-CN/guide/下，都值得翻一翻。

写在最后

回头看，那位折磨了我一下午的"401 之敌"，其实只花十分钟就被一条规则彻底消灭了。从那以后，浏览器请求头编辑这件事对我来说就浓缩成了三个字：写规则。

如果你也每天在开发者工具和接口文档之间来回切换，不妨花五分钟装上 Header Editor，写下你的第一条规则。相信我——当你看到那个一直报错的接口突然"自己变好"的那一刻，你会回来感谢这个不起眼的小扩展。

【免费下载链接】HeaderEditorManage browser's requests, include modify the request headers, response headers, response body, redirect requests, cancel requests项目地址: https://gitcode.com/gh_mirrors/he/HeaderEditor