解决Nginx中文文件名乱码的关键是确保文件名字节、Nginx解析逻辑、HTTP响应头、浏览器渲染四者在UTF-8编码视角下完全对齐；需用ls -b确认文件名真实编码，配置charset utf-8及charset_types text/html，启用autoindex时须配套add_header Content-Type "text/html; charset=utf-8"，并验证客户端请求为UTF-8百分号编码。
解决 Nginx 中文文件名乱码，关键不是“加个 charset 就行”，而是让文件名字节、Nginx 解析逻辑、HTTP 响应头、浏览器渲染四者在 UTF-8 编码视角下完全对齐。任何一环用错编码（比如系统存的是 GBK 字节，Nginx 当 UTF-8 读，浏览器又按 ISO-8859-1 解），都会表现为 ? 或 。
确认文件系统中文件名的真实编码
Linux/macOS 文件系统不存“编码类型”，只存原始字节。中文文件名是否能被 Nginx 正确匹配，取决于这些字节是否为合法 UTF-8 序列。
- 用
ls -b查看文件名原始字节：若显示类似\346\226\207\344\273\266\345\220\215.txt，说明是 UTF-8；若混有\243\306等非标准 UTF-8 字节，则大概率是 GBK 或 Big5 编码 - 避免在 Windows CMD（默认 GBK）下直接创建含中文的目录并挂载到 Linux Nginx 根目录——此时文件名是 GBK 字节，但 Nginx 默认按字节原样匹配，找不到对应路径就会 404
- 已有非 UTF-8 文件名？可用
convmv -f gbk -t utf-8 --notest *批量转码（需先安装 convmv）
配置 Nginx 正确响应 UTF-8 路径与目录列表
仅设 charset utf-8; 不够，要覆盖 autoindex 输出、HTML 响应头、MIME 类型声明三处。
- 在
http或server块中添加：charset utf-8; - 启用目录浏览时，必须同时设置：
autoindex on;+charset_types text/html;（否则 autoindex 生成的 HTML 默认无<meta charset>，浏览器按 Latin-1 解析 UTF-8 字节） - 更稳妥写法（显式声明响应头）：
add_header Content-Type "text/html; charset=utf-8";，可放在 location 块内 - 注意：不要写
charset utf-8,gbk;—— 多值会误导浏览器回退到第一个（utf-8）之后尝试 gbk，反而引发二次解码错误
验证客户端请求是否符合 UTF-8 百分号编码规范
浏览器地址栏输入中文路径（如 /测试.html）时，会自动转为 %E6%B5%8B%E8%AF%95.html。这是标准 UTF-8 URL 编码。Nginx 的 location 匹配发生在解码后，所以必须确保：
- 请求 URL 确实是 UTF-8 编码：用
curl -v "http://localhost/%E6%B5%8B%E8%AF%95.html"测试，而非curl -v "http://localhost/测试.html"（后者依赖 curl 自身编码逻辑，不可靠） - 禁用可能干扰的模块：如旧版 ngx_http_sub_module 若配置不当，可能对已解码 URI 再次做字符替换，导致乱码
- 检查
$request_uri（原始未解码）和$uri（解码后）日志输出，确认 Nginx 收到的是预期字节序列
特殊环境注意事项
Windows 或 Docker 容器中部署 Nginx 时，系统级编码容易成为隐性陷阱。
- Windows：CMD 默认 GBK，用它创建文件或运行
nginx -t可能导致配置文件读取异常（尤其含中文注释或路径时）；推荐用 PowerShell（UTF-8）或 VS Code 终端，并确保配置文件保存为 UTF-8 无 BOM - Docker：基础镜像常为 en_US.UTF-8，但若自定义镜像未显式设置 locale，
LANG=C会导致某些工具（如 ls）输出异常；应在 Dockerfile 中加入：ENV LANG=C.UTF-8 - 反向代理场景：若后端是 PHP/FastCGI，务必检查
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;是否拼接正确——$fastcgi_script_name已解码，不应再对其中文部分二次 decode
