nginx 中中文路径 rewrite 的关键是始终在 utf-8 字节层面处理，因 nginx 已自动解码 uri，正则应直接匹配解码后的 utf-8 字节，配置文件须存为 utf-8 无 bom，pcre 需支持 utf-8，rewrite 后避免二次编码，调试须用 curl 和 debug 日志验证。
在 Nginx 中对含中文路径做 rewrite，关键不是“解码再重写”，而是让整个流程始终在 UTF-8 字节层面一致处理——Nginx 不会自动把 `%E6%B5%8B` 转成“测”再匹配，它只按原始字节（已解码后的 UTF-8 字节序列）进行正则匹配。乱码本质是字节错位，不是显示问题。
确保 rewrite 匹配的是已解码的 UTF-8 字节
Nginx 在执行 rewrite 前，已对请求 URI 做了一次标准 URL 解码（即把 %E6%B5%8B 变成对应 UTF-8 字节）。所以你的正则应直接面向这些字节写，而不是写编码后的字符串。
- ✅ 正确示例（匹配中文“测试”）：
rewrite ^/测试/(.*)$ /api/v1/$1 break;
这要求配置文件本身用 UTF-8 编码保存，且终端、编辑器不插入 BOM 或混用 GBK - ❌ 错误写法：
rewrite ^/%E6%B5%8B%E8%AF%95/(.*)$ ...—— Nginx 此时收到的已是解码后字节，不会再去匹配百分号编码串
规避 PCRE 版本与 UTF-8 支持风险
旧版 PCRE（
- 检查 PCRE 是否支持 UTF-8：
nginx -V 2>&1 | grep -o 'PCRE.*UTF-8'，应输出类似PCRE library version: 8.45 2021-01-27 (UTF-8) - 若不支持，升级 Nginx 或使用
utf8修饰符（Nginx ≥ 1.11.8）：rewrite ^/([^/]+)$ /index.php?path=$1 break; # 加 utf8 保证捕获完整汉字
写为：rewrite ^/([^/]+)$ /index.php?path=$1 break; utf8;
避免 rewrite 后二次编码导致下游出错
rewrite 后跳转或 proxy_pass 时，Nginx 默认会对新 URI 再次编码（尤其含空格、括号等），可能把“测试.html”变成“%E6%B5%8B%E8%AF%95.html”，而有些后端又重复解码，引发双重解码错误。
- 用
last替代redirect或permanent，避免 301/302 跳转触发浏览器再次编码 - proxy 场景下，禁用自动编码：
proxy_pass_request_headers off;
并显式设置：proxy_set_header X-Original-URI $request_uri;
让后端自己决定如何解析原始请求行
调试与验证方法
不要靠浏览器地址栏输中文来测试——它依赖客户端编码逻辑不可控。必须用已知编码的 curl 验证。
- 用
curl -v "http://host/%E6%B5%8B%E8%AF%95/file.txt"发送标准 UTF-8 编码请求 - 开启 Nginx debug 日志：
error_log /var/log/nginx/debug.log debug;
查看http uri:行，确认解码后字节是否为你预期的 UTF-8 序列（如uri: "/测试/file.txt"） - 配合
log_format记录原始和解码后值：log_format debug '$request_uri → $uri';
