nginx默认解码uri但不丢失特殊编码，关键在proxy_pass末尾斜杠控制透传：带/则移除location前缀后转发剩余路径（如/file%20name.pdf），保留原始编码；不带/则拼接完整uri。
在 Nginx 负载均衡中，**原始请求 URI 中的特殊字符（如空格、中文、括号、%20、%E4%B8%AD 等）本身不会被 Nginx 主动修改或“丢失”**——关键在于：Nginx 默认会自动解码 URL 编码，而 proxy_pass 转发时的行为取决于 location 和 proxy_pass 末尾斜杠的搭配。所谓“保留转义字符”，实际是要确保：客户端发送的编码形式能被正确传递给后端，且不因 Nginx 的路径拼接或重写逻辑被二次解码、截断或误匹配。
确保 URI 原始编码完整透传给后端
Nginx 在收到请求后，会先对 URI 做一次标准 RFC 3986 解码（如 /file%20name.pdf → /file name.pdf），这是不可关闭的。但只要不额外干预，这个解码后的字符串会原样用于 proxy_pass 转发（不含 location 前缀时）或拼接（含前缀时）。要让后端收到与客户端发出一致的编码形式，需满足：
- 客户端必须发送合法编码的 URI（例如空格必须为
%20，不能发原始空格；否则 Nginx 直接返回 400 Bad Request） - 避免使用
rewrite或set $args等指令对 URI 做任何修改，否则可能触发二次编码/解码 - location 匹配用前缀方式（如
location /api/），而非正则匹配含未转义元字符的规则（如location ~ \.pdf$配合含[的文件名易出错）
proxy_pass 末尾斜杠决定是否保留原始路径结构
这是最常被忽略却影响 URI 透传的关键点：
-
location 以
/path/结尾，proxy_pass 也以/结尾：Nginx 移除 location 前缀后，将剩余路径直接拼到 proxy_pass 后 → 客户端请求/path/file%20name.txt，后端收到/file%20name.txt（编码保留） -
location 以
/path/结尾，proxy_pass 不带/：Nginx 把完整原始 URI（含/path/）拼到 upstream 地址后 → 后端收到/path/file%20name.txt（路径前缀多了一层） - 若需严格透传原始 URI（包括 query string 和编码），推荐统一用第一种写法，并在后端服务中处理解码逻辑
禁用自动解码？不现实，但可绕过干扰
Nginx 没有开关能关闭内置 URL 解码，强行“保留 %20”在服务端层面也不符合 HTTP 规范。真正要做的，是防止解码后引发的问题：
- 后端应用应基于解码后的路径工作（如 Python Flask 的
request.path已是 Unicode 字符串），而不是尝试重新解析原始字节 - 若后端必须接收原始编码字符串（如某些遗留系统），可在 Nginx 层用
$request_uri变量透传：proxy_set_header X-Original-Uri $request_uri;—— 此变量值未经解码，含原始%20、%E4%B8%AD等 - 确认后端服务器（如 Tomcat、Node.js）的 URI 编码配置与 Nginx 一致（均设为 UTF-8），避免解码错乱
验证与调试建议
用 curl 发送典型请求并检查后端日志或响应头：
curl -v "http://your-domain.com/static/测试%20文件.pdf"- 在后端打印接收到的完整 request URL 或 path 变量
- 检查 Nginx error log 是否有
invalid URI或client sent invalid request报错，这说明客户端发了非法字符（如未编码空格） - 开启 Nginx access log 的
$request_uri字段，对比日志中记录的 URI 与后端收到的是否一致
