📍 WDQWDWQD987AAAAA:216.73.216.91
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /53fe54d82fce.html
📄

404 not found是什么意思：日志中应该核对哪些字段

404 not found 的意思是服务器收到了请求，但找不到对应资源，于是返回 HTTP 状态码 404。排查时，日志里最该先核对的是：请求时间、请求方法、请求 URI、状态码、Referer、User-Agent、响应大小、上游处理结果。这些字段能帮助判断是链接写错、资源被删、路径规则不匹配，还是爬虫或用户访问了旧地址。

先核对请求行：方法、URI、协议版本

请求行通常包含请求方法、请求 URI 和 HTTP 版本。要查的是：请求方法是否为 GET 或 HEAD，URI 是否与预期一致，是否带上了多余斜杠、大小写差异、URL 编码字符或查询参数。例如日志中出现 /images/Logo.png，而服务器文件实际是 /images/logo.png，在区分大小写的系统上就会返回 404。若 URI 里出现 %20、%2F 等编码，还要核对解码后路径是否真实存在。结果说明：URI 与文件或路由不匹配时，优先修链接或补重定向；若 URI 正确却仍 404，再查服务器配置和上游应用。

核对状态码与响应大小，区分真 404 和伪 404

状态码字段应直接显示 404。但有些站点会把不存在的页面返回 200，再在页面里写“未找到”，这叫软 404，日志状态码不会显示 404。要查的是：状态码是否为 404，响应大小是否异常小或接近模板页大小。若状态码是 200 但响应大小与正常页面差异很大，可能是软 404。结果说明：真 404 可直接按路径缺失处理；软 404 需要改应用返回正确状态码，否则搜索引擎和监控工具难以识别。

核对 Referer 和 User-Agent，判断来源与访问者类型

Referer 表示请求从哪个页面跳转而来，User-Agent 表示客户端类型。要查的是：Referer 是否来自站内旧链接、外部合作方、广告落地页或用户书签；User-Agent 是常见浏览器、搜索引擎爬虫还是脚本工具。若大量 404 的 Referer 集中在同一个旧页面，说明该页有失效链接；若 User-Agent 是爬虫且 URI 集中在旧栏目，说明需要检查站点地图和历史链接。结果说明：站内来源优先修链接，外部来源可评估是否做 301 重定向，爬虫来源则结合 robots.txt 和站点地图分别核查。注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。

核对时间与频次，定位突发还是长期问题

时间字段要精确到分钟或秒，并确认时区。要查的是：404 是集中在某次发布之后，还是长期均匀出现；同一 URI 是单次出现还是高频重复。例如假设某次改版后，日志中 /old-page 在十分钟内出现 300 次，且 Referer 都来自首页，这就可能是首页仍有旧链接。结果说明：突发集中通常与发布、改版、配置变更相关；长期高频可能是外部死链或爬虫持续抓取旧地址。此时应导出对应 URI 列表，按频次排序处理。

可执行核对清单

1. 查请求 URI：复制完整路径，在浏览器或无痕窗口直接访问，确认是否 404。结果说明路径本身是否可达。
2. 查请求方法：确认是 GET、HEAD 还是 POST。结果说明是否因方法不被路由支持而返回 404。
3. 查状态码：确认日志状态码为 404，并对比响应大小。结果说明是真 404 还是软 404。
4. 查 Referer：统计来源页面，找出站内失效链接。结果说明应修链接还是做重定向。
5. 查 User-Agent：区分用户、爬虫和脚本。结果说明处理优先级和影响范围。
6. 查时间分布：按小时或分钟聚合，关联发布记录。结果说明是否由近期变更引起。
7. 查服务器与上游日志：若前端日志只有 404，继续看应用日志或反向代理日志。结果说明是文件缺失、路由未注册还是上游超时被误判。

下一步：从日志中导出最近 24 小时内状态码为 404 的 URI 列表，按访问次数从高到低排序，先处理前 20 条，并逐条确认是补文件、修链接还是设置 301 重定向。