“404 not found”表示服务器收到了请求,但找不到对应的资源。它本身不是“网站坏了”,而是“这个地址没有可返回的内容”。当同一站点上有的页面正常、有的页面 404,且你并没有删除过这些页面时,最常见的原因不是内容消失,而是多条配置互相冲突:重写规则、大小写、尾斜杠、反向代理、缓存或路由规则各自给出不同答案。下面是一份按优先级排列的排查清单,适合时间和人手有限时先做最可能见效的几项。
要查什么:出问题 URL 的 HTTP 状态码、响应来源、请求路径原文。
怎么查:在服务器访问日志中搜索该路径,或在浏览器开发者工具的“网络”面板查看该请求的状态码和响应头。重点看 Server、X-Powered-By、Via 等响应头。
结果说明什么:如果 404 来自反向代理或 CDN 节点,而不是应用服务器,说明冲突发生在转发层;如果应用日志里根本没有这条请求,说明请求在到达应用前就被拦截或改写了。这一步决定后面查哪一层,不要跳过。
要查什么:Web 服务器重写规则、应用路由、框架中间件三处是否对同一路径做了不同处理。
怎么查:把出问题 URL 和正常 URL 并排列出,逐条对照规则。常见冲突形态包括:一条规则把 /a 重写到 /b,另一条又把 /b 重写回 /a;或者伪静态规则把带参数的地址改成了不存在的文件路径。
结果说明什么:如果关闭其中一条规则后 404 消失,冲突点就定位到了。适用条件是你能在测试环境复现;如果只有生产环境出问题,先导出规则做静态比对,不要直接在生产上反复改。
要查什么:请求路径与真实资源路径是否只在大小写、结尾斜杠、URL 编码上不同。
怎么查:把浏览器地址栏里的路径复制出来,与服务器上实际文件名或路由定义逐字符比较。注意 %20 与空格、%2F 与斜杠、中文路径的编码形式。
结果说明什么:Linux 服务器区分大小写,/About 和 /about 可能是两个结果;有的框架把 /page 和 /page/ 视为不同路由。如果只有其中一种写法 404,说明是规范化规则缺失或不一致,而不是内容丢失。
要查什么:robots.txt 中的 Disallow 规则、站点地图里列出的 URL 是否与实际可访问地址一致。
怎么查:直接请求 /robots.txt 和站点地图文件,把其中列出的 URL 抽样访问。注意 robots.txt 的抓取限制不等于可靠的索引移除:被禁止抓取的页面仍可能因外部链接出现在结果中,而真正返回 404 的页面才可能随时间从索引中减少。站点地图也不保证收录,它只是提交候选地址。
结果说明什么:如果站点地图里的地址本身返回 404,说明生成逻辑与路由规则脱节;如果 robots.txt 屏蔽了本应可访问的目录,先判断这是有意限制还是配置遗留,再决定是否调整。
要查什么:哪一处改动能让 404 消失,且不影响其他正常页面。
怎么查:按以下顺序执行,每步只改一处并立即复测:
结果说明什么:如果改一处就恢复,说明是单点配置错误;如果多处都需调整才恢复,说明存在配置叠加,应把规则收敛到一处维护。适用条件是你能控制服务器或应用配置;如果站点托管在第三方平台,只能核对平台提供的重定向与路由设置,无法直接修改底层规则时,应把可复现的 URL 和现象整理后提交给平台支持。
下一步:先取出一个 404 URL 和一个正常 URL,按上面的顺序做一次对照记录。只要两层配置对同一路径给出不同答案,冲突就已经暴露出来了。