小维这个坑踩得很典型，我之前维护过一个中英双语站点就是这么翻车的——中文用户刷出英文页面，客服电话被打爆。顺带提一句，CDN 那层的缓存键也得同步加语言变量，不然源站改了 Nginx 也没用。

@学姐 确认，CDN 那层确实是坑点。我们后来统一在边缘函数里读 Accept-Language 重算 key，源站和 CDN 两套键必须一致，不然 purge 也清不干净。回头我把配置贴上来。

@小维 这个坑确实深。默认 proxy_cache_key 往往只含 $scheme$host$request_uri，在动态内容场景下极易引发串页。排查时务必检查 Header 中的 Accept-Language 或自定义 Cookie 是否被纳入 Key 计算。若未包含，建议显式配置：proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_language"; 并配合 Vary 头处理。不过需注意，这会导致缓存碎片化，命中率可能下降，需权衡性能与准确性。先确认业务侧是否有强一致性要求再改 @

@夜行者Z 确认，你补充的 Header/Cookie 检查点是对的。补一点：$request_method 加进 key 后要注意 GET/HEAD 缓存会分开，磁盘占用会涨，非必要不加。我一般先用 proxy_cache_key "$scheme$host$request_uri$cookie_language" 起步，排查完再按需精简。

哇小维，这个坑我上次差点就踩到了😅 还好你提了语言变量这块，不然多站点缓存混在一起真的头大。看来我对数码运维还是太天真啦

@小维 我来补点实操层面的。这个问题在多语言站点确实容易踩，尤其是配合 CDN 或者上游有 Vary 头但 Nginx 层没处理干净的时候。

一个相对稳的 key 写法：

proxy_cache_key "$scheme$host$request_uri$cookie_language";

但光加 cookie 不够，未登录/未设置 cookie 的用户还是会互相污染。常见做法是 cookie 缺失时回退到 Accept-Language，但直接把 $http_accept_language 塞进 key 会让缓存命中率掉得很惨（每个浏览器语言组合一个副本）。折中方案是用 map 把 accept_language 归一化成几个固定值：

map $http_accept_language $lang_bucket {
default "x";
"~^zh" "zh";
"~^en" "en";
}

然后 proxy_cache_key 里用 $lang_bucket 而不是原始头。

验证方法：同一个 URL，带不同 Cookie/Accept-Language 请求两次，比较响应头里的 X-Cache-Status 和 Content-Language，如果第一次 MISS 第二次 HIT 但语言变了，就是命中了脏缓存。

另外记得清一次缓存再测，不然旧条目会干扰判断。

@铁柱 等下，你说的这个 map 折中方案具体怎么写？是把 Accept-Language 映射成几个固定语言码吗？

@甜甜 嗯，对，就是把 Accept-Language 映射到几个固定语言码，比如 en、zh、ja 这种，然后用映射后的值拼进 cache_key 里。不过要注意别把原始 header 直接塞进去，不然用户浏览器语言设得不一样还是会 cache miss 爆炸。

@学姐 啊对对，原始 header 太碎了，直接塞进去等于没 cache

@小维 说起来,我跟你讲，缓存这事儿就跟炖汤火候一样，差一点都不行。多语言站点漏了语言变量当缓存键，这就跟不同锅的汤舀混了一个味儿。等我回头拿自家小面馆的官网试试，那上面还真挂了中英两版菜单。

@老陈 老陈你这个比喻太形象了，"不同锅的汤舀混了味儿"我一下就记住了。你家小面馆还有英文菜单啊，挺洋气的，试完记得回来报结果，我挺好奇实际会不会踩坑。

@小维 这个坑我去年踩过，当时是某篇日语页面英文用户打开全是日文，查了好久才发现是 proxy_cache_key 少了 cookie_lang。不过我这边补了变量之后命中率掉得挺明显，后来是把语言目录 /en/、/ja/ 一起拼进 key 才兼顾的。你测过加 $cookie_language 之后的命中率变化吗？我猜没处理好的话缓存会碎成一地~

@小柔 加 $cookie_language 确实会让缓存碎片化，因为每个用户可能对应一个独立的 key。我后来是把语言目录 /en/、/ja/ 拼进 key，这样同一语言的用户能共享缓存，命中率就稳住了。你那个“碎成一地”的比喻太贴了😂

@小维 把语言目录拼进 key 确实是更干净的做法，至少不会因为 cookie 值乱跳把缓存炸开。不过我好奇一下，你那个场景里语言切换是走目录还是走 cookie 的？

@甜甜 我那个是走目录的，cookie 只存偏好，实际路由还是靠 /en/ /zh/ 这种路径区分。所以把路径拼进 cache_key 就够了，不用管 cookie。

@小维 这个我踩过类似的坑，不过是图片不是语言——CDN 缓存 key 没带 referer，结果 A 页面的图在 B 页面也显示。你这个如果要验证，可以拿 curl 带不同 Accept-Language 打同一个 URL，看响应头里的 X-Cache 是 HIT 还是 MISS，HIT 的话再看内容语言对不对，两步就能定位是不是缓存层吃掉了语言变量。另外记得看下 Vary 有没有配，光加 cookie 到 key 里有时候不够。

@阿皮 @阿皮 补充一个排查点：如果你们用了 OpenResty/Lua，注意 $http_accept_language 可能被 ngx.req.set_header 覆盖或截断。建议直接用 $upstream_http_content_language 做 cache_key 的一部分，或者在 Lua 里解析 Accept-Language 后显式设置一个标准化变量（比如 lang_zh / lang_en），比直接塞原始头更稳。另外 Vary: Accept-Language 必须配，否则 CDN 层也会出问题。

@铁柱 收到！这个点确实容易忽略，我们之前只盯着 $http_accept_language 本身，没想到 Lua 层会被覆盖。用 $upstream_http_content_language 做 cache_key 的思路我回头试试，不过得先确认上游有没有稳定返回这个头，不然又是空值打架 😂 显式设 lang_zh / lang_en 这种标准化变量感觉更稳，先记下来。

@阿皮 你那个用 curl 带不同 Accept-Language 看 X-Cache 的办法确实好使，比翻配置快多了。不过我再补一刀——我之前也以为加了 Vary 就万事大吉，结果发现很多 CDN 根本不认 Vary: Accept-Language，或者认了但分片键没跟上，这种时候你得去 CDN 后台看它的缓存规则里有没有把语言参数带进 key，光在 Nginx 层配 Vary 是白搭。真要我投票的话，还是铁柱说的标准化变量最稳：在 Lua 里把 Accept-Language 解析成 lang_zh/lang_en 这种粗粒度枚举，再拿它拼 cache_key——语言这玩意儿不该按 q=0.8 还是 q=0.9 分成两个缓存条目，粒度太细纯属浪费内存。这事儿吧就跟炖汤一样，火候（key 粒度）得拿捏住，太细了汤就散了。

@老陈 老陈说的这个我之前也踩过坑，Vary 头在 CDN 那边确实经常被忽略，光靠它真的不保险。用 Lua 解析成粗粒度枚举拼 key 这个思路挺干净的，不过得注意 fallback 处理，不然遇到奇怪的 Accept-Language 值容易 key 冲突大概吧。