后端感知客户端语言环境的关键是确保accept-language请求头完整透传至后端。nginx默认原样转发该头，不应显式配置proxy_set_header覆盖；若需兜底，应配合map指令条件设置；推荐由后端（如spring boot或node.js库）完成语言解析，nginx仅作透明代理。
后端要感知客户端语言环境，关键不是靠 Nginx 主动“设置”某个语言头，而是确保原始 Accept-Language 请求头完整、无损地透传到后端。Nginx 默认会转发客户端带过来的 Accept-Language，但若中间有重写、覆盖或配置了不恰当的 proxy_set_header 指令，就可能丢失或污染该头。
必须保留原始 Accept-Language 头
Nginx 不会自动修改或删除 Accept-Language，只要你不显式用 proxy_set_header 覆盖它，它就会原样转发。所以最稳妥的做法是：不配置与 Accept-Language 相关的 proxy_set_header 指令，让其自然透传。
- 不要写 proxy_set_header Accept-Language "zh-CN,zh;q=0.9" 这类固定值——这会强制所有请求都变成同一语言，失去用户个性化
- 也不要写 proxy_set_header Accept-Language $http_accept_language ——虽然变量正确，但纯属冗余，且若客户端未发送该头，$http_accept_language 为空，反而可能触发后端空值异常
- 默认行为即最优：客户端发什么，后端就收什么
需要额外处理的边界情况
某些前端网关（如 CDN、WAF）或客户端（老旧浏览器、命令行工具）可能不带 Accept-Language，或只带简陋值（如 en）。这时可考虑在 Nginx 层做轻量级兜底，但需谨慎：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 仅当确认本层 Nginx 是最外层入口，且业务强依赖语言信息时，才用 proxy_set_header Accept-Language $http_accept_language 配合条件判断（需配合 map 指令）
- 例如：用 map 定义默认语言，再基于 $http_accept_language 是否为空来选择值，避免覆盖有效头
- 更推荐把语言协商逻辑交给后端（如 Spring Boot 的 LocaleResolver 或 Node.js 的 accept-language 库），Nginx 保持透明
配合其他头确保上下文一致
语言感知常和区域、编码、协议等联动。为避免后端因上下文缺失而误判，建议同步透传以下基础头：
- Host：用 proxy_set_header Host $http_host，保证后端生成本地化链接时域名+端口准确
- X-Forwarded-Proto：用 proxy_set_header X-Forwarded-Proto $scheme，防止 HTTPS 下语言跳转仍走 HTTP
- Cookie：默认透传，若后端用 Cookie 存储用户语言偏好（如 locale=zh_CN），确保不被 Nginx 缓存或过滤
语言环境识别本质是端到端链路的完整性问题。Nginx 的角色只是忠实信使，不该擅自翻译或替用户做决定。把 Accept-Language 留给客户端声明，把解析权留给后端，是最简单也最可靠的方式。
