proxy_pass 不处理 mime 类型映射，仅转发请求；静态资源的 content-type 由 nginx 的 types 和 default_type 配置决定，需通过独立 location 拦截并本地响应，避免被 proxy_pass 错误转发。
proxy_pass 本身不处理 MIME 类型映射——它只负责把请求转发给后端服务，响应头里的 Content-Type 由后端决定。但如果你用 Nginx 同时充当静态资源服务器（比如托管前端构建产物）和反向代理（比如转发 /api 到后端），那特殊文件（如 .woff2、.avif、.mjs、.webp）的 MIME 类型就取决于 Nginx 自身的 types 配置，而不是 proxy_pass。
明确区分：静态资源走 Nginx，动态请求走 proxy_pass
这是关键前提。Nginx 不会因为配置了 proxy_pass 就自动接管所有路径的 MIME 类型；只有当请求被某个 location 拦截并由 Nginx 直接响应（比如 root + try_files）时，types 和 default_type 才生效。
常见错误是把所有请求都 proxy_pass 到一个后端，却期望 Nginx 给 .woff2 返回 font/woff2 ——这不可能，后端得自己设对 Content-Type。
所以要让 Nginx 处理特殊文件 MIME 类型，必须确保这些文件路径由 Nginx 本地服务，而不是被 proxy_pass 掉。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
在静态资源 location 中显式配置 types 和 default_type
比如你把前端打包文件放在 /var/www/dist，希望正确识别 .mjs、.avif、.webp：
- 在对应 server 或 http 块中，用内联 types 补充新类型：types { application/javascript mjs; image/avif avif; image/webp webp; }
- 确保该 location 能访问到 types 配置（推荐写在 http 块里，全局生效）
- 显式设置兜底：default_type application/octet-stream;，避免未定义扩展名返回空 Content-Type 导致浏览器拒绝加载
- location 示例：
location / {
root /var/www/dist;
try_files $uri $uri/ /index.html;
}
proxy_pass 场景下仍需保证静态资源不被误代理
如果你的配置类似这样：
- location / { proxy_pass http://backend; } → 全部转发，Nginx 根本不看 mime.types
- location /static/ { alias /var/www/assets/; } → 这里才用得上 types
务必把静态资源路径（如 /assets/、/fonts/、/images/）单独拆出 location，并确保它们不落入 proxy_pass 的匹配范围。可用精确匹配或前缀排除：
- location = /favicon.ico { try_files /favicon.ico =404; }
- location ^~ /fonts/ { root /var/www/dist; }
- 再用 location / { proxy_pass http://backend; } 处理其余请求
验证是否生效：别只看 proxy_pass，要看实际响应头
对一个 .woff2 文件发起请求，用 curl 检查响应头：
- curl -I https://example.com/fonts/icon.woff2
- 如果返回 Content-Type: font/woff2 → types 生效
- 如果返回 Content-Type: text/plain 或没这个头 → 检查 location 是否命中、types 是否写对、default_type 是否兜底
- 如果返回 Content-Type: text/html → 很可能被 proxy_pass 错误转发到了后端，需调整 location 优先级
