404错误排查：日志中应该核对哪些字段 - 先看这五个字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0eec731ae8c4.html
📄
404错误排查：日志中应该核对哪些字段 - 先看这五个字段
排查404错误时，日志里最该先核对的字段是：请求路径、状态码、Referer、User-Agent、时间戳。这五个字段能回答三个关键问题：哪个URL返回了404、请求从哪里来、请求者是谁。时间人手有限时，优先看状态码确认是不是404，再看请求路径确认具体是哪个地址，然后用Referer判断是自己站内链接写错还是外部链接失效，最后用User-Agent区分真实用户和爬虫。五个字段一起看，基本能定位大部分404的来源。
状态码字段：先确认这是不是真的404
日志中的状态码字段通常写作 status、status_code 或 sc-status，不同服务器格式不同。核对时注意两点：
- 404 和 410 都表示资源不可用，但410是明确告知已永久删除，处理方式不同。
- 有些日志会把 404 记录在单独的错误日志里，访问日志中可能看不到，需要两个文件都查。
- 如果状态码是 200 但页面内容是404提示，说明服务器返回了软404，这类问题在日志里看不出来，需要另外核对页面实际内容。
判断结果：如果状态码字段确实是404，继续往下看请求路径。如果状态码不是404，说明问题不在这个字段，需要换方向排查。
请求路径字段：确认到底是哪个URL出错
请求路径字段一般写作 request、request_uri 或 cs-uri-stem。核对时重点看：
- 路径是否带参数。带参数的URL（如
?id=123）和不带参数的URL，在日志里是两条不同记录。 - 路径大小写是否一致。部分服务器区分大小写，
/Page和/page可能一个正常一个404。 - 路径是否带尾部斜杠。
/about和/about/在部分配置下会返回不同结果。 - 路径中是否有多余字符，比如空格被编码成
%20、中文被编码成百分号形式。
判断结果：如果同一路径反复出现404，说明有固定来源在持续请求这个地址，需要找到来源并修正。如果路径只出现一次，可能是偶然的失效外链，优先级可以放低。
Referer字段：判断请求从哪里来
Referer字段记录请求的来源页面。核对时按以下情况分类：
- Referer为空：可能是用户直接输入网址、从书签打开，也可能是爬虫请求，还可能是浏览器隐私设置屏蔽了来源信息。
- Referer是站内地址：说明自己网站上有链接指向了一个不存在的页面，属于站内链接错误，应该优先修复。
- Referer是外部域名：说明别的网站链接到了你的失效页面，可以考虑做重定向或联系对方更新链接。
判断结果：站内来源的404优先级最高，因为影响的是自己用户的浏览体验。外部来源的404可以排后处理。Referer为空时，需要结合User-Agent进一步判断。
User-Agent字段：区分用户和爬虫
User-Agent字段记录请求者的身份信息。核对时注意：
- 包含
Googlebot、Bingbot等字样的是搜索引擎爬虫。爬虫频繁请求404地址，说明有失效链接被持续抓取。 - 包含
curl、python、wget等字样的是脚本或监控工具，可能是自动化任务在请求旧地址。 - 普通浏览器标识说明是真实用户，这类404直接影响用户体验，应优先处理。
判断结果：真实用户的404优先修复，爬虫的404次之，脚本的404再次之。注意User-Agent可以被伪造，不能仅凭这个字段断定请求者身份，需要结合其他字段综合判断。
时间戳字段：判断404是突发还是持续
时间戳字段记录请求发生的时刻。核对时看两个维度：
- 集中在一段时间内：可能是某次改版、迁移或删除操作导致的批量404，需要检查那次操作涉及了哪些URL。
- 分散在很长时间内：可能是长期存在的失效链接，一直没被处理，优先级取决于请求频率。
判断结果：突发型404通常影响面大，应该最先处理。持续型404如果请求量很低，可以排后。复查时对比处理前后的时间戳分布，确认404数量是否下降。
按优先级处理与复查
时间人手有限时，按以下顺序处理：
- 筛选状态码为404的记录。
- 按请求路径分组，统计每个路径的出现次数。
- 出现次数高的路径优先处理。
- 结合Referer判断来源，站内来源优先修复链接，外部来源考虑设置301重定向。
- 处理完成后，隔一段时间再查日志，确认该路径的404记录是否减少或消失。
复查时注意：如果404数量没有下降，可能是重定向配置未生效，或者有新的失效链接产生。如果404变成了301但目标页面又返回404，说明重定向指向了一个同样不存在的地址，需要检查重定向目标。
下一步：从日志中导出最近七天的404记录，按请求路径分组统计次数，先处理排名前十的路径，处理完后再对比下一周的日志确认效果。
