Nginx不解析请求头，乱码主因是客户端非UTF-8编码发送、Nginx隐式破坏字节（如underscores_in_headers开启）、后端未按原始字节显式UTF-8解码；需关闭下划线头丢弃、禁用变量拼接header、后端用getRawHeader等获取原始字节再UTF-8解码。
Nginx 本身不解析请求头内容，所谓“转发请求头乱码”，本质不是 Nginx 解码错了，而是字节在传递链路中被错误解码或截断。关键在于：客户端发的是什么字节、Nginx 是否原样透传、后端是否按原始字节正确解码。
下面从三个实际可操作环节给出解决路径：
确保请求头字节不被 Nginx 隐式破坏
Nginx 默认透传 header，但某些配置会悄悄破坏原始字节：
- 关闭
underscores_in_headers on;（若开启，含下划线的中文头名如X-用户-ID会被静默丢弃） - 避免在
proxy_set_header中拼接变量（如proxy_set_header X-Trace "$host $http_x_trace"），尤其当$http_x_trace可能含非 ASCII 字符时；改用proxy_pass_request_headers on;（默认已开启）保持原样透传 - 检查是否启用了
ngx_http_sub_module或 WAF 类模块，它们可能对 header 做正则替换，误伤中文或特殊字符
后端必须显式按 UTF-8 解码原始字节
浏览器或客户端发送含中文的 header（如 Authorization: Bearer 用户令牌）时，通常会先做 UTF-8 编码再 URL encode（如 %E7%94%A8%E6%88%B7），但部分测试工具（如 Postman）可能直接发裸中文——这属于非标准 HTTP 行为，后端不能依赖框架自动解码：
- Java：不用
request.getHeader("Authorization")，改用getRawHeader()获取字节数组，再new String(bytes, StandardCharsets.UTF_8) - Python（Flask）：用
request.environ.get('HTTP_AUTHORIZATION')获取原始字符串，避免被 Werkzeug 自动 decode - Node.js（Express）：通过
req.rawHeaders或中间件拦截原始 HTTP 流，而非req.get()
验证真实请求头编码，别信浏览器地址栏
浏览器不会在 header 中发裸中文，所以不能靠地址栏输 /test?name=张三 来测 header：
- 用 curl 发真实带中文 header 的请求：
curl -v -H "X-Test: 测试" http://your-nginx/
- 在 Nginx access_log 中加
$http_x_test和$request_uri对比，确认日志里记录的是测试还是乱码字节 - 若日志中已乱码，说明上游（如负载均衡器或客户端 SDK）提前做了错误转码，需向前排查
不复杂但容易忽略
