Nginx处理URL特殊字符的关键是透传原始编码而非强制解码：应使用正则捕获$1原样转发，禁用merge_slashes，避免proxy_pass隐式解码，并协同前后端统一UTF-8编码解析。
Nginx 默认会对 URL 中的特殊字符（如空格、中文、`/`、`?`、`#`、`+`、`%` 等）进行严格校验，未正确编码的请求容易触发 400 Bad Request 错误。关键不是“禁止特殊字符”，而是让 Nginx 正确识别、透传或解码它们——这依赖于路径匹配方式、代理行为和字符集协同配置。
用正则捕获代替硬拼接，避免 URL 解码失败
直接在 proxy_pass 中拼接未处理的路径（如 proxy_pass http://backend/$request_uri;）极易出错，因为 Nginx 会在内部对 `$request_uri` 做一次解码，再转发时可能重复解码或乱码。
- 推荐写法：用
location+ 正则提取路径片段，原样透传 -
location ^~ /api/ { proxy_pass http://127.0.0.1:3000/; }—— 这种写法会自动剥离前缀并完整转发剩余路径（含已编码字符） - 若需更灵活控制，用
if+$request_uri正则匹配，只取目标部分 - 例如：
if ($request_uri ~ ^/v1/(.*)$) { proxy_pass http://backend/$1; }，确保 `$1` 是原始编码后的字符串
确保后端能接收并理解编码格式
Nginx 本身不负责“解码业务参数”，它只负责按规则转发。真正决定字符是否可用的，是后端服务对 URL 编码的解析能力。
- 前端发送请求前，必须对路径参数做标准 percent-encoding（如中文转为
%E4%B8%AD%E6%96%87） - 后端框架（如 Spring Boot、Express、Flask）需配置支持 UTF-8 解码 query/path 参数
- 避免在 Nginx 层做
rewrite解码操作，除非明确需要——多数场景应保持编码透传
全局与局部 charset 配置要一致
虽然 charset 主要影响响应头和静态内容输出，但它也间接影响浏览器对响应中 URL 的解析逻辑。
- 在
http块设charset utf-8;，让所有响应默认声明 UTF-8 - 若后端返回非 UTF-8 内容（如 GBK），应在对应
server或location中覆盖：charset gbk; - 注意：
charset不改变 Nginx 对请求 URI 的解析行为，但缺失会导致浏览器误判响应内容编码，进而影响 JS 中decodeURIComponent()的结果
禁用自动 decode 的场景需特别处理
某些 API 设计要求路径中保留原始编码（如签名路径含 %2F 表示斜杠），而 Nginx 默认会将 %2F 视为 `/` 并用于 location 匹配——这可能导致路由错误。
- 启用
merge_slashes off;可禁用路径标准化，保留原始斜杠编码 - 使用
location /raw/ { proxy_pass http://backend/; }配合客户端发送双编码（如%252F）实现绕过 - 更稳妥的方式：改用请求头或 body 传递敏感路径片段，避开 URI 编码争议
