404页面返回200状态码是致命错误，因其导致搜索引擎持续索引死链、破坏缓存机制；根本原因是Nginx默认将error_page指定的静态文件（如/404.html）以200状态返回，需通过internal指令或正确配置error_page语法（空格分隔而非等号）强制继承404状态。
为什么404页面返回200状态码是致命错误
很多团队把404.html放在项目根目录，Nginx配置error_page 404 /404.html，但浏览器Network面板里看到的响应头却是HTTP/1.1 200 OK——这会让搜索引擎持续索引“死链”，用户刷新时也得不到正确缓存行为。
根本原因在于：Nginx默认把/404.html当作普通静态文件返回，不自动继承404状态。必须显式干预。
- 正确做法是在
location = /404.html块中加internal;，阻止外部直接访问，再配合error_page触发时自动带出404状态 - 如果用
return 404;代替error_page，则需手动输出HTML（不推荐） - 本地测试务必用
curl -I https://yoursite.com/nonexistent验证响应头，不能只看页面内容
多个前端项目共用同一套错误页的硬约束
当工程里有十几个-client结尾的SPA项目（如admin-client、user-client），又不想每个都复制一份404.html和500.html，符号链接是最轻量且可维护的方案。
关键限制是：Nginx的error_page路径必须能被root或alias解析到，且文件要有可读权限；符号链接目标必须在Web服务器用户（如www-data）能访问的路径下。
立即学习“前端免费学习笔记（深入）”；
- 推荐将统一错误页放在
/data/html/error/，用ln -s /data/html/error/404.html /data/src/admin-client/404.html批量生成 - 禁止把源文件放在
/etc或/root等受限目录——Nginx worker进程无权读取 - 检查链接有效性：
ls -l /data/src/*/404.html，确保箭头指向真实文件且无broken提示
Spring Boot里error目录失效的典型原因
Spring Boot默认从src/main/resources/templates/error/找404.html、500.html，但实际运行时经常404页没生效，返回的是白板或默认Tomcat错误页。
核心问题不在模板位置，而在资源路径与DispatcherServlet拦截范围的冲突。
- 确认
spring.mvc.throw-exception-if-no-handler-found=true已启用，否则404不会进错误处理流程 - 静态资源路径（如
static/）下的404.html会被Spring默认静态资源处理器优先匹配，必须删掉或移出static - Thymeleaf模板需放在
templates/error/，且文件名严格为404.html（不能是404-old.html） - 若用WebMvcConfigurer自定义
addViewControllers()，会覆盖默认错误页映射，需显式注册registry.addViewController("/error").setViewName("error/404");
IE浏览器强制显示自定义404页的兼容写法
IE有个“显示友好HTTP错误信息”开关，默认开启。即使后端返回真实404状态，IE也会拦截并显示自己的简陋错误页，完全无视你的404.html。
唯一可靠解法是在错误页开头用服务端逻辑重置状态码为200，但仅限于JSP/PHP等能执行服务端代码的场景；纯静态HTML无法绕过此限制。
- JSP页第一行必须写
，且不能有任何前置输出（包括空格、BOM） - 该技巧只对IE有效，Chrome/Firefox仍保持404状态，所以SEO和爬虫不受影响
- 注意：此操作会让
curl -I看到200，但IE用户看到的就是你设计的页面——这是权衡后的妥协 - 现代项目若已放弃IE支持，直接删掉这行，专注保证真实404状态即可
最常被忽略的点是日志联动：无论页面多美观，如果Nginx或应用层没记录原始request_uri和http_referer，就无法区分是内部链接写错还是爬虫扫废弃路径。错误页本身只是表象，日志才是根因入口。
