通过配置 Nginx 自定义日志格式记录 $http_referer 和 $status,可精准追踪 404 请求来源;需显式启用 referer 字段,用 awk 等工具过滤空值及本站域名后分析高频 referer,并结合业务识别搜索引擎、第三方平台、App WebView 等典型异常模式,进阶可接入 ELK 或 Prometheus 实现实时监控与告警。
直接用 $http_referer 配合 Nginx 日志格式,就能把 404 请求的“从哪点过来的”记录清楚,关键在日志字段设计和后续分析逻辑。
Nginx 默认 access_log 不强制记录 $http_referer,需显式配置。推荐在 http 或 server 块中定义带 referer 的日志格式:
log_format referer_404 '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';
access_log /var/log/nginx/404-referer.log referer_404;
$http_referer 是客户端发来的原始 Referer 头,可能为空(如直接输入 URL、HTTPS→HTTP 跳转、隐私策略屏蔽),日志中会显示 -,需在分析时过滤或标注。假设日志已持续记录,可对 404-referer.log 执行单行分析,聚焦真实有效的上游来源:
awk '$9 == 404 && $7 != "-" && $7 !~ /^https?://[^/]*.yourdomain.com// {print $7}' /var/log/nginx/404-referer.log | sort | uniq -c | sort -nr | head -20
$9 对应 status 字段(取决于 log_format 中字段顺序,请按实际调整索引),$7 是 referer;正则排除本站子域可减少噪音;head -20 输出前 20 个高频来源。awk '$9 == 404 && $7 != "-" {print $7, $3}' ... | sort | uniq -c | sort -nr($3 是 request,如 "GET /old-page.html HTTP/1.1",可进一步用 awk '{print $2}' 提取路径)高频 referer 并不都代表“有效入口”,需结合业务判断是否属于问题源头:
google.com/url?、baidu.com/link? —— 说明旧页面被收录未更新,需提交死链或设置 301notion.site、wordpress.com、medium.com —— 检查这些平台内嵌链接是否指向已下线资源myapp://page?id=123)或空白 —— 需与客户端团队协同修复跳转逻辑https://yoursite.com/blog/ → 404 /2023/post-abc.html,说明栏目页未同步更新归档逻辑当 404 量级上升或需长期追踪趋势时,静态日志分析效率下降,建议引入轻量可观测链路:
status == 404 AND http_referer != "-",解析 referer 域名、路径、来源页面关键词,写入 Elasticsearchnginx_http_requests_total{status="404"} 指标做总量预警,再结合日志下钻分析 referer 细节