nginx本身不解析请求头，中文乱码主因是客户端非utf-8编码发送+后端错误解码；解决关键为字节原样透传（禁用underscores_in_headers、避免变量拼接）+后端显式utf-8解码原始字节，并确保docker/wsl环境locale设为utf-8。
核心问题不在“Nginx 不支持中文字符集”，而在于请求头（尤其是 Cookie、User-Agent、自定义头如 X-Forwarded-For 或业务头）中含中文时，后端服务收到的原始字节被错误解码。Nginx 本身不解析请求头内容，它只是透传；乱码通常发生在：① 客户端用非 UTF-8 编码（如 GBK）构造请求头；② 后端未按原始字节处理，而是强制用 Latin-1 或系统默认编码解码；③ 负载均衡配置中启用了不安全的 header 处理（如 proxy_set_header 错误拼接或截断）。解决重点是保证“字节原样透传 + 后端正确解码”。
确保请求头字节不被 Nginx 意外修改
Nginx 默认不会重写或解码请求头值，但以下配置可能引发隐式破坏：
- 避免在
proxy_set_header中拼接含中文的变量（如proxy_set_header X-Trace "$host $remote_addr";），若$host或$remote_addr在特殊环境下含非 ASCII 字符（极少见），应改用安全变量或过滤 - 禁用
underscores_in_headers on;—— 开启后 Nginx 会丢弃下划线字段，某些中文业务头名若含下划线（如X-用户-ID）会被静默忽略，看似“消失”实为丢弃 - 检查是否启用
ngx_http_sub_module或第三方模块（如某些 WAF 模块），它们可能对请求体或 header 做正则替换，误伤中文字符
强制后端接收原始字节并指定 UTF-8 解码
请求头中的中文（如 Cookie: username=张三）实际由客户端以 UTF-8 编码为字节后发送（如 username=%E5%BC%A0%E4%B8%89 是标准 URL 编码；纯中文未编码属非法 HTTP 行为，但部分浏览器或测试工具会发）。关键动作是：
- 后端应用必须从原始请求头二进制流读取，而非依赖框架自动解码（例如 Java 的
request.getHeader("Cookie")可能已按平台默认编码转成 String，丢失原始字节） - 推荐做法：在 Nginx 的
location块中添加proxy_pass_request_headers on;（默认即开启），并确保后端使用getRawHeader()类接口获取未解码字节，再显式用 UTF-8 解码 - 若无法改后端，可在 Nginx 层做兼容性转义：用
map指令将含中文的 header 值转为 URL 编码后再透传（需配合 Lua 或 echo 模块，生产环境慎用）
验证与调试真实请求头编码
不要依赖浏览器地址栏直接输入中文路径来测试 header —— 浏览器不会在 header 中发裸中文。可靠方法是：
- 用
curl -v -H "X-Test: 测试" http://upstream/发送，观察 Nginx access_log 中$http_x_test记录的原始值（需在 log_format 中启用），确认是否为 UTF-8 字节序列（如E6%B5%8B%E8%AF%95） - 在后端打印接收到的 header 字节十六进制（如 Python：
bytes(header_value, 'latin-1').hex()），比对是否与 curl 发送一致 - 若发现字节被篡改（如
0xE5 0xBC 0xA0变成0xC0 0xAF），说明中间有 GBK/Latin-1 强制转码，需排查 Nginx 模块或系统 locale 设置
补充：Docker 或 WSL 环境下的系统级影响
当 Nginx 运行在 Docker 或 WSL 中，若基础镜像 locale 未设为 UTF-8（如 LANG=C），某些 C 库函数（如 strtok 处理 header 分割）可能误判多字节边界，导致截断。解决方案：
- Dockerfile 中明确设置：
RUN locale-gen zh_CN.UTF-8 && update-locale LANG=zh_CN.UTF-8，并在启动命令前加export LANG=zh_CN.UTF-8 - WSL 中执行
sudo locale-gen en_US.UTF-8 zh_CN.UTF-8，然后修改/etc/default/locale为LANG="zh_CN.UTF-8" - 验证：进入容器或 WSL 执行
locale，输出中LC_CTYPE和LANG必须含UTF-8
