根本原因是utf-8编码链断裂，需统一客户端、nginx、后端三者utf-8视角：确保请求头与路径为utf-8百分号编码、禁用干扰模块、显式透传content-type及charset、静态文件名须为utf-8存储。
HTTP/2 本身不改变字符编码逻辑，Nginx 在 HTTP/2 下代理多语言站点时出现编码错乱，根本原因仍是 UTF-8 编码链断裂——和 HTTP/1.1 完全一致。区别在于 HTTP/2 的头部压缩（HPACK）和二进制帧传输可能掩盖问题表象，让人误以为是协议层导致。实际仍需从请求、转发、响应三端统一 UTF-8 视角入手。
确保客户端发起的请求头与路径本身就是 UTF-8 编码字节
浏览器对含中文的 URL（如 /文章/测试.html）会自动做 UTF-8 百分号编码（%E6%96%87%E7%AB%A0/%E6%B5%8B%E8%AF%95.html），这是标准行为。但部分旧工具、脚本或 Windows 控制台环境可能用 GBK 发送，Nginx 解码后就变成乱码字节。
- 用
curl -v "https://your.site/%E6%B5%8B%E8%AF%95.html"测试，不要直接传中文字符串 - 检查 access log 中
$request_uri是否已乱码：若log_format main '$request_uri'显示\345\210\237\347\261\20d类似内容，说明原始字节就是 UTF-8；若显示??或异常符号，说明上游已错
禁用可能破坏 UTF-8 字节流的模块与指令
HTTP/2 下 Nginx 默认启用 HPACK 压缩头部，但某些配置会干扰编码完整性：
- 关闭
ngx_http_sub_module对响应体的替换（尤其未设sub_filter_types text/html;时），它可能把 UTF-8 多字节当单字节 Latin-1 处理 - 不在 location 中使用
rewrite对含中文路径做捕获，除非明确加utf8标志（Nginx ≥ 1.19.0） - 避免
proxy_set_header Referer $http_referer;直接透传——若$http_referer已被上游错误解码，透传只会放大问题
强制透传原始 Content-Type 与 charset，并关闭自动干预
HTTP/2 不支持修改响应头后再发，所以 Nginx 必须“原样透传”，不能删减或重写 charset 参数：
- 使用
proxy_set_header Content-Type $upstream_http_content_type;显式透传，防止旧版 Nginx 或某些模块剥离charset=utf-8 - 禁用
proxy_hide_header Content-Type和proxy_ignore_headers Content-Type - 若后端未设 charset，Nginx 无法补救——修复点一定在后端，例如 Spring Boot 加
server.servlet.encoding.force=true，PHP 设default_charset = "UTF-8"
为静态文件目录和 autoindex 显式声明 charset
当 Nginx 直接提供静态资源（如开启 autoindex on 展示中文文件名目录）：
- 在
server或location块中添加charset utf-8; - 补充
charset_types text/html text/plain text/css application/javascript;，确保各类文本响应都带Content-Type: ...; charset=utf-8 - 文件系统中的中文名必须是 UTF-8 编码存储（用
ls -b验证），否则 Nginx 匹配路径失败或返回 404
不复杂但容易忽略
