Nginx 中使用 alias 指令映射静态路径时，不会改变 MIME 类型的判定逻辑——它依然只看请求 URI 的后缀名，查 types 块匹配 Content-Type。也就是说，alias 只负责“把请求指向哪个文件”，而“这个文件该用什么类型返回”，完全由后缀决定，和 alias 路径里实际文件名或内容无关。
确保 alias 路径下的特殊后缀被正确识别
比如你用 alias /var/www/assets/; 把 /static/ 映射过去，访问 /static/icon.woff2，Nginx 提取的是 .woff2 后缀，不是 /var/www/assets/icon.woff2 这个完整路径。所以关键还是：你的 types 配置里有没有 font/woff2 woff2;。
- 若没配，Nginx 查不到
woff2→ 触发default_type（如application/octet-stream）→ 浏览器拒绝加载字体 - 若配了，且拼写准确（注意是
woff2不是wof2），就能返回Content-Type: font/woff2
常见 alias 场景下要补的 MIME 类型示例
这些类型常出现在前端构建产物或资源目录中，容易因默认 mime.types 缺失而报错：
-
application/javascript js mjs ts—— 支持 ES 模块、TypeScript 临时文件（如/static/app.mjs） -
font/woff2 woff2、font/woff woff—— 现代字体文件 -
image/avif avif、image/webp webp—— 新型图片格式 -
application/wasm wasm—— WebAssembly 模块 -
application/json json5—— 配置类 JSON 文件（如 VitePress 的.json5）
避免 location + alias 与 types 作用域脱节
如果 alias 写在某个 location 块里，而 types 只定义在 http 或上层 server，通常没问题（Nginx 会向上继承）。但要注意：
- 不要在该
location内又写types { }却漏掉关键类型——会覆盖外层，导致其他后缀失效 - 更稳妥的做法：把自定义
types放在http块，用include加载，确保所有location都能用到 - 若必须在
location内定义，需完整写出全部需要的映射，不能只补一两个
验证是否生效的最快方式
别依赖浏览器开发者工具看源码，直接查响应头：
-
curl -I https://yoursite.com/static/main.avif→ 应看到Content-Type: image/avif -
curl -I https://yoursite.com/static/config.json5→ 应看到Content-Type: application/json（如果你已配json5） - 如果返回
Content-Type: text/plain或压根没有该头，说明types没命中，优先检查拼写、include 路径、是否被覆盖
