Nginx rewrite不处理URL解码，操作的是已解码的URI；中文路径问题主因是编码状态不一致或隐式再编码，需确保locale为UTF-8、配置文件UTF-8编码、避免手动拼接编码字符串，并正确使用alias和last/break。
Nginx 的 rewrite 指令本身不参与 URL 解码逻辑，它操作的是 Nginx 已解码后的 URI 字符串。若中文 URL 出现 404 或重写后路径错乱，问题通常不在 rewrite 本身，而在于重写前后的编码状态是否一致、是否触发了隐式再编码。
rewrite 前必须确保 URI 已正确解码
Nginx 默认会对客户端请求的 URI 自动做一次百分号解码（URL decode），得到 UTF-8 字节序列后再进入 location 匹配和 rewrite 阶段。这意味着：
- 浏览器发送
/file/中文.txt→ 自动编码为/file/%E4%B8%AD%E6%96%87.txt→ Nginx 收到后解码为/file/中文.txt（内部处理用） - 此时你在
rewrite ^/file/(.*)$ /static/$1 break;中匹配到的$1就是中文.txt（UTF-8 字节），不是%E4%B8%AD%E6%96%87.txt - 只要文件系统里真有
/static/中文.txt且 locale 是 UTF-8，就能命中
避免 rewrite 引发二次编码或路径错位
某些 rewrite 写法会意外导致 Nginx 内部重新编码 URI，尤其在使用 redirect 或未加 last/break 时：
- 用
rewrite ... permanent;或redirect：Nginx 会把重定向响应头中的 Location 值按当前 URI 字节原样生成，若其中含中文，可能被浏览器再次编码（如从中文变成%E4%B8%AD%E6%96%87），但这是浏览器行为，非 Nginx 主动编码 - 用
rewrite ... last;：触发内部重定向，Nginx 会将新 URI 再次解析、解码、匹配 —— 若 rewrite 后的 URI 字符串含未编码的中文，而 Nginx 配置中又存在 alias 或 root 路径拼接错误，就容易 404 - 不要在 rewrite 中手动拼接已编码字符串，例如：
rewrite ^/old/(.*)$ /new/%E4%B8%AD%E6%96%87-$1 last;—— 这会让 Nginx 把%E4当作字面字符，而非编码标识，结果路径错乱
安全可靠的 rewrite 中文路径写法
推荐始终以“解码后语义”编写规则，让 Nginx 在统一 UTF-8 上下文中工作：
- 确保服务器 locale 是 UTF-8（
LANG=zh_CN.UTF-8），并验证文件名真实字节为 UTF-8（ls -b 中文.txt应显示\344\270\255\346\226\207.txt） - rewrite 规则中直接使用中文（Nginx 配置文件需保存为 UTF-8 编码）：
rewrite ^/文章/(.*)$ /posts/$1 break; - 搭配
alias时注意末尾斜杠：location /posts/ { alias /var/www/content/; }（alias路径必须以/结尾，否则/posts/中文.html会被映射为/var/www/content中文.html） - 禁用干扰指令：不要在同 location 中混用
try_files $uri @fallback和复杂 rewrite；避免set $var …后再 rewrite，除非确认变量值未被额外转义
调试中文 rewrite 是否生效
启用详细日志可定位问题根源：
- 在 http 块中添加：
log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$request_uri" "$uri" "$document_uri" "$args"'; - 观察日志中
$request_uri（原始请求）、$uri（解码后用于匹配的路径）、$document_uri（最终查找的文件路径）三者是否一致 - 若
$uri显示为/file/%E4%B8%AD%E6%96%87.txt，说明 Nginx 未成功解码 —— 多数因系统 locale 非 UTF-8 或请求本身用 GBK 编码
