Nginx默认不支持直接解析未经编码的中文路径，必须确保客户端请求为UTF-8百分号编码（如/文章/→/%E6%96%87%E7%AB%A0/），文件系统存储为UTF-8编码，Nginx配置启用charset utf-8，并避免location中硬写中文路径。
Nginx 默认不支持直接解析未经编码的中文路径（如 /文章/ 或 /产品详情.html），遇到这类请求时，会因 URI 解析失败或文件系统匹配不到而返回 404。这不是配置写错，而是编码、解码与文件系统协同的问题。
确保客户端请求是 UTF-8 编码的 URL
浏览器通常会对中文路径自动进行百分号编码（如 /文章/ → /%E6%96%87%E7%AB%A0/）。但某些前端框架、curl 命令或测试工具若未正确编码，就会发来原始中文字符，Nginx 无法识别，直接 404。
- 开发调试时，用
curl -v "http://localhost/%E6%96%87%E7%AB%A0/"测试，而非curl "http://localhost/文章/" - 前端跳转建议统一用
encodeURI()处理路径，例如：location.href = encodeURI('/文章/'); - 检查 Access Log 中的请求 URI 字段，如果看到未编码的中文（如
"GET /文章/ HTTP/1.1"），说明上游已出错，需从前端或代理层修正
确认文件系统能读取中文文件名
Nginx 本身不处理文件名解码，它把解码后的路径原样交给操作系统查找。所以即使 URL 正确编码，若文件系统或目录权限不支持中文，仍会 404。
- Linux 文件系统（如 ext4）默认支持 UTF-8 文件名，但需确保挂载时未禁用（一般无需额外设置）
- 检查真实文件是否存在且命名一致：
ls -l /var/www/html/看是否显示文章/目录；可用stat "文章"验证 inode 名称是否为 UTF-8 字节序列 - 确保 Nginx worker 进程用户（如
www-data）对含中文路径的目录有执行权限（x）：目录需755，文件需644
避免 location 匹配与编码不兼容
使用正则或前缀匹配时，若规则依赖原始字符（比如 location /文章/ { ... }），Nginx 实际匹配的是编码后字符串，必然失败。
- 不要在
location中硬写中文路径——Nginx 配置文件本身应保存为 UTF-8 编码，但运行时不按字符语义匹配 - 推荐用通用匹配代替：
location / { try_files $uri $uri/ /index.html; }，让前端路由或后端统一对接 - 若必须精确控制，用正则匹配编码片段：
location ~ ^/%E6%96%87%E7%AB%A0(/|$)，但可维护性差，仅作临时排查
反向代理场景下的中文路径透传
当 Nginx 作为代理时，后端服务（如 Node.js、Python）可能自行解码，导致重复解码或乱码，最终找不到资源。
- 默认情况下，Nginx 会将已编码的 URI 透传给后端，不干预解码过程
- 确认后端是否开启了双重解码（例如 Express 的
app.set('trust proxy', true)不影响路径，但某些中间件可能误操作） - 必要时，在
proxy_pass前加rewrite统一标准化路径，例如：rewrite ^/(.*)$ /$1 break;（保持编码不变）
