Nginx rewrite中直接使用未编码特殊字符（如中文、空格）会导致匹配失败或400/404，因rewrite匹配的是已解码的$uri值；应避免在正则中硬写未编码字符，改用UTF-8配置、\s匹配空格、%%转义%符号，或优先采用return/try_files替代复杂重写。
在 Nginx 中，Rewrite 规则里若直接使用未编码的特殊字符（如空格、中文、`#`、`?`、`/`、`&` 等），常导致重写失败、跳转异常或 400/404 错误。根本原因是：Nginx 在解析请求 URI 时，已对原始请求做了一次解码；而 rewrite 指令匹配的是 解码后 的字符串，但如果你在正则中写了未编码的字符（比如直接写 `中文` 或空格），实际匹配会失败——因为浏览器发来的请求里，这些字符是 URL 编码过的（如 `中文` → `%E4%B8%AD%E6%96%87`，空格 → `%20`）。
确认请求 URI 实际被解码后的样子
Nginx 的 rewrite 是在 server 或 location 块中对 $uri 变量进行匹配，而 $uri 值是经过解码的（不含 query string）。所以排查第一步是看真实传入的 URI 是什么：
- 在对应 location 中加日志记录：log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$uri" "$args" "$request_uri";
- 用 curl 测试并观察 access log，例如：curl 'https://example.com/path/带空格的文件.pdf' → 日志中 "$uri" 字段显示的是 /path/带空格的文件.pdf（已解码），而非 /path/%E5%B8%A6%20%E7%A9%BA%E6%A0%BC...
- 注意：$request_uri 是原始未解码的完整请求行（含 query），而 $uri + $args 才等价于它解码后拆分的结果
避免在 rewrite 正则中硬写未编码字符
你不能在 rewrite 的匹配模式里直接写 `中文`、空格或 `#`，因为它们在正则中可能语法非法，且与 $uri 实际值不一致：
- ❌ 错误写法：rewrite ^/old/中文\.html$ /new.html permanent;（Nginx 启动会报 invalid UTF-8 或 regex compile error）
- ✅ 正确做法一（推荐）：用 PCRE 兼容的 Unicode 字符类或转义 —— 但更稳妥的是 改用匹配编码前的语义逻辑，比如按路径结构或参数区分，而不是依赖具体中文名
- ✅ 正确做法二：如果必须匹配含中文的路径，确保配置文件保存为 UTF-8 编码，并在 nginx.conf 开头加 charset utf-8;；同时确认系统 locale 支持 UTF-8（如 en_US.UTF-8），否则仍可能解析失败
特殊字符需按编码后形式处理（尤其空格和百分号）
空格在 $uri 中表现为字面空格（不是 `%20`），但你在正则里写空格容易被忽略或引发语法问题：
- 空格建议用 \s 或 [[:space:]] 匹配，例如：rewrite ^/file\s+name\.pdf$ /fixed-name.pdf permanent;
- 如果原始请求里有 `%20`，它已被解码成空格，所以不要在正则里写 `%20` —— 那样永远不匹配
- 若需匹配字面 `%` 符号（比如重写含 `%2F` 的路径），要写成 %%（Nginx 要求对 `%` 二次转义），例如：rewrite ^/path/%%2Fsub$ /real/sub permanent;
用 return 或 try_files 替代复杂 rewrite（更安全）
当涉及多字节字符或易混淆的编码场景，rewrite 容易出错。可考虑更可控的方式：
- 用 return 301 直接跳转，避免正则解析：location = "/old/页面.html" { return 301 /new/page.html; }
- 用 try_files 做静态映射：location /zh/ { try_files $uri /zh/index.html; }
- 对动态需求，把解码逻辑交给后端（如 PHP/Node），Nginx 只做简单路径转发，避免在前端处理编码边界
