Nginx访问日志中的Referer字段记录了当前请求的来源页面地址，它反映了用户从哪个页面跳转而来，也常被用于判断流量渠道、排查盗链以及分析爬虫行为。不过线上环境里Referer可能为空、可能是整个URL、可能来自搜索引擎的加密跳转，甚至被客户端篡改，因此不能简单地把原始字符串当作唯一依据。分析Referer来源需要从日志采集格式开始，结合命令行统计和业务策略逐层展开。
一、调整日志格式，完整保留Referer字段
Nginx默认的combined格式虽然已经包含$http_referer变量，但它的字段之间使用空格分隔，而请求行、User-Agent里本身也包含空格，直接用awk按空格切分很容易错位。建议在http块中自定义日志格式，采用竖线或其他不常出现在字段中的字符作为分隔符。例如：
log_format main '$remote_addr|$time_local|$request|$status|$body_bytes_sent|$http_referer|$http_user_agent'; access_log /var/log/nginx/access.log main;
这里把$http_referer放在第六个字段，后续统计时只要用awk -F'|' '{print $6}'就能准确提取，不会受空格干扰。需要注意的是，如果反向代理后面还有一层Nginx或负载均衡，单纯记录$http_referer可能会丢失真实客户端来源，此时建议同时记录$http_x_forwarded_for和$http_x_real_ip等头部信息。将这些字段一并写入日志，对后续安全分析和渠道归因都有帮助。
很多公司会对日志做切割和归档，同一套格式必须长期保持一致，否则历史数据无法和当前数据合并统计。上线新格式前，可以先在测试环境验证字段顺序和转义情况，尤其是User-Agent中可能含有竖线字符，这种情况虽然少见，但可以在写入前用正则替换或改用JSON格式规避。如果使用JSON格式，$http_referer会作为一个独立键值对保存，后端解析更可靠，但会略微增加日志体积。
二、用命令行快速统计Referer来源域名
有了带分隔符的日志后，最常见的需求是统计一天内哪些域名带来的访问量最高。可以使用下面这条命令：
cat access.log | awk -F'|' '{print $6}' | grep -v '^-$' | sed -E 's#^https?://##; s#/.*##' | sort | uniq -c | sort -rn | head -20
这条命令的流程是：先提取第六个字段，过滤掉空Referer标记-，然后去掉协议头和路径部分，只保留域名，最后排序去重并统计出现次数。得到的结果可以直观看出哪些搜索引擎、社交媒体或外部链接贡献了主要流量。如果只想统计某个具体搜索引擎来源，可以把sed步骤替换成grep 'baidu.com'或grep 'google.com'，再继续排序统计。
进一步分析时，不能只停留在域名粒度。比如来自百度搜索和百度图片的URL结构不同，来自微信的Referer可能是https://mp.weixin.qq.com或https://weixin110.qq.com，这些都可以通过统计完整路径来区分。需要查看具体来源页面时，可以保留URL中的路径和参数部分，统计出现次数最高的完整Referer字符串，这样能定位到具体哪个文章或活动页面带来了转化。在实际操作中，如果某条Referer字符串超长且包含大量无用参数，可以先截取问号之前的部分，避免参数差异造成统计碎片化。
对于日志量很大的站点，直接使用cat access.log会占用大量内存和IO，可以改用zcat处理压缩日志，或者只提取当天的文件。另外awk和sed的组合在小规模数据下完全够用，如果每天有上亿行日志，建议导入到ELK或ClickHouse中做聚合分析，命令行只适合快速排查和临时取数。
三、识别异常Referer并配置防盗链
Referer为空并不一定代表异常。用户通过地址栏直接输入网址、从HTTPS页面跳转到HTTP页面、某些移动端应用内嵌浏览器、隐私模式下访问，都会导致Referer为空。真正需要警惕的是：同一IP在短时间内产生大量空Referer请求，且User-Agent表现为脚本或爬虫；或者Referer字段是伪装成搜索引擎但域名拼写错误的字符串，例如ba1du.com或g00gle.com，这说明有人在伪造来源。
防盗链是最常见的基于Referer的安全策略。Nginx提供了valid_referers指令，可以定义哪些来源是合法的，不满足条件的请求会被标记为$invalid_referer。下面是一个保护图片和视频资源的配置示例：
location ~* \.(jpg|jpeg|png|gif|webp|svg|mp4|zip|rar)$ {
valid_referers none blocked server_names *.ipipp.com ~\.google\. ~\.baidu\.;
if ($invalid_referer) {
return 403;
}
}
这段配置允许直接访问（none）、被代理隐藏的Referer（blocked）、同域名来源（server_names）、以及*.ipipp.com、谷歌和百度的来源。命中其他来源时返回403。需要说明的是，valid_referers中的字符串默认是前缀匹配，使用~开头才表示正则匹配，正则里的点号必须用反斜杠转义，否则会匹配任意字符，造成防护形同虚设。
不过防盗链不能过度依赖Referer，因为客户端可以完全自定义这个字段。对于关键资源下载、支付回调、接口防刷等场景，必须配合签名、token、IP限制、频率控制等手段。日志分析的价值在于事后追溯，例如发现某个第三方网站大量盗用图片，可以通过日志中的Referer统计出其域名和请求路径，然后将其加入黑名单或者联系对方处理。
四、建立可持续的Referer分析流程
临时做一两次统计只能解决眼前的排查需求，要让Referer数据持续产生价值，需要把分析流程固化下来。可以每天定时跑一个脚本，统计前一天的来源域名TOP50，并将结果发送到运维群或写入数据库。脚本中应同时记录空Referer占比、异常域名列表、以及按IP聚合的请求次数，当某个来源的流量突然暴涨时能够及时告警。
如果站点规模较大，建议直接将Nginx日志输出到ELK或Kafka，在Logstash中解析Referer字段并写入Elasticsearch。这样运营人员可以在Kibana中按时间、渠道、落地页维度筛选来源分布，开发人员也能通过查询接口定位某个用户的完整访问路径。无论采用脚本还是平台方案，核心都是先把日志格式规范好，字段清晰了，后续分析才能顺利展开。