网页接入 CDN 后出现白屏，控制台提示脚本或样式的 MIME 类型不受支持，但 Network 面板里的资源请求却显示 200。这时应该检查返回的正文：请求的虽然是 .js 或 .css，实际拿到的可能是首页、登录页或错误页。
只把 Content-Type 改成 JavaScript，无法把一份 HTML 变成代码；关闭 X-Content-Type-Options: nosniff 也修不好错误的资源路径。本文从失败请求入手，区分 MIME 映射、单页应用回退、CDN 改写与版本发布问题，并给出修复后的验证顺序。
状态码 200 与资源类型正确是两回事
浏览器需要根据实际的响应类型处理资源。Fetch 标准规定，在启用 nosniff 的检查下，脚本和样式请求会因不匹配的 MIME 类型被阻止；HTTP(S) JavaScript 模块的加载还有相应的 MIME 检查。因此，返回成功状态码不保证脚本或样式能被接受。[1][2]
先在开发者工具中选中失败的那一条请求，同时查看 URL、状态码、Content-Type、响应正文、重定向和缓存来源。错误大致可以分为以下几类：
| 响应特征 | 优先排查 |
|---|---|
text/html，正文是站点首页 |
缺失资源落入 SPA 回退、错误响应被改写为首页 |
text/html，正文是登录或验证页面 |
鉴权中间件、安全验证、错误的跳转规则 |
正文确实是代码，类型却是 text/plain 或其他不合适的值 |
源站 MIME 映射、对象存储元数据、CDN 响应头规则 |
| 刚发布后只有部分用户失败，URL 含旧内容哈希 | 旧页面仍引用已删除的资源或旧动态分块 |
| 同一 URL 在源站正确，在 CDN 上返回旧的 HTML | 缓存中的错误对象、回源路径或边缘改写 |
表中的现象只能帮助缩小范围。要把响应正文、请求链和各层配置对齐后再下结论，不能仅凭一个 Server 或缓存标识头判断责任位置。
用一次 GET 保存响应，确认拿到的究竟是什么
从浏览器复制失败资源的完整 URL，保留实际路径和版本参数；分享排查记录前隐藏令牌、Cookie、个人信息及查询参数中的密钥。下面的命令适用于安装了 curl 的 Linux、macOS 或 WSL。Windows PowerShell 可使用 curl.exe，并调整该终端的换行写法。
curl --silent --show-error --compressed \
--connect-timeout 5 --max-time 20 \
--dump-header asset-headers.txt \
--output asset-body.txt \
--write-out 'status=%{http_code} type=%{content_type} total=%{time_total}s\n' \
'https://static.example.com/assets/app-abc123.js'
这是一次 GET，不会自动重试或跟随跳转。--compressed 会请求 curl 支持的压缩编码并解压响应，便于查看正文。使用自己管理的资源地址，避免把诊断命令指向敏感写接口。
检查响应时，先回答几个具体问题：
- 正文开头是不是
<!doctype html>、<html>，或与首页内容一致？ - 状态是否为 3xx，
Location是否指向首页、登录页或验证入口？ - 浏览器显示的资源地址是否与命令完全相同，包括大小写、前缀和查询参数？
- 响应是否来自 CDN、浏览器本地缓存或 Service Worker？是否有可关联的请求 ID、
Age和缓存命中信息？
命令行与浏览器结果不同，还应比较鉴权、请求头和 Service Worker 的参与情况。不要用一次未登录请求去否定登录用户的故障。只发 HEAD 也不足以确认正文，因为它不返回需要检查的内容。
将静态资源缺失与 SPA 页面回退分开处理
单页应用常把 /account/settings 等前端路由交给 index.html。如果相同的回退也覆盖 /assets/app-abc123.js，缺失的脚本就可能得到首页 HTML 和 200 状态码。浏览器随后按模块脚本加载它，报出的就是 MIME 类型错误。
以 Linux 上的 Nginx 静态托管为例，假设实际构建目录为 /srv/www/app/dist，所有构建资源位于 /assets/。下面仅展示已有 server 中需要核对的部分，不是可直接覆盖生产配置的完整文件：
root /srv/www/app/dist;
location ^~ /assets/ {
try_files $uri =404;
}
location / {
try_files $uri $uri/ /index.html;
}
这里让缺失的 /assets/ 文件返回 404，页面路由仍可回退到首页。Nginx 官方文档说明，try_files 会按配置的路径检查文件，最后一个参数可以是内部跳转目标或返回状态码。[3]
使用前必须按实际目录调整：资源可能位于 /static/、子路径或对象存储；alias 与 root 的路径拼接方式也不同。还要检查其他正则 location、继承的 error_page、反向代理和 CDN 错误页规则，确认最终的 404 没有再次被改成首页。
如果是 CloudFront，官方文档明确支持把源站的某些错误状态改为 200 并返回自定义错误页。这样的能力可以用于特定场景，但也说明“边缘返回 200”不足以证明源站找到了资源。[6] 其他平台需要核对各自的错误响应和路径行为，不能照搬产品设置。
修改前保存原配置及回退规则。先验证前端深层路由、真实静态文件和不存在的静态文件三类请求；Nginx 配置检查通过后再按团队流程重新加载。出现影响时恢复原配置，不需要清空业务数据或全站关闭防护。
正文正确时，再修复 MIME 配置
只有确认响应正文确实是目标代码，才进入文件类型配置排查。
Nginx 需要检查生效配置中的 types 映射和 mime.types 引入情况，同时确认相关 server 或 location 没有覆盖映射。.css 应作为 text/css 返回；JavaScript 模块应返回浏览器接受的 JavaScript MIME 类型，例如 text/javascript。不要把全部资源统一设成同一个 default_type，那会影响 HTML、图片、字体等其他文件。[1][2][3]
对象存储则要检查该对象上传时的内容类型元数据，并用实际 GET 验证。若源站正确、CDN 错误，检查边缘响应头改写、错误缓存及回源路径。修正时保持安全响应头的作用范围，不靠删除 nosniff 掩盖问题。
如果正文是 HTML，回到路径与回退规则处理。强行给首页加上 JavaScript 类型，可能只会让错误从 MIME 不匹配变成语法错误，真实的缺失资源依旧没有恢复。
发布后才出错，核对资源前缀与新旧版本
应用部署在 /app/，构建结果却引用 /assets/，或者资源迁到独立域名后仍使用旧前缀，都可能请求到不存在的位置。Vite 的部署文档说明，部署到不同的公共基础路径时需要正确设置 base。[4] 其他构建工具也要核对各自的资源前缀、运行时公共路径以及 CSS 引用资源的方式。
检查时用构建后的 HTML 和资源清单对照线上文件，不只看开发环境能否运行。CDN 回源前缀是否重复添加、路径大小写是否一致、资源是否上传到对应目录，也应逐项核对。
另一个常见触发点是过早删除旧的内容哈希文件：用户还开着旧页面，页面后来才加载动态分块，而该文件已经在新部署中被删掉。Vite 官方文档描述了这种动态导入失败场景，并提醒避免让旧 HTML 持续引用已消失的资源。[5]
可采用以下发布顺序，具体保留时间由页面寿命、回滚窗口和业务约定决定：
- 先上传并验证新版本资源，再切换引用它们的 HTML。
- 给页面入口与内容哈希资源设置各自合适的缓存策略，入口需要能及时重新验证；长缓存的哈希 URL 应保持内容不变。
- 为仍可能打开的旧页面保留对应资源，并保留回滚所需文件。
- 发现错误后，先恢复正确的文件、路径或响应，再刷新受影响的 CDN 对象。
仅清理所有缓存，无法恢复已经删除的文件；仅要求用户刷新，也不能替代修复发布顺序。若采用自动重新加载来处理分块错误，应限制次数，避免不断刷新页面或丢失未保存输入。
按 URL 验证修复，避免只看首页恢复
源站修复后，先确认同一个失败 URL 返回正确正文、状态和类型，再检查经过 CDN 的结果。如果需要绕过 CDN 对照，使用团队已有的受控诊断入口，保持 Host、TLS、路径和鉴权一致，不要临时公开源站。
刷新缓存时要覆盖真正命中的资源路径及相关变体，核对查询参数、主机名和缓存键。检查冷请求与后续命中请求，确认错误 HTML 不会在下一次回源后重新进入缓存。源站返回缺失文件时，应继续保持预期的错误状态，而不是再次由首页接管。
最后回到浏览器验证：
- 深层前端路由仍然可用，真实的 JS/CSS 能加载，不存在的静态文件不会拿到首页。
- 页面、脚本、样式和动态分块来自相互兼容的版本，旧会话仍能完成必要操作。
- 控制台没有新增 MIME、模块加载或跨域错误；若随后出现 CORS 问题，应按跨域流程单独排查。
- 核对 Service Worker 的更新和缓存策略，必要时在受控测试会话中临时绕过它复测，不让“清空所有用户站点数据”成为默认修复动作。
当失败 URL 的状态、正文和类型都一致，且新旧页面经过 CDN 均能正确加载，才说明问题得到解决。留下故障 URL、错误内容来源、配置改动和验证结果，下一次发布就能检查同一条链路。
官方参考资料
资料核验日期：2026 年 10 月 16 日。文中的路径、文件名和 Nginx 片段均为说明性示例，未声称完成生产环境测试。
