404页面返回200状态码是软404的主因，需验证响应头确为404；Nginx需加internal限制直接访问，Apache需确保ErrorDocument生效；静态托管平台默认不支持真404；路径、权限、CDN、资源引用及框架路由均可能导致状态码或渲染异常。
404页面返回200状态码
这是最常见也最隐蔽的原因：你放了一个404.html，但服务器根本没把它当错误页用，而是当成普通页面返回了200 OK。搜索引擎和浏览器都认这个状态码，结果就是“看起来像404，实际是200”——软404。
必须验证响应头：curl -I http://localhost/nonexistent 或打开浏览器 Network 面板，确认看到的是 HTTP/1.1 404 Not Found，而不是 200 OK。
- Nginx 配置里只写
error_page 404 /404.html;不够，得加location = /404.html { internal; }，否则直接访问/404.html会返回 200 - Apache 的
ErrorDocument 404 /404.html要确保放在生效的配置段（如虚拟主机或.htaccess），且mod_alias已启用 - 静态托管平台（GitHub Pages、Vercel）默认不支持真 404 状态码，它们的“404 页面”本质是前端路由 fallback，响应永远是 200 —— 别指望它能被爬虫识别
自定义404页面路径未被服务器识别
服务器不知道该去哪找你的404.html，或者它被挡在了权限/路径规则之外。
比如 Nginx 默认只允许从 root 目录下读取文件，如果你把 404.html 放在 /var/www/errors/404.html，但 root 指向的是 /var/www/html，那就会 404 套 404。
立即学习“前端免费学习笔记（深入）”；
- 确保
404.html和主站 HTML 在同一层级，或明确配置root路径指向其所在目录 - 检查文件权限：Nginx/Apache 进程用户（如
www-data）必须有读取该文件的权限 - 某些 CDN 或 WAF（如 Cloudflare）会劫持 404 请求并重定向，导致你本地配好了，线上却看不到——用手机或 curl 绕过 CDN 测试真实响应
HTML中引用了外部资源但加载失败
你的404.html本身能返回 404 状态码，但页面内嵌的 CSS、JS 或图片路径又错了，结果页面空白、样式错乱、按钮失效——用户根本看不出这是个“设计过的404页”。
尤其在移动端或受限网络环境下，这些资源加载失败概率更高，反而放大了错误感。
- 404 页面应尽量内联关键 CSS 和 JS，避免依赖外部 CDN 或相对路径（如
./css/main.css） - 所有资源路径建议用绝对路径，例如
/css/404.css，而非../assets/css/404.css - 禁用非必要请求：不要在 404 页面里调 Google Analytics、微信 JS-SDK 或埋点脚本
框架或中间层覆盖了原生404逻辑
Vue Router、React Router 的 history 模式，或 SpringMVC 的 DispatcherServlet，或 Flask 的路由装饰器，都可能“吃掉”原本该由 Web 服务器处理的 404。
现象是：URL 明明不存在，但页面没报错，只是白屏或跳到首页——这不是服务器没配好，是上层逻辑兜底了。
- Vue/React 项目开启 history 模式后，Nginx 必须加
try_files $uri $uri/ /index.html;，否则刷新/about就真 404；但这也意味着所有 404 都被前端接管，无法触发服务端error_page - SpringMVC 若
<url-pattern>/</url-pattern>拦截全部请求，需显式放行静态资源：<resources mapping="/static/**" location="/static/"></resources> - Flask 中，如果所有路由都用
@app.route()定义，没写@app.errorhandler(404)，那 404 请求就直接 404，不会进你的模板
真正难调试的从来不是“页面没显示”，而是“页面显示了但状态码不对”或“状态码对了但资源全断”。每次改完配置，务必用 curl -I 看头，用 Network 面板看资源加载链路——别信肉眼所见。
