15 分钟上手 Header Editor：从改请求头到拦截请求的完整清单

15 分钟上手 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

加班到深夜，他决定换一种方式联调

阿凯在一家电商公司写前端。他的日常是：本地起一个开发环境，对接测试环境的 API，偶尔还要切到预发布环境看效果。问题在于，三个环境的接口都要求不同的认证令牌，他每天相当一部分工作，是在代码里搜 token、改 token、再刷新页面。

直到有天晚上，他把测试令牌忘改回去，一口气提交到了生产分支。那晚的教训让他明白：联调不该靠人肉记忆。他找到了一款叫 Header Editor 的开源免费浏览器扩展——它能修改浏览器发出的请求，包括请求头、响应头、响应体，也能把请求重定向到别的地址，或者干脆取消它。装上之后，环境切换变成了点一下开关的事。

Header Editor 是一款面向浏览器请求控制的扩展，核心是"接管浏览器发出的每一个请求"。它本身不生产功能，而是给你一张"规则表"：你写下规则，它负责在请求离开浏览器前、或响应回到浏览器时，按你的要求动手。这份 Header Editor 指南面向零基础用户，从安装到进阶全程不用写几行代码。

立刻上手：装好扩展，3 分钟跑通第一条规则

安装：选商店还是本地加载？

精简版和完整版的区别一句话能说清：完整版多了"自定义函数"和"正则排除"这类高级能力，普通用户从精简版开始就够用。装好后，浏览器工具栏会多一个带铅笔图标的 HE 按钮。

第一条规则：把网页伪装成手机版

这一步只花两分钟，但足以让你感受到整套系统的工作方式：

1. 点击工具栏的 HE 图标，打开管理面板。
2. 点右下角的"添加"按钮，新建一条规则。
3. 匹配条件选"网址前缀"，填https://m.example.com/。
4. 功能选"修改请求头"，头名称填User-Agent，内容填一段 iPhone 的 UA 字符串。
5. 保存，刷新页面。

此时访问m.example.com，服务器收到的 UA 就是你的手机型号。按 F12 打开开发者工具，在网络面板点开任意请求，就能在"请求头"里看到改动后的痕迹。

验证小技巧：不少网站会按 UA 返回不同页面，改完 UA 再看网页结构，如果和原来不一样，说明规则已经生效。这是 Header Editor 修改请求头最直观的体验。

换个角度看核心能力：把每个请求想象成一个快递包裹

先不看功能清单，看一个类比。浏览器每次访问网页，都相当于寄出一个快递包裹：

• 快递单上的寄件人、收件人、备注，就是请求头。
• 快递要送到的地址，就是请求的 URL。
• 包裹里的东西，就是服务器返回的响应体。
• 快递员的回执单，就是响应头。

Header Editor 就是你家楼下的快递中转站。它能在三个环节动手脚：

这套心智模型的好处是：遇到任何网络层面的怪问题，先问自己"这是快递单的问题、地址的问题，还是包裹内容的问题"，再决定配哪类规则。规则之间还能叠加——同一个请求可以既改头、又改地址，也可以按优先级让特定规则先执行。

真实案例集：五个高频需求，照着配就行

下面五个案例覆盖了大多数人装 Header Editor 的真实动机。每个案例都是"问题 → 操作 → 前后对比"，参数可以直接照抄。

案例一：多环境联调，自动携带认证令牌

问题：前端联调时要在开发 / 测试 / 预发布三个环境间切换，每个环境的 Authorization 都不同，手工改代码容易忘改、改错。

操作：

1. 新建规则，匹配条件选"网址前缀"，填https://test-api.example.com/。
2. 功能选"修改请求头"，头名称Authorization，值填Bearer test-token-123。
3. 再建一条同样的规则，前缀换成预发布地址，令牌换成另一份。

前后对比：之前每次切环境要改代码、重新编译；现在切环境 = 切换规则开关，联调请求自动带对令牌，省掉了最易出错的环节。

案例二：图片防盗链，改 Referer 让图片正常显示

问题：把站外图片贴到自己页面，很多图床会返回 403，因为请求携带的 Referer 指向了"不被信任"的域名。

操作：

1. 新建规则，匹配条件选"网址前缀"，填图片所在的域名，如https://imgsrc.example.com/。
2. 功能选"修改请求头"，头名称Referer，值填一个允许访问的站点地址，如https://www.example.com。

前后对比：改之前图片位置一片灰；改之后图片正常加载。这个思路对多数防盗链场景通用，社区里也流传着大量现成的 Referer 规则可以直接导入。

案例三：本地调试跨域接口，补上 CORS 响应头

问题：本地起的前端要调用另一个域的 API，浏览器因为缺少 CORS 头直接拦截，控制台一片报错。

操作：

1. 新建规则，"资源类型"选xmlhttprequest，匹配地址填 API 域名。
2. 功能选"修改响应头"，依次添加三条：
   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST, PUT, DELETE
   • Access-Control-Allow-Headers: Content-Type, Authorization

前后对比：改之前请求被浏览器拦下（网络面板标红）；改之后接口正常返回数据。这条规则适合调试期顺手用，生产环境请让后端正规配置 CORS。

案例四：取消埋点和跟踪请求，让页面安静下来

问题：某些第三方统计脚本会在每个页面偷偷发请求，拖慢加载，还可能泄漏访问行为。

操作：

1. 新建规则，匹配"网址前缀"或正则，填埋点域名的特征路径。
2. 功能选"取消请求"。

前后对比：改之前网络面板里躺着几十个埋点请求；改之后这些请求直接消失，页面加载明显变快。规则粒度可以很细，只拦特定路径、放行其余。

案例五：临时替换页面内容，验证前端展示

问题：想看看某段文案或某个接口返回字段换成别的值后，页面渲染成什么样，但改服务端成本太高。

操作（需要完整版；Chrome 下启用响应体修改会提示"已开始调试此浏览器"，属正常现象）：

1. 新建规则，匹配目标网址。
2. 功能选"修改响应体"，编码保持 UTF-8。
3. 在自定义函数里写一句替换逻辑，例如把页面中的baidu全部替换成Google：

return val.replace(/baidu/g, 'Google');

前后对比：改之前页面显示原文；改之后打开同一网址，文案已按规则替换，适合快速做文案与展示的验证。

进阶玩法：当"改头换面"不够用时，你还有三张牌

第一张牌：自定义函数，规则写不出的逻辑交给代码

完整版支持在规则里挂一段 JavaScript，动态生成头值、按条件决定是否重定向。它接收val和detail两个参数，前者是当前 URL 或头数组，后者包含请求方法、资源类型、发起页面等信息。例如只把图片和视频请求重定向到另一个域名：

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

官方提醒：能用普通规则解决的就别用函数，函数是最后的手段。想深入研究，看 custom-function.md。

第二张牌：运行模式，用性能换能力的选择题

每条规则都有两种运行模式：

日常使用建议优先 DNR，遇到搞不定的场景再切 Web Request。

第三张牌：规则资产化，分组、导入导出、云备份

规则多了以后，Header Editor 提供完整的资产管理：按功能分组（认证组、缓存组、调试组）、一键导入导出分享给团队、绑定云备份防止丢失。社区里也有现成的"第三方规则"可直接下载启用，详见 third-party-rules.md 与 cloud-backup.md。

如果你对技术实现感兴趣，请求处理的核心逻辑在src/pages/background/request-handler/目录下，包含 DNR 处理器、Web Request 处理器和响应修改器三块。想本地跑起来，先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 精简版），产物在dist_*目录。

新手指南常见疑问

Q1：规则配好了，为什么没生效？按顺序排查：规则开关是否打开 → 匹配条件是否写得太宽或太窄（先从前缀匹配试起）→ 是否被排除规则命中 → 是否命中浏览器限制（如 Chrome 不允许改chrome.google.com/webstore开头的请求）→ 刷新页面再试。

Q2：精简版和完整版到底选哪个？只改请求头、重定向、取消请求，精简版完全够用且性能更好；需要自定义函数或正则排除，再上完整版。Chrome 上完整版不走应用商店，需要下载 crx 本地安装。

Q3：Chrome 提示"Header Editor 已开始调试此浏览器"，正常吗？正常。这是启用"修改响应体"功能时调用了 Chrome 的调试接口所致。介意的话，在选项里关掉"修改响应体"，或给 Chrome 加--silent-debugger-extension-api参数启动。

Q4：怎么删除某个请求头？把该头的值设为_header_editor_remove_即可，这是从 3.0.5 起内置的约定值，比空值更可靠。

Q5：改了响应头，为什么开发者工具里看不到？开发者工具显示的是浏览器缓存的一份原始记录，不代表实际生效情况。验证办法很直接：把content-type改成text/plain，网页立即以纯文本显示，就说明规则真的生效了。

最后的话：给浏览器一张"可以改的快递单"

回到阿凯的故事。装上 Header Editor 之后，他的环境切换变成了一次点击，测试令牌再也没被带进生产环境。他常说，这个扩展最妙的地方不是功能多，而是把"调网络"从"改代码"里解放了出来——需求变了，改规则；环境换了，切开关，代码一行不动。

你现在就可以做三件事：去商店装上 Header Editor（精简版即可）；照着上文的第一条规则改一次 UA，体验规则从配置到生效的完整闭环；然后把你最常遇到的网络问题，对照快递中转站的三个环节，配出属于自己的第一条规则。

网络请求每天都在发生，而控制权，值得握在你自己手里。

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