Nginx反向代理含特殊字符路径时需禁用自动URI解码、用正则location匹配、配置proxy_redirect正则重写并透传X-Original-URI给后端协同处理。
当 Nginx 反向代理的路径中包含特殊字符（如 +、%、空格、{、}、[、] 等），浏览器会自动编码（如空格→%20，+→%2B），而后端服务若未正确解码或 Nginx 未保留原始编码格式，就容易导致 302 跳转失败、Location 头乱码、404 或跳转到错误路径。
确保 URI 原始编码不被 Nginx 自动解码
Nginx 默认会对请求 URI 进行一次解码（如将 %2F → /），这在含特殊字符的路径代理中常引发问题。需显式关闭自动解码：
- 在对应
location块中添加：proxy_pass_request_headers on;（默认已启用，但需确认） - 关键配置：rewrite ^(.*)$ $1 break; + proxy_pass http://backend; 组合可绕过部分 URI 处理逻辑
- 更稳妥方式：使用 unencoded 参数（Nginx 1.19.7+）：
proxy_pass http://backend/uri/ some_path?arg=val; 不适用；应改用：
location ~ ^/api/v1/[a-zA-Z0-9%+._~-]+/detail$ {
proxy_pass http://backend;
proxy_redirect off;
}
处理后端返回的含编码 Location 头
后端可能返回类似 Location: /search?q=hello%2Bworld 的跳转地址，若 Nginx 的 proxy_redirect 规则写成 proxy_redirect /search /api/search，会因未匹配编码字符而失效。
- 启用正则匹配重写：proxy_redirect ~^(/search\?q=[^ ]+)$ /api$1;
- 通用解法（推荐）：proxy_redirect ~^(https?://[^/]+)?(/.*)$ $scheme://$host/api$2; —— 保留全部编码内容，仅补上前缀
- 禁用自动重写并由后端控制：proxy_redirect off;，同时确保后端读取
X-Forwarded-Prefix并生成正确跳转地址
避免 location 匹配阶段误判特殊字符
Nginx 的 location 指令在匹配时对 URI 是“解码后匹配”的（RFC 3986），即 /user%2Btest 和 /user+test 都会被视为 /user+test 来比对。但正则 location（~ 或 ~*）支持原始字节匹配。
- 用正则 location 显式捕获编码段：location ~ ^/v2/[a-zA-Z0-9%+._~-]+/action$ { ... }
- 避免使用
=精确匹配含特殊字符的路径，因其要求完全一致且不解码，易失配 - 测试技巧：用
curl -v "http://x/x%2Bx"查看 Nginx access_log 中的$request_uri，确认实际收到的是编码形式还是已解码形式
后端协同：传递原始请求信息
仅靠 Nginx 难以 100% 还原原始编码意图，需后端配合解析原始 URI：
- 透传原始请求路径：proxy_set_header X-Original-URI $request_uri;
- 确保协议与前缀正确：proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Prefix /api; - Spring Boot 示例：启用
server.forward-headers-strategy=framework并读取X-Original-URI构造跳转地址，而非依赖HttpServletRequest.getRequestURL()
