HTML文件本身不能重定向404页面，真404必须返回HTTP/1.1 404 Not Found状态码；任何JS跳转、meta refresh或服务端301/302都会导致软404，损害SEO与可访问性。
HTML 文件本身不能做重定向——所谓“404 页面跳转”，本质是混淆了「状态码返回」和「客户端跳转」。真 404 必须返回 HTTP/1.1 404 Not Found 状态码，任何 window.location.href、<meta http-equiv="refresh"> 或服务端 301/302 都会掩盖错误，触发搜索引擎标记为“软 404”。
为什么不能在 404.html 里写 JS 跳转
用户访问 /nonexistent，服务器已返回 404 状态码 + 你的 404.html 内容；此时再执行 window.location.href = "/"：
- 浏览器地址栏先闪现错误路径，再跳走，体验割裂
- 响应头仍是
404 Not Found，但页面 DOM 已被替换，爬虫可能抓不到原始上下文 - Google 明确将此类行为归为软 404：不计入真实错误统计，且可能降权
- 禁用 JS 的环境（如部分屏幕阅读器、企业内网）直接卡在空白页或残缺内容上
Nginx 中正确配置自定义 404 页面
目标是：请求未命中时，返回真实 404 状态码，同时渲染你写的 /404.html —— 不是跳转，是内部响应体替换。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 确保
fastcgi_intercept_errors on;已启用（在http或server块内） - 主
location /块中加：error_page 404 /404.html;（路径必须以/开头） - 单独声明
location = /404.html { internal; }，防止外部直接访问该路径返回 200 -
/404.html文件需放在网站根目录，且第一行含完整 HTML 结构（避免被 CDN 截断）
GitHub Pages 和 Netlify 的差异处理
静态托管平台不让你改服务器逻辑，但各自有约定俗成的“真 404”触发方式：
立即学习“前端免费学习笔记（深入）”；
- GitHub Pages：严格要求文件名为
404.html，且必须放在仓库根目录（pages/404.html无效）；它会自动对所有未匹配路径返回 404 状态码 + 该文件内容 - Netlify：需在
_redirects文件中写/* /404.html 404，或在netlify.toml中配[[redirects]] from = "/*" to = "/404.html" status = 404 - 两者都不支持带参数的跳转（如
/search?q=/nonexistent），也不允许你在404.html里再 JS 跳转——否则状态码失效
最容易被忽略的一点：本地双击打开 HTML 文件永远测不出真 404，必须走 HTTP 协议。用 npx serve 启服务后，再用 curl -I http://localhost:5000/xxx 看第一行是否为 HTTP/1.1 404 Not Found —— 这才是唯一可信验证方式。
