17370845950

HTML5页面部署后404错误主因是服务器路径配置、文件部署或路由不匹配；需检查静态资源是否存在、URL与实际路径是否一致、服务器根目录配置、History模式fallback规则、文件权限及CDN缓存。

HTML5 页面部署后出现 404 Not Found 错误，绝大多数情况不是 HTML5 本身的问题，而是服务器路径解析、文件部署或路由配置没对上。先确认静态资源是否真在服务器上、URL 是否和实际路径一致，再查服务端逻辑。

检查浏览器地址栏 URL 和实际文件路径是否匹配

这是最常被忽略的一步。HTML5 是纯静态文件，404 意味着服务器根本没找到对应路径的文件。

• 打开浏览器开发者工具（F12），切到 Network 标签，刷新页面，看哪个请求返回了 404 —— 注意是 HTML 文件本身 404，还是 script、css、图片等资源 404
• 如果是 index.html 404，说明你访问的 URL（比如 https://example.com/app/）没映射到真实文件位置（比如服务器上实际是 /var/www/html/myapp/index.html）
• 检查服务器根目录是否正确：Apache 默认是 DocumentRoot，Nginx 是 root 指令；确认你上传的 index.html 确实放在该目录下，且文件名大小写完全一致（Linux 区分大小写！）
• URL 中带子路径（如 /myapp/）但没配 base 或重写规则，会导致相对路径引用的 JS/CSS 全部 404

HTML5 History 模式下刷新 404（Vue/React 路由常见）

单页应用（SPA）用 history.pushState 改变 URL 但不发请求，首次访问深层路由（如 /user/123）时，如果服务器没做 fallback 配置，就会直接 404。

• 现象：首页 / 能打开，但手动刷新 /about 或直接访问该 URL 就 404
• 解决方法不是改前端代码，而是配服务器：让所有非资源请求（即非 .js、.css、.png 等后缀）都返回 index.html
• Nginx 示例：

  location / {
    try_files $uri $uri/ /index.html;
  }

• Apache 示例（.htaccess）：

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]

检查文件权限与 Web 服务器用户读取能力

尤其在 Linux 服务器上，即使文件存在，也可能因权限问题导致 403（拒绝访问）或静默 404（部分配置下）。

• 运行 ls -l index.html，确认文件权限至少是 -rw-r--r--（644），所属用户/组能被 Web 服务进程（如 www-data、nginx 或 apache）读取
• 检查父目录权限：Web 服务器需要对整个路径有 x（执行）权限才能进入目录，例如 /var/www/html 目录权限不能是 600
• SELinux 启用时（如 CentOS/RHEL），可能拦截访问，临时测试可运行 setenforce 0 看是否恢复；确认后用 chcon 或 semanage 修复上下文

CDN 或反向代理缓存了旧的 404 响应

某些 CDN（如 Cloudflare）或 Nginx 反向代理会缓存 404 响应，即使你已修复文件，仍持续返回 404。

• 用 curl -I https://yoursite.com/index.html 查看响应头，关注 X-Cache、Age、CF-Cache-Status 等字段
• 如果是 Cloudflare，进仪表盘 → Caching → Configuration → 关闭 Cache 404s（默认关闭，但可能被手动开启过）
• Nginx 反向代理中，检查是否有 proxy_cache_valid 404 1m; 类似配置，临时注释掉并 reload
• 强制刷新 CDN 缓存：Cloudflare 的 Purge Everything，或针对具体 URL Purge

真正卡住的地方往往不在 HTML5 规范，而在路径拼写、大小写、服务器配置层级、CDN 缓存策略这些“看不见”的环节。先抓 Network 看清哪个请求 404，再顺着那个 URL 往服务器文件系统里一层层找，比猜原因快得多。