nginx反向代理请求头乱码主因是utf-8编码链断裂，需统一客户端、nginx、后端三者编码：确保请求头原始字节为utf-8、禁用干扰解码模块、显式透传charset意图、统一响应字符集输出。
解决 Nginx 反向代理中因默认字符集不匹配导致请求头乱码，核心不是“Nginx 不支持中文”，而是请求头、Nginx 内部处理、后端响应三者间 UTF-8 编码链断裂。重点在统一视角、避免隐式转码、显式传递编码意图。
确保请求头本身是 UTF-8 编码的原始字节
浏览器发送含中文的请求头（如 Referer: https://example.com/测试页面）时，会自动按 UTF-8 编码为百分号格式（%E6%B5%8B%E8%AF%95%E9%A1%B5%E9%9D%A2）。但某些客户端（如旧版 curl、自定义脚本）可能用 GBK 或系统本地编码发送，Nginx 解码后字节就错乱。
验证方法：用 curl -v "http://your-proxy/%E6%B5%8B%E8%AF%95.html" 测试，而非直接传中文字符串；检查 Nginx access log 中的 $request 或 $http_referer 是否已乱码——若已乱，问题出在客户端或中间网关，不在 Nginx 配置。
禁用干扰解码的模块与指令
Nginx 默认对 URI 做一次标准 URL 解码，但某些配置会二次干预：
- 停用
ngx_http_sub_module（尤其开启sub_filter且未指定sub_filter_types时），它可能对已解码的 URI 再次做字符串替换，把 UTF-8 字节当 Latin-1 处理，引发乱码； - 避免在 location 中使用
rewrite对含中文路径做正则捕获后未加utf8标志（如rewrite ^/([^/]+)$ /index.php?path=$1 break;），Nginx 8.0+ 支持utf8修饰符，旧版本需确保 PCRE 库编译时启用 UTF-8 支持； - 不要用
proxy_set_header Referer $http_referer;直接透传——若上游已乱码，透传只会放大问题；必要时先用 Lua 或 map 模块清洗。
显式声明并透传编码意图给后端
Nginx 不会自动修改请求头内容的编码，但它可以控制是否将编码信息告知后端：
- 在 proxy location 中添加：
proxy_set_header Accept-Charset "utf-8";，提示后端“客户端期望 UTF-8”； - 若后端依赖
Content-Type中的 charset 判断，可强制设置：proxy_set_header Content-Type "application/x-www-form-urlencoded; charset=utf-8";（仅适用于表单提交等场景）； - 关键一点：确保
proxy_pass后端服务本身接受并正确解析 UTF-8 请求头——例如 Tomcat 需配置URIEncoding="UTF-8"在 connector 中，否则即使 Nginx 传了 UTF-8 字节，Tomcat 仍按 ISO-8859-1 解析。
统一响应侧的字符集输出（防连锁乱码）
请求头乱码常伴随响应乱码出现，补全闭环：
- 在 server 或 location 块中写：
charset utf-8;，让 Nginx 对 text 类型响应自动注入charset=utf-8； - 配合
charset_types显式列出类型：charset_types text/html text/plain text/css application/javascript application/json;； - 对反代响应，用
add_header Content-Type "text/html; charset=utf-8";覆盖后端可能错误的 header（注意：不能和charset指令混用同一 location，否则可能冲突）； - 前端页面必须带
<meta charset="utf-8">，且文件本身保存为 UTF-8 无 BOM 格式。
