404错误排查：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /75b8fa9963f2.html
📄
404错误排查：怎样取得可复查的状态证据
要取得可复查的404状态证据，核心是让每一次请求都留下可被第三方重复验证的记录：记录请求URL、请求时间、响应状态码、响应头中的关键字段，以及请求所经过的链路。只截图浏览器页面不够，因为页面显示与HTTP状态码可能不一致；只凭监控告警也不够，因为告警可能被重试或缓存干扰。可复查意味着换一个人、换一台机器、换一个时间点，按同样的方法能得到可解释的结果。
准备：先固定请求对象和观察工具
开始排查前，先把“哪个URL返回404”写清楚。要区分几种容易混淆的对象：
- 用户实际访问的完整URL，包含协议、主机名、路径和查询串。
- 服务器内部重写或跳转后的目标URL。
- 站点地图、内链或外链中引用的URL。
- 带与不带末尾斜杠、带与不带大小写差异的变体。
工具方面，命令行工具适合留下文本证据，浏览器开发者工具适合观察单次请求，服务端访问日志适合观察真实流量。三者记录的不是同一件事，应分别保存。命令行请求可以用curl -I只取响应头，也可以用curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n"输出状态码和跳转目标。若需要保存完整响应头，把输出重定向到文件，例如curl -I https://example.com/path > headers.txt。这些命令只是示例，实际域名和路径要替换成待查对象。
实施：一次请求要记录哪些字段
最关键的一步是：对同一个URL连续请求多次，并把每次的完整响应头和时间戳写入同一个文件。可复查的证据至少包含以下内容：
- 请求发出的UTC时间，精确到秒。
- 请求方法与完整URL。
- 响应状态码，例如404、410、301、302、200。
- 响应头中的
Location、Cache-Control、Content-Type、Server、Date等字段。 - 请求时使用的User-Agent，以及是否携带Cookie或认证信息。
- 请求出口IP或所在网络环境，用于判断是否命中CDN节点或地区缓存。
如果只记录“我看到404”，无法判断是源站返回、CDN返回、还是应用层自定义错误页。把响应头保存下来，才能区分这几种情况。例如响应头里出现Server: nginx且没有应用框架特征，可能指向Web服务器直接返回；若响应头带有应用框架的会话标识，则可能由应用路由产生。这里说的是“可能原因”，不是已经定位的原因，需要结合日志继续确认。
验证：用不同路径和不同节点交叉比对
单次请求的结果不能直接当作结论。可复查的验证至少做三组对比：
- 同一URL从不同网络请求，观察状态码是否一致。
- 同一URL带查询串与不带查询串请求，观察是否只有一种变体返回404。
- 同一URL请求两次，观察第二次是否被缓存改变结果。
如果不同节点结果不同，说明缓存或分发层参与了响应，需要进一步查看CDN或反向代理的缓存键与回源日志。如果只有带查询串的变体返回404，问题可能在应用路由或参数处理，而不在静态文件是否存在。如果两次请求结果不同，先检查Cache-Control和Age，再检查是否有发布、重启或配置变更发生在两次请求之间。
还要把HTTP状态码与实际页面内容分开看。有些站点对不存在的路径返回200并展示“页面不存在”的提示，这种情况对用户是404体验，对爬虫和监控却是200。反之，有些错误页返回404但页面内容正常。判断应以响应状态码为准，同时记录页面标题或关键内容作为辅助。
维护：把证据变成可重复的检查项
排查结束后，把这次使用的URL、命令、时间点和结论整理成一条检查项，放进日常巡检。巡检不需要覆盖全站，可以只针对已知容易出问题的路径类型：栏目页、详情页、带参数的筛选页、旧链接跳转目标。每次巡检输出同样的字段，形成时间序列，才能看出404是偶发还是持续。
关于几个常见边界：robots.txt中的限制只影响抓取行为，不等于把已收录页面移除；站点地图提交不保证收录；HTTPS只表示传输加密，不保证站点没有漏洞，也不直接保证排名。这些判断需要分别核对，不能互相替代。
下一步，选一个你怀疑返回404的具体URL，用命令行请求两次并把完整响应头保存到文件，再与同时间的服务端访问日志比对。两份记录能对上，才算取得可复查的状态证据；对不上，就先查请求是否经过了缓存、代理或不同的主机名。
