自定义 404 页面不生效，可能是宝塔面板在作怪

首先，为这个略带“标题党”味道的标题道个歉。与其说是宝塔面板在“作怪”，不如说是它太贴心了——默认帮你把 404 页面给“安排”好了。对于很多站点来说，404 页面往往只是一个空白提示页，甚至直接交给服务器默认处理。但像我这种使用高级 WordPress 主题的站点，本身就具备完善的页面自定义能力，404 页面自然也早就精心设计过。

其实，我很早之前就发现自己的 404 页面有点不对劲。右边是浏览器默认的 404 状态页，而按照主题预设，左边才是我自定义的完整 404 页面。只是这问题一直不影响正常访问，也就懒得深究。直到最近对站点做了一次拆分和结构调整，顺手把这个“小毛病”彻底排查并修复了，这才有了这篇文章。

1. WordPress 的 404 是怎么工作的？

很多人以为 404 页面是服务器返回的，其实不完全对。正常情况下流程是：

1. 浏览器请求一个不存在的 URL
2. Nginx 把请求交给 index.php
3. WordPress 判断找不到内容
4. 设置 is_404() = true
5. 加载主题的 404.php 模板
6. 输出主题定义的 404 页面

所以问题的关键在于：主题的 404 页面生效的前提，是请求必须成功进入 WordPress。如果这个请求在到达 WordPress 之前就被服务器层拦截并处理了，那无论主题里的 404 页面做得多么精美、多么完善，都完全不会生效。

而我标题里所谓“宝塔在作妖”，其实正是因为宝塔在网站设置中默认启用了自定义 404 页面。请求在 Nginx 层就已经被处理掉，自然就轮不到 WordPress 接管了。

2. 最常见原因：伪静态 / try_files 失效

这次的问题其实很好判断——页面没有任何主题样式，没有加载任何 wp-content 相关资源，页面上只剩下一句干巴巴的 “404 Not Found”。

这种现象基本可以直接下结论：请求根本没有进入 WordPress，而是在 Nginx 层就被拦截并返回了 404。

和 ChatGPT 交流后，大致可以归纳为两个常见方向：

1. 伪静态规则失效（try_files 未正确生效）
2. 请求在服务器层被提前拦截

当然，也不能排除 WordPress 本身的问题。根据我多年的经验，很多“玄学”固定链接问题，其实只需要进入：WordPress 后台 → 设置 → 固定链接，什么都不用改，直接点击“保存更改”一次，就能重新生成 Rewrite 规则，问题往往就消失了。

3. 本次 404 页面解决方案

所以我的排查顺序也很简单：

第一步，进入 WordPress 后台，重新保存一次固定链接。
第二步，进入宝塔面板 → 网站 → 设置 → 伪静态，在下拉框选择 WordPress 模板并保存，确保 try_files 规则正常。

但真正的问题，并不在这里。最后排查到宝塔网站配置文件，在 Error Page 部分看到了这一段：

#ERROR-PAGE-START  错误页配置，可以注释、删除或修改
error_page 404 /404.html;
#error_page 502 /502.html;
#ERROR-PAGE-END

问题，恰恰就出在这里。这个配置会让 404 页面直接导向宝塔面板新建网站时默认生成的 404.html，而我一开始就把这个文件给删了，所以就直接成了浏览器最基本的 404 状态页。

因此解决方案就很明了了，直接删除或者注释掉这一行，让服务器不再强制跳转到那个并不存在的 404.html 文件，而是交由当前站点自身的错误处理机制来接管。这样一来，系统就会按照现有的路由规则或框架默认的 404 逻辑来返回页面，而不是简单地抛出一个空白的浏览器原生 404 提示。

总结来说，这次问题的根源并不复杂，而是配置与文件实际存在状态不一致导致的。当服务器被明确指定跳转到某个错误页面时，该文件就必须真实存在；否则只会得到更原始、更简陋的错误反馈。遇到类似情况时，优先检查错误页配置与实际文件是否匹配，往往能快速定位问题。