结论:排查自定义404错误页是否生效、是否被误用,日志里最该先核对的是请求路径、状态码、来源页、User-Agent、请求时间、响应体积这六类字段。状态码决定这是不是404,请求路径决定用户或爬虫访问了什么,来源页和User-Agent帮助区分真实用户、站内死链和爬虫,响应体积与时间用于判断返回的是自定义页还是服务器默认错误页。
自定义404页面最容易出问题的地方,是页面看起来正常,但HTTP状态码返回了200或302。日志中应优先核对状态码字段,常见名称包括status、status_code、sc-status。判断标准是:真正的不存在资源应返回404;如果返回200,搜索引擎可能把它当作有效页面收录,用户也会误以为页面存在。
适用前提:你已经在服务器或CDN层配置了自定义错误页,并且日志能记录响应状态。若日志只记录访问量、不记录状态码,应先调整日志格式,再谈核对。
请求路径字段常见为request_uri、uri、path,查询字符串可能单独记为query_string或包含在完整URL中。核对时要区分:
/Page与/page结果不同。如果同一路径反复出现404,说明有稳定来源在引用它;如果大量随机路径出现404,可能是扫描或爬虫行为。判断结果不同,处理方式也不同:前者应修复链接或做重定向,后者可考虑限流或屏蔽,而不是改自定义页内容。
来源页字段常写作referer或referrer,User-Agent常写作user_agent。核对来源页可以判断用户是从站内哪个页面点进来的,从而定位站内死链;来源为空则可能是直接输入、书签或某些爬虫。
User-Agent用于区分浏览器、搜索引擎爬虫和脚本工具。注意:robots.txt的抓取限制不等于可靠的索引移除,日志里看到爬虫访问404也不代表该URL一定不会被索引。若你希望某类URL不被抓取,应结合状态码、页面内容和必要的移除手段分别核查,不能只靠日志字段下结论。
自定义404页通常有固定模板,响应体积会接近该模板大小。若日志中bytes或body_bytes_sent明显偏小,可能返回的是服务器默认错误页或空白页。核对方法:
curl -I请求一个确定不存在的路径,查看状态码和响应头;curl -s获取响应体,确认是否包含自定义页中的标题或标识文本;响应时间字段如request_time可用于发现自定义页是否拖慢错误响应。若404页面加载了数据库查询或远程请求,错误响应可能变慢,影响体验。适用条件是:自定义页应尽量静态化,不依赖会失败的后端逻辑。
假设你有一个已上线的站点,想验证自定义404页是否按预期工作,可以按以下步骤执行:
/this-page-should-not-exist-404;验收信号:状态码为404、响应体包含自定义页特征、来源页能正确记录站内跳转、响应体积稳定。若状态码为200或302,应先修服务器配置;若状态码正确但响应体是默认页,应检查错误页路径和服务器权限;若来源页为空但预期有站内跳转,应检查来源页字段是否被代理或浏览器策略过滤。
下一步:先固定一个测试路径,按上述步骤抓取一次日志记录,再决定是修状态码、修模板路径,还是处理站内死链。