nginx中文路径乱码本质是uri在客户端、nginx、后端三环节utf-8编码未对齐；需确保浏览器自动编码为%e6%b5%8b等utf-8格式，nginx用proxy_pass http://backend/原样透传，后端按原始utf-8字节解析。
Linux 下 Nginx 使用 proxy_pass 时路径含中文出现乱码，本质是请求 URI 中的中文字节在 Nginx 解码、透传、后端接收三个环节未保持 UTF-8 一致性。不是简单加个 charset 就能解决，关键在链路对齐。
确认客户端请求确实是 UTF-8 百分号编码
浏览器地址栏输入 /测试接口 会自动转为 %E6%B5%8B%E8%AF%95%E6%8E%A5%E5%8F%A3，这是合法行为。但 curl 或 Postman 手动构造请求时容易出错：
- 用
curl -v "http://upstream/%E6%B5%8B%E8%AF%95"测试，不能直接写curl -v "http://upstream/测试" - 若后端日志中看到类似
%C2%BF%C2%BF或%A3%F6，说明客户端用了 GBK 编码，需修正源头 - Chrome 开发者工具 Network 标签页中检查 Request URL 字段，确认是标准 UTF-8 编码格式
确保 Nginx 不做错误解码或二次编码
Nginx 默认对 URI 进行一次 URL 解码（即把 %E6%B5%8B 变成字节 \xE6\xB5\x8B），但不会改变字节内容。问题常出在 proxy_pass 拼接逻辑中：
- 避免在
location中用rewrite+break后再proxy_pass，易触发隐式重编码 - 推荐写法：
proxy_pass http://backend/;（结尾带斜杠），让 Nginx 原样透传解码后的 URI 字节 - 禁用
underscores_in_headers on;，防止含中文的自定义 header（如X-用户-ID）因下划线被静默丢弃
后端必须按原始字节处理，不能依赖框架自动解码
Nginx 透传的是 UTF-8 字节流，但很多语言框架（如 Java Servlet、Spring、Python WSGI）默认用平台编码（如 Linux 的 UTF-8 或 Windows 的 GBK）解析 header 和 path，导致乱码：
- Java：不要用
request.getRequestURI()，改用request.getReader()或从原始 input stream 读取字节，再用new String(bytes, StandardCharsets.UTF_8) - Node.js：Express 默认已支持，但需确认
app.set('trust proxy', true)和req.originalUrl的使用场景 - PHP：
$_SERVER['REQUEST_URI']是原始字符串，但 FastCGI 环境下注意fastcgi_param REQUEST_URI $request_uri是否被覆盖
补充：文件系统与日志中的中文路径显示问题
如果 Nginx 日志里 $uri 显示乱码（如 “æµè¯.html”），不是功能故障，而是终端或日志查看器未用 UTF-8 解码：
- 用
less -r或cat查看日志，确保终端 locale 是zh_CN.UTF-8 - 调试时优先用
$request_uri（原始未解码字符串）代替$uri - Linux 系统级检查：
locale输出应含LANG=zh_CN.UTF-8；若无，执行sudo locale-gen zh_CN.UTF-8 && sudo update-locale LANG=zh_CN.UTF-8
