核心是确保字符编码在后端、nginx、浏览器间全程统一为utf-8且可验证：后端须显式声明charset并输出匹配字节流，nginx禁用压缩、透传原始content-type头，缓存键需纳入charset维度以隔离不同编码响应。
核心是让字符编码在整条链路上保持一致且可验证：后端输出、Nginx 缓存/转发行为、浏览器解析三者必须对齐 UTF-8（或其他统一编码），不能依赖 Nginx 自动识别或转换。
统一后端响应的 Content-Type 与实际字节流
乱码根源常在后端——它返回了 UTF-8 字节，却没声明 charset=utf-8；或声明了 UTF-8，实际输出却是 GBK 字节。
- 强制后端在所有文本类响应头中显式带 charset：
Content-Type: text/html; charset=utf-8、application/json; charset=utf-8、application/xml; charset=utf-8 - Java（Spring Boot）需确认：
server.servlet.encoding.charset=UTF-8且spring.http.encoding.force=true - PHP 需启用
default_charset = "UTF-8"，避免 header() 前已输出 BOM 或隐式编码 - 用
curl -I http://backend/xxx检查响应头是否含正确 charset，再用curl -s http://backend/xxx | hexdump -C | head确认前几个中文字符是否为合法 UTF-8 字节序列（如“测试”应为e6 b5 8b e8 af 95）
禁用后端压缩，避免编码与压缩耦合失真
后端若对 GBK 响应启用 Gzip，Nginx 缓存的是压缩后的二进制流；浏览器解压后按 UTF-8 解析，必然乱码。这不是 Nginx 的错，而是压缩掩盖了编码不匹配。
- 在对应
location中添加：proxy_set_header Accept-Encoding "";，明确禁止后端压缩 - 检查 access_log 中
$upstream_http_content_encoding变量，确保日志里不再出现gzip或deflate - 如必须保留压缩，请确保后端对所有压缩响应都严格配套正确的 charset，且 Nginx 不启用
sub_filter或正则替换（会破坏二进制完整性）
显式透传并保护原始响应头
Nginx 默认可能“净化”掉 Content-Type 中的 charset 参数，尤其在开启某些模块或使用旧版本时。
- 用
proxy_set_header Content-Type $upstream_http_content_type;显式透传原始头，防止丢失 charset - 不要使用
proxy_hide_header Content-Type，它会整个删掉该头 - 若后端未设 charset，Nginx 无法补全——此时修复点一定在后端，Nginx 只能做可靠透传
缓存键纳入编码维度（灰度/过渡期适用）
当无法立刻统一后端编码（例如新老接口并存 UTF-8 和 GBK），可将编码信息加入缓存键，避免不同编码响应互相覆盖。
- 用
map提取上游响应中的编码：map $upstream_http_content_type $cache_charset {<br> ~charset=utf-8 utf8;<br> ~charset=gbk gbk;<br> default other;<br>} - 构造带编码的缓存键：
proxy_cache_key "$scheme$request_method$host$request_uri$cache_charset"; - 加调试头：
add_header X-Content-Charset $cache_charset;，便于定位响应来源
