404 not found 的意思是:服务器收到了请求,但找不到对应资源,因此返回 HTTP 状态码 404。要判断一个页面是否真的返回 404,不能只看浏览器页面上的文字,而应取得可复查的状态证据:记录请求 URL、响应状态码、响应头、请求时间和使用的工具。这样做的价值在于,证据可以交给他人复核,也能在排查误报时区分“页面确实不存在”和“页面存在但被错误拦截”。
可复查的状态证据,不是一句“我打开是 404”,而是一份最小记录。建议至少包含以下字段:
Content-Type、Location、X-Robots-Tag。如果只记录“页面显示未找到”,无法排除以下情况:服务器返回 200 但页面内容是错误提示;CDN 或安全策略返回 403;重定向链条最终落到 404。因此状态码和响应头比页面文案更关键。
下面给出一个可执行的最小步骤。假设要检查 https://example.com/missing-page,在终端执行:
curl -I -L -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/missing-page
参数含义:-I 只取响应头,-L 跟随重定向,-o /dev/null 丢弃正文,-w 输出最终状态码和生效 URL。判断结果时:
404:该请求最终返回未找到,可作为 404 状态证据。200:资源可访问,页面上的“404”可能是前端路由或内容错误,不是 HTTP 404。301 或 302:存在重定向,应继续查看 Location 指向哪里,再判断最终状态。403:请求被拒绝,不等于资源不存在,需要检查访问权限或防护规则。如果需要保留完整响应头,可执行:
curl -I -L https://example.com/missing-page
把输出复制到工单或文档中,并标注执行时间和网络环境。这样他人可以在相同条件下复现。
不习惯命令行时,可以用浏览器开发者工具的 Network 面板。操作步骤是:打开开发者工具,切换到 Network,勾选 Preserve log,刷新目标页面,点击第一条文档请求,查看 Status Code 和 Response Headers。需要记录的是:
Location 或 X-Robots-Tag。注意:浏览器可能使用缓存,状态码不一定反映服务器当前响应。可勾选 Disable cache 后重试,或换用无痕窗口。若页面由前端框架渲染,直接查看源代码可能看不到 404 文案,应以网络请求状态码为准。
看到 404 时,可能原因包括:URL 拼写错误、资源被删除、路径大小写不一致、服务器重写规则错误、反向代理配置不当、站点迁移后未设置重定向。上述每一项都只是可能原因,不能凭一个现象直接下结论。
要定位原因,可做对比检查:
判断结果时:如果源站返回 200 而 CDN 返回 404,问题更可能在 CDN 缓存或回源配置;如果源站和 CDN 都返回 404,问题更可能在应用路由或文件缺失。若返回 403 或 500,则不属于 404 问题,应另按权限或服务端错误排查。
可复查证据的验收标准是:另一个人仅凭记录就能复现相同状态码。为此,记录中应避免只写“我检查过了”,而应包含命令、输出、时间和环境。若涉及 robots.txt 或站点地图,要分清边界:robots.txt 的抓取限制不等于可靠的索引移除;站点地图不保证收录;HTTPS 不保证安全无漏洞或排名。这些工具不能替代 404 状态证据本身。
下一步:选一个你怀疑返回 404 的 URL,用上面的 curl 命令执行一次,把状态码、最终 URL 和响应头保存下来。若结果不是 404,再按 200、301、403、500 分别进入对应排查路径。