三月十三日下午两点多，我照例打开那个对话式搜索入口，习惯性先扫了一眼地址栏——结果它又停在了那个带地区后缀的域名上。前一天同一个时间、同一台机器、同一套浏览器配置，它是能正常落到国际站的。我第一反应是扩展挂了，因为过去大半年，我一直靠一个能改写请求头的浏览器扩展，把Accept-Language、User-Agent里的几个字段调成我需要的样子，用来给手上几个多语言页面做对照测试。禁用、重装、重写规则、换扩展，折腾到快四点，我才确认了一件不太情愿承认的事：不是我的规则写错了，是"改请求头就能改变站点行为"这套思路，在这个产品上已经不好使了。
这篇东西写给两类人。一类是把"改请求头"当成日常调试手段的前端、测试、运维同学，你们大概这几天也遇到了类似的"昨天还灵、今天全废"；另一类是纯粹好奇"为什么一个改头的扩展会突然失效"的技术爱好者。核心结论先摆在这儿：客户端改请求头本来就是一副临时脚手架，它失效不是意外，是迟早的事。真正值得花时间的，不是找一个新的扩展去补上这个洞，而是把"这次跳转到底是谁下的决定"查清楚——查清楚之后你会发现，大多数情况下你根本没必要去改头。
1. "跳到区域站"这个决定，到底是谁下的
很多人（包括半个月前的我）默认跳转是"服务器看到我的 IP 或者我的请求头，返回一个 302"。这个心智模型只对了一小部分。从你在地址栏敲下回车，到地址栏变成区域站，中间至少有四个层级的角色在参与决策，而请求头只影响其中很窄的一块。
1.1 四个可能的决策者，逐个点名
第一层，浏览器自己。这里最容易背锅，也最容易被忽略。HSTS 预加载、之前缓存下来的 301（注意 301 默认会被浏览器长期缓存）、Service Worker 里写死的跳转逻辑、扩展注入的规则、甚至书签里存的旧 URL，任何一个都可能在请求真正发出去之前就把你送走了。我踩过最坑的一次是某个站点的 301 被缓存了将近一年，清 Cookie 完全没用，得单独清"缓存的重定向"那一项才恢复。
第二层，DNS 解析与边缘层。现在稍微有点规模的站点，域名解析出来的都是内容分发网络的边缘地址。边缘层拿到的第一个信息就是"这个连接从哪个网段来"，不少产品的地域路由就是在这里一次性完成的，压根不进入应用服务器。这一层的判定，你在浏览器里改任何请求头都碰不到，因为边缘层看的是 TCP 连接的对端地址，不是你的 HTTP 头。
第三层，应用层。到这里才轮到请求头说话。常见参与判定的信号有Accept-Language、Cookie里的地区偏好、登录态里的市场设置、User-Agent里的平台信息，以及Sec-CH-*这一族客户端提示头。注意关键词是"参与"而不是"决定"——大部分产品会把 IP 归属和 Cookie 偏好排在语言头的前面。
第四层，前端脚本。页面已经 200 加载完了，JS 调一个"我在哪"的接口拿到地区码，然后location.replace过去。这种跳转在 Network 面板里看不到 302，只有一条 XHR 加一次新的文档请求，特别容易被误判成"服务端跳的"。
把这张图铺开，问题就清楚了：你改请求头，最多只能影响第三层里"读头"的那部分判定逻辑。如果对方的判定重心在第一层缓存、第二层边缘，或者第三层里的 IP 和 Cookie，那你改一百个头也没用。
1.2 三步定位法：先看，再猜
我把排查顺序固定成三步，每次遇到"行为变了"都按这个走，省得来回猜。
第一步，用命令行看原始响应，绕开浏览器所有的缓存和扩展干扰：
curl -sSI -H 'Accept-Language: en-US,en;q=0.9' 'https://example.com/' | head -n 30重点盯四个东西：状态码是 200 还是 302、Location指向哪里、有没有Cache-Control和Vary、有没有Set-Cookie。如果命令行里行为是正常的（不跳），而浏览器里跳，那问题几乎百分之百在浏览器这一层——缓存、Cookie 或者扩展。反过来，如果命令行也跳，那基本可以确定是服务端策略。
第二步，在开发者工具里勾上 Preserve log（保留日志），重新走一遍。你要判断的是：第一个文档请求返回的是 302，还是 200 之后由 JS 发起跳转。这一条决定了你后面往哪个方向查。很多人跳过这步直接去改请求头，方向从一开始就错了。
第三步，用无痕窗口 + 禁用全部扩展做一次对照。无痕窗口清掉了大部分扩展和缓存，如果无痕下行为正常、普通窗口异常，那就是本地环境问题；两边都异常，就是服务端变了。这一步花不了一分钟，但能砍掉一半的无效排查。
1.3 四种跳转机制的区分表
同样是"地址栏变了"，背后的机制完全不同，排查手段也不一样。我整理了一张自己常用的对照表：
| 机制 | 典型特征 | 首要排查手段 |
|---|---|---|
| HTTP 3xx 重定向 | Network 里第一条请求状态码就是 301/302，Location明确 | 命令行curl -I看头部，检查Cache-Control |
| 前端 JS 跳转 | 首条请求 200，随后出现一条 XHR 和一次新的文档请求 | 在 Sources 里全局搜location.replace |
| meta refresh | HTML 源码里有http-equiv="refresh" | 直接看响应体前几十行 |
| Cookie 粘性 | 只有在带某个 Cookie 时才跳，清掉就恢复正常 | 逐条删除 Cookie 二分定位 |
再补一个容易被漏掉的细节：看响应头里有没有Vary: Accept-Language。如果没有这个头，说明缓存键里压根不包含语言，那么即使源站真的读了你改的语言头，你也很可能拿到的是别人（或者上一分钟的自己）缓存的版本，改与不改看起来没差别。这个细节能解释很多"改了但没反应"的困惑。
2. 请求头改写这条路的三个结构性缺陷
我在那半天里最深的感受不是"某个扩展坏了"，而是"我依赖的这条路，从设计上就不结实"。把缺陷拆开看，大致是三块。
2.1 扩展改头的能力边界一直在收窄
早期浏览器扩展可以拿到全量的网络请求拦截权限，在请求发出前任意修改头部，甚至能改写响应体。这套机制能力强、副作用也大，后来主流浏览器陆续把"阻塞式请求拦截"从普通扩展的能力里拿掉了，换成了声明式的规则接口：你只能提前声明"匹配这个 URL 的请求，把某个头设成某个值"，不能在里面写逻辑、不能读响应、不能根据结果动态决策。
这个变化带来的直接后果有三个。一是规则有数量上限，静态规则集和动态规则各有各的额度，规则一多就得做取舍；二是一部分头部被浏览器列为受保护，扩展改了也会被覆盖或者直接丢弃；三是不同浏览器的实现细节不一样，同一份规则在两个浏览器上表现可能完全不同。换句话说，"扩展能改头"这件事本身建立在浏览器愿意给你这个特权的前提上，特权一收紧，整条方案就跟着塌。
2.2 服务端压根不读你改的那个头
这是认知层面最大的坑。按规范，Accept-Language只是一个"偏好提示"，服务端完全可以忽略它。不少产品做国际化时，语言是靠账号设置或者 Cookie 决定的，请求头只用于首次落地时的兜底判断，甚至完全不参与。
客户端提示头（Sec-CH-UA、Sec-CH-UA-Platform这一族）更麻烦：需要服务端先在响应里通过Accept-CH主动声明"我要这些信息"，浏览器才会在后续请求里带上。也就是说，主动权在服务端手里，你单方面去改，改了也未必会被采信。
还有一个隐蔽的现象：某些头部是由边缘层在转发过程中重写或注入的，它们带着地理位置信息，客户端根本无从伪造。当你看到响应里出现一个你从来没发过的头，基本就能判断"判定发生在我够不着的地方"。
2.3 灰度发布让"昨天还好用"成为最坏的证据
三月十三日下午这个时间点特别值得说。很多团队做发布和灰度，习惯安排在自家工作时间的下午，因为出问题还有人能立刻回滚。一次后端改动，把地域判定从"读请求头"整体挪到"读 IP + Cookie 优先"，对绝大多数用户是无感的，不会有任何公告，前端代码一行没变。但对你这种靠改头来改变行为的少数用户来说，体验就是"突然全废"。
这时候最误导人的恰恰是你自己的经验。"昨天还好用"会让你把所有注意力放在客户端——重装扩展、换规则、换浏览器，而真正变化的地方在服务端，你连看都没看一眼。我后来给自己定了个规矩：先证明服务端行为变了，再回头怀疑客户端。顺序反了，半天就白扔了。
3. 那次失效的完整排查链路
下面这段是我那半天真实走过的路径，按顺序列出来，包括每步的结论。之所以完整写出来而不是只给答案，是因为排查思路本身比结论更可复用——下次换个产品、换个场景，你照着走一遍就行。
3.1 我按顺序做的九件事
- 无痕窗口 + 禁用全部扩展。结果：无痕下依然跳。结论：不是扩展冲突，也不是缓存污染，问题在服务端或者网络侧。
- 命令行
curl -I直接看响应头。结果：返回 302，Location指向区域站。结论：确实是 HTTP 层重定向，不是前端 JS 干的。 - 在 curl 里手动加
Accept-Language和自定义 UA。结果：行为不变，还是 302。结论：语言头和 UA 至少不是这一层的主要判定依据。 - 检查响应里的
Set-Cookie。结果：第一次落地时下发了一个带地区标识的 Cookie。结论：存在粘性，后面所有请求都可能被这个 Cookie 带着走。 - 清掉这个 Cookie 再请求一次。结果：依然 302 到区域站，但下发的 Cookie 值变了。结论：Cookie 不是根因，是被动写入的结果。
- 换一条路径，比如访问一个具体的子页面而不是根路径。结果：子页面正常返回 200。结论：重定向规则是路径级的，挂在根路径或特定的入口路径上。
- 抓一遍完整请求，看有没有客户端提示头。结果：有
Sec-CH-UA系列，但没有Sec-CH-UA-Platform-Version之类更细的。结论：服务端确实采集了客户端信息，但采集范围有限。 - 换一个网络环境做对照（比如切到手机热点）。结果：行为一致。结论：不是某一条出口线路的特殊处理，是普适策略。
- 对比响应头里有没有边缘层注入的地理信息字段。结果：找到一个没被我发送过、但出现在响应里的字段。结论：判定发生在我够不着的地方，实锤。
走完这九步，答案已经很清楚了：判定逻辑在边缘层和应用层之间，主要依据是连接来源，请求头只是辅助信号。这条路上没有任何"改头"的操作空间。
3.2 现象与成因对照表
排查过程中我记了一堆现象，事后整理成表，方便以后快速对照：
| 现象 | 更可能的成因 | 下一步验证 |
|---|---|---|
| 命令行正常、浏览器异常 | 本地缓存、Cookie 或扩展 | 无痕窗口对照 |
| 命令行和浏览器都异常 | 服务端策略变更 | 抓响应头看 302 与Location |
| 改了头但响应完全没变化 | 该头不参与判定 | 检查响应里有没有Vary |
| 改头偶尔生效偶尔不生效 | 边缘缓存命中不同版本 | 加随机查询参数重试 |
| 清 Cookie 后行为短暂改变 | 粘性 Cookie 被动重写 | 逐条二分删 Cookie |
| 只有某个路径异常 | 路径级重定向规则 | 换路径做对照 |
3.3 三个反直觉的发现
发现一：改 UA 的"效果"其实是错觉。我一度以为改 UA 起了作用，因为改完之后偶尔能落到国际站。后来加了随机参数反复测了二十次，命中率大概三成——这不是生效，这是命中了不同的边缘缓存版本。判断一个改动是否真的生效，一定要重复足够多次，别用单次结果下结论。
发现二：请求头里有Accept-Language，但服务端可能只拿它排序。有些产品会用语言头决定"页面用哪种语言渲染"，但用 IP 决定"去哪个站点"，两件事是分开的。你改了语言头，页面语言变了，域名没变，于是你以为"改头有用但不够"，实际上是两个完全独立的判定链路。
发现三：状态码 302 和 307 的区别在这类场景里会咬人。302 在历史上被浏览器实现成"可以改方法"，307 则严格保持原方法。如果你在调试一个 POST 请求的重定向，看到 302 之后方法变成了 GET、请求体丢了，别怀疑是自己的代码问题，那是规范历史包袱。这类细节在排查跳转链路时经常被忽略。
4. 换一条路：把"改头"升级成"可控的测试上下文"
查清楚之后我做了一个决定：不再在日常工作里依赖任何"改请求头"的扩展。不是因为它不好用，而是因为它不可控、不可复现、不可进流水线。取而代之的是一套能写进代码、能跑在 CI 里的测试上下文。这套东西本来是给我自己产品的多语言页面做回归用的，但用它来观察第三方站点的行为差异同样好使。
4.1 用测试框架的上下文参数替代扩展
以目前用得比较多的一个端到端测试框架为例，它支持在创建浏览器上下文时直接指定语言、时区、额外的请求头，而且每个上下文之间是完全隔离的：
const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const ctx = await browser.newContext({ locale: 'en-US', timezoneId: 'America/Los_Angeles', extraHTTPHeaders: { 'Accept-Language': 'en-US,en;q=0.9', }, }); const page = await ctx.newPage(); const resp = await page.goto('https://example.com/', { waitUntil: 'domcontentloaded', }); console.log('status:', resp.status()); console.log('final url:', page.url()); console.log('server headers:', JSON.stringify(resp.headers(), null, 2)); await browser.close(); })();这段代码比扩展强在四个地方：语言和时区是浏览器层面真实生效的，不只是加一个头；每次运行都是干净上下文，没有历史 Cookie 污染；能直接拿到状态码、最终 URL 和完整响应头；可以写断言、可以进 CI、可以跑一百次统计命中率。可复现这三个字，是它和"手动改头"之间最本质的差别。
4.2 把"我在哪"的接口拦下来做分支验证
如果你的目的是验证自己产品在不同地区下的前端分支逻辑，最干净的做法是把地理判定接口 mock 掉，而不是去伪造网络环境：
await page.route('**/api/geo**', async (route) => { await route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify({ country: 'SG', region: 'ap-southeast' }), }); }); await page.goto('https://your-app.example.com/'); await expect(page).toHaveURL(/\/sg\//);这样做的好处是判定的输入完全受你控制，输出可以被断言，而且不依赖任何外部条件。产品的地域路由逻辑改一次，你改一下 mock 的返回值就能覆盖新分支，比在浏览器里跟扩展规则较劲高效得多。
4.3 一份能直接抄的目录结构
我把这套东西整理成了一个小仓库，结构大概是这样：
geo-i18n-check/ ├── cases/ │ ├── locale-en.json │ ├── locale-ja.json │ └── locale-zh.json ├── fixtures/ │ └── geo-responses.json ├── specs/ │ ├── redirect.spec.js │ └── locale-render.spec.js └── report/ └── summary.json每个 case 文件里只放三样东西：语言、时区、期望落地的路径前缀。跑完之后生成一份汇总，哪几个组合通过了、哪几个失败了，一目了然。这套结构的价值在于，它把"我印象中昨天是这样的"变成了"这份报告里第 7 条断言失败了"。
4.4 为什么我劝你彻底放弃"用客户端改头对抗服务端策略"
这里说句实在话。服务方按区域做路由、做内容分发，是它自己的产品策略和合规安排。客户端靠改请求头去绕，一来技术上不成立——你已经看到了，判定根本不在你够得着的那一层；二来这件事本身也不合适，你今天绕过去了，明天它换个判定维度，你又得重来一遍，永远在追。
真正值得投入的方向有两个：一是在自己的可控环境里做多地区、多语言的验证，用上面那套上下文和 mock 的方式；二是用产品本身提供的语言、市场设置。前者是工程能力，后者是正常使用方式，两者都不会因为某次灰度发布而一夜作废。
5. 只想正常用产品的话，先动这几处设置
不是所有人都要做工程验证。如果你只是想让那个入口按你期望的语言和站点打开，那顺序应该是从"产品给的正规开关"开始，而不是从"装个扩展改头"开始。
5.1 产品自带的语言与市场设置优先级最高
绝大多数国际化产品，在设置页里都有语言、地区、内容市场的选项。这些设置一般会写进账号或者长效 Cookie，优先级高于任何请求头。先去把这几项调对，再看行为有没有变化。我见过太多人一上来就装扩展，结果产品设置里那一项从来没动过——方向反了。
顺带说一个观察：账号级设置和匿名态设置的行为经常不一样。登录之后按账号走，退出登录之后按 Cookie 或者连接来源走。所以你在两种状态下测出来的结论可能互相矛盾，这不是 bug，是两套链路。
5.2 清理顺序很关键，别一上来就清全部
清数据这件事，顺序错了等于白清。我一般的顺序是：
- 先只删该站点的那条地区 Cookie，看行为变不变；
- 再清该站点的全部 Cookie 和站点数据；
- 然后清缓存的响应，特别是 3xx 重定向缓存；
- 最后才考虑清全部浏览数据。
为什么这么排？因为你需要知道"是哪一项在起作用"。一上来就全清，问题暂时消失了，但你不知道原因，下次遇到还是抓瞎。而且全清的代价很大，一堆登录态全丢，得不偿失。
提示：清完数据之后，第一次请求往往会重新触发一次"判定 + 写入 Cookie"，这时候看到的行为才是最接近"新用户"的。想看真实的首访行为，务必在这个状态下观察。
5.3 判断"这是策略不是 bug"的三个信号
到某个点你就该停手了，别在没意义的地方耗时间。我的判断标准是三条：一是命令行和浏览器行为一致，说明不是本地环境问题；二是响应头里出现了你没发过的、带地理含义的字段，说明判定在边缘层；三是换网络、换设备、换浏览器，结论都一样。三条里中了两条，基本可以确定这是产品策略，不是你哪里配错了，收手去做别的事更划算。
最后分享一个个人的习惯。现在每次我想装个扩展去改某个站点的行为之前，我会先问自己一句：**如果这个改动明天失效了，我今天做的事是不是全白费？**如果答案是"是"，那我就先去把观测手段搭好——抓包、对照实验、可复现的脚本。观测能力不会失效，扩展会。这半天折腾下来，我唯一不后悔的，就是把那九步排查链路完整记了下来，后面遇到同类问题，直接照着走一遍，半小时出结论。
