关键不是“保留转义”，而是让Nginx正确传递原始URI：默认先解码再匹配location，proxy_pass却用解码后URI转发，破坏后端预期；应禁用merge_slashes、启用proxy_pass_request_uri on，并确保proxy_pass不带URI尾缀，配合X-Forwarded-Uri透传原始$request_uri。
关键不是“保留转义”，而是让 Nginx 正确传递原始 URI，不二次编码、不解码错位、不破坏后端预期的字符格式。
理解 Nginx 的 URI 处理逻辑
Nginx 默认会对客户端发来的 URI 做两件事：先解码（如 %20 → 空格、%2B → +），再用解码后的字符串匹配 location；但 proxy_pass 转发时，默认使用解码后的 URI，这会导致后端收不到原始编码形式——尤其当后端依赖原始 % 编码（比如某些 REST API 或 Java Spring Boot 应用）时，就会出错。
要“完美保留”，本质是绕过默认解码行为，把原始请求 URI 字符串原样传给后端。
核心配置：禁用 merge_slashes + 启用 proxy_pass_request_uri
这两项配合才能稳定生效：
-
merge_slashes off; —— 防止 Nginx 自动合并多个斜杠（如
//api//v1被改成/api/v1），避免破坏含编码路径的结构 -
proxy_pass_request_uri on; —— 让 proxy_pass 使用原始未解码的
$request_uri（含 %xx、+、空格等），而不是解码后的$uri
注意：proxy_pass_request_uri 必须在 location 块内启用，且 proxy_pass 指令不能带 URI 尾缀（例如不能写 proxy_pass http://backend/;，否则会触发重写逻辑，丢弃原始路径）。
配套 header 设置与编码兼容性
仅传 URI 还不够，还需确保后端能识别原始编码语义：
- proxy_set_header Host $host; —— 保持原始 Host，避免后端因 Host 不一致拒绝请求
- proxy_set_header X-Forwarded-Uri $request_uri; —— 显式透传原始 URI（供后端调试或路由判断）
- proxy_set_header X-Forwarded-For $remote_addr; —— 保留真实客户端 IP
- 若后端是 Java 或 .NET，确认其容器（如 Tomcat、Kestrel）未开启自动 URL 解码双遍历（double-decoding），否则可能把
%2520（即 %20 的二次编码）错解为
特殊字符常见陷阱与验证方法
以下情况容易出问题，建议逐项检查：
- 请求含
+：浏览器发a+b时，+在 query string 中常被当作空格处理；如需字面量+，应编码为%2B，并确保后端按 %2B 解析 - 路径含中文或括号：如
/file/张三(测试).pdf，需前端用encodeURIComponent编码成/file/%E5%BC%A0%E4%B8%89%28%E6%B5%8B%E8%AF%95%29.pdf，Nginx 用$request_uri直传即可 - 空格：必须编码为
%20，不能直接传空格（HTTP 协议不允许 URI 中出现裸空格） - 验证方式：在后端打印接收到的完整 request URL 或 raw path，对比是否与 curl -v 发送的一致（例如
curl -v "http://proxy/test%20file%2Bname"）
不复杂但容易忽略
