网站出现404如何排查，关键是先确认问题范围，再沿着“访问地址—服务器路由—应用逻辑—缓存与部署”逐层定位。不要一看到404就直接修改首页或批量做跳转，先判断是单个页面不存在、整站路由异常，还是只有某些设备或网络环境无法访问。

先判断404影响了哪些页面

打开出现问题的完整地址，记录页面路径、访问时间、使用的域名、协议以及触发方式。随后分别测试首页、几个正常页面、同目录下的其他地址，以及出现404的页面。通过影响范围，通常可以快速缩小排查方向。

不同表现对应的优先排查方向

表现	优先检查内容
只有一个旧页面404	页面是否删除、改名，旧链接是否需要跳转
同一目录下多个页面404	目录路径、路由规则、伪静态或重写配置
整站页面普遍404	域名指向、站点根目录、发布版本、反向代理配置
刷新后或直接访问才404	前端路由、服务器回退规则、单页应用配置
只有部分用户或某个地区出现404	缓存、CDN节点、域名解析、灰度发布或权限策略

第一步：确认返回的确实是404

有些页面显示“找不到页面”，但服务器实际返回的并不是HTTP 404，而是200、403、500等状态码。可以打开浏览器开发者工具的“网络”面板，重新加载页面，查看主文档请求的状态码、最终请求地址和响应头。

如果页面显示错误但返回200，属于常见的“软404”表现。此时要检查应用是否把所有不存在的地址都返回了同一个页面，或者前端路由是否拦截了错误。反过来，如果服务器明确返回404，就应继续查找路径、文件或路由为何没有匹配。

还要注意请求类型。页面地址、图片、样式文件、脚本文件和接口地址都可能返回404。先确定是哪一个资源失败，不要只根据浏览器最终显示的错误页面判断。

第二步：检查访问地址是否发生变化

许多404并不是服务器故障，而是地址本身已经与实际页面不一致。逐项核对以下内容：

• 域名是否正确，是否误用了测试域名、旧域名或带有不同子域名的地址。
• 路径中的大小写是否一致。部分服务器区分大小写，/News和/news可能是两个不同地址。
• 路径末尾是否多了或少了斜杠，文件扩展名是否被删除或改变。
• 参数、锚点、特殊字符、中文字符和空格是否经过正确编码。
• 页面是否从HTTP切换到HTTPS，或从一个目录迁移到了新的目录。
• 站内链接、菜单、图片地址和接口调用是否仍然指向旧路径。

可以直接从网站内部入口重新进入目标页面，再与出现404的地址进行对比。如果内部入口能打开，而手动输入的地址不能打开，问题通常集中在链接拼写、路径规则或旧地址处理上。

第三步：检查文件是否真的存在

如果网站使用静态文件，先在服务器或发布目录中确认目标文件是否存在，文件名、目录层级和扩展名是否完全一致。还要检查最近一次发布是否漏传文件、上传到了错误目录，或发布脚本清理了原有文件。

如果页面原本存在，但最近改版、迁移或重新部署后出现404，应重点比较发布前后的目录结构。常见情况包括：源代码中有文件但未被打包，打包产物目录配置错误，服务器根目录指向了旧版本，或者新版本只发布了首页而没有发布子页面资源。

动态网站则不能只看物理文件。文章、商品或用户页面可能由数据库记录和程序路由动态生成。此时要确认对应数据是否仍然存在、是否被下架、是否使用了新的别名，以及程序是否能根据该别名查询到正确记录。

第四步：检查路由和重写规则

伪静态和重写规则是网站出现404的常见原因。一个看似普通的页面地址，可能需要由服务器把请求交给应用程序处理。如果重写规则未生效，服务器会把它当成不存在的实体文件，直接返回404。

排查时应确认：

• 当前站点加载的是哪一份服务器配置，修改是否已经应用到实际运行环境。
• 站点根目录是否正确，虚拟主机或反向代理是否把请求转发到了正确的应用。
• 重写规则是否覆盖了目标路径，是否被更高优先级的规则提前截断。
• 规则是否区分带斜杠与不带斜杠、大小写、文件扩展名或请求参数。
• 应用自身是否注册了对应路由，以及路由参数格式是否发生变化。

对于使用前端路由的单页应用，首页可能可以打开，但直接访问某个子路由或刷新子路由时出现404。这通常意味着服务器没有把前端页面路由回退到入口文件。修复回退规则时，也要避免把真正不存在的图片、脚本和样式文件全部返回入口页面，否则会产生新的资源加载问题。

第五步：利用日志确定是哪一层返回404

当页面和配置看起来都正常时，应按请求链路查看日志。先查Web服务器或反向代理的访问日志，确认请求是否到达服务器、实际请求路径是什么、返回状态码由哪一层记录。再查看应用日志，判断请求是否进入程序、是否因为数据不存在而主动返回404。

如果网站前面接入了CDN、缓存或网关，还要分别确认边缘节点和源站的结果。可以在不同网络环境、不同时间重复访问，并对比响应头、缓存状态和更新时间。若源站已经修复但部分访问仍然404，可能是旧缓存尚未失效；若只有某个节点异常，则需要检查该节点是否同步到最新配置或发布内容。

日志中应重点关注请求方法、完整路径、主机名、来源页面、状态码和响应时间。同一个路径是否同时出现200与404，也很有价值：这可能说明不同节点版本不一致、缓存内容不一致，或请求参数触发了不同的应用分支。

常见404场景应如何处理

页面改名或网址结构调整

如果旧地址对应的内容已经迁移到明确的新地址，可以为旧地址设置一对一的永久跳转，并同步修改站内链接、导航和相关入口。不要把所有失效页面都无差别跳转到首页，因为访问者无法得到原本想找的内容，也会增加后续定位难度。

页面被删除且没有替代内容

没有替代页面时，保留正常的404响应通常比伪造一个看似正常的页面更合适。自定义404页面可以提供站内搜索、主要栏目和返回首页的入口，但页面本身仍应返回404状态。

发布后大量页面同时404

优先回看本次发布的文件清单、构建输出、服务器根目录和路由配置。若确认是新版本导致，先恢复到已知正常版本，再单独修正发布流程。这样既能恢复访问，也能避免在故障状态下反复修改多个配置。

接口或动态内容返回404

检查请求地址、请求方法、版本前缀、参数格式和登录状态。接口找不到资源与网页找不到文件的处理方式不同，不能仅通过修改静态目录或首页回退规则解决。还要确认前端调用的接口版本是否与当前后端版本一致。

修复后要完成哪些验证

修复完成后，不要只测试一个浏览器页面。至少应验证原来的404地址、新地址、首页、同级页面、带参数地址、移动端常用资源以及关键接口。对于跳转，还要确认跳转目标正确、没有多次连续跳转，也没有出现循环跳转。

• 直接访问目标地址和从站内链接进入，结果应一致。
• 刷新页面、清理本地缓存后再次测试，排除旧缓存影响。
• 检查页面主文档和图片、脚本、样式等依赖资源的状态码。
• 确认不存在的随机地址仍返回真正的404，而不是返回200首页。
• 检查站点地图、导航、相关文章和外部投放入口中是否还保留失效地址。
• 观察修复后的访问日志，确认404数量是否下降，是否出现新的路径异常。

建立持续排查机制，减少404反复出现

网站出现404通常与网址变更、内容删除、发布失误或路由配置调整有关。每次改版前保留旧地址与新地址的对应关系，发布后抽查重点页面，并定期从访问日志中整理高频404路径，可以在问题扩大前发现异常。

对于经常变化的内容，建议统一管理网址规则、跳转规则和删除流程；对于程序项目，则应把路由测试、静态资源检查和发布目录校验纳入上线步骤。这样遇到新的404时，就能先判断是单个地址问题，还是某一层配置整体失效，再采取针对性的修复措施。

校对：方保僑