网站日志如何识别异常爬虫与高频访问来源?

网站日志里躺着的每一行记录，都是某个客户端对服务器说过的一句话。问题在于，这些话里绝大部分来自机器而非真人。一个正常运营的企业站，真实用户的请求往往只占日志总量的两三成，其余全是搜索引擎抓取、监控探针、SEO工具扫描、内容采集脚本，以及各种不知道从哪个角落冒出来的自动化程序。把这些机器流量一概当成“爬虫”去封，会误伤搜索引擎;一概放行，服务器资源又会被无声地消耗掉。识别异常爬虫和恶意高频来源，核心不在于找到一个万能规则，而在于建立一套从日志里读出“谁在干什么”的习惯，再根据行为特征做出分级判断。

先看请求量分布，但别只看请求量

最直觉的切入点是统计高频IP。一条常用的命令就能列出访问次数最多的来源：awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20。这条命令本身没问题，但它给出的结果需要放在上下文中解读。一个IP访问了八百次，可能是攻击者在扫描，也可能是某个企业客户的内网出口在正常使用你的服务，还可能是某个CDN节点在回源。单看次数就封禁，误判的概率不低。

更有价值的信号是请求量和状态码的组合。扫描器在探测后台路径或漏洞时，会产生大量404响应。执行 awk '$9 ~ /^(404|500)$/ {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 可以筛出那些触发大量错误的来源。一个正常访客不会在短时间内制造几十个404，而一个正在穷举 /wp-admin、/.env、/phpmyadmin 的脚本会。另一个值得看的维度是请求的均匀程度。自动化脚本的请求间隔往往高度一致，而真人用户的点击是离散的、带停顿的。如果日志里开启了 $request_time 字段，还可以观察那些“高频且极快”的请求：响应时间短于零点零五秒却每秒发起几十次的来源，大概率不是人在操作。

User-Agent能看出不少东西，但别全信

User-Agent字段是日志里最直观的身份标签，也是最容易被伪造的一层外衣。统计UA分布的命令和统计IP类似：tail -n 10000 /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20。如果某个UA的请求占比超过两成，而且对应的来源IP高度分散，基本可以判定是分布式采集行为。这类UA通常带着明显的工具特征，比如 python-requests、Scrapy、Go-http-client、SemrushBot、AhrefsBot 等，在Nginx层用 map 指令集中匹配并返回403或444，是最干净的拦截方式。

但UA的陷阱在于，它可以随便写。一个采集脚本把UA改成 Mozilla/5.0 开头的浏览器标识，从字符串上就看不出来了。更隐蔽的做法是伪装成搜索引擎爬虫。Googlebot的UA谁都可以填，但真正的Googlebot来自Google控制的IP段。验证方式是反向DNS查询来源IP是否属于官方网段，而不是看UA字符串长得像不像。如果日志里出现大量声称自己是Googlebot但反向解析对不上的请求，这批IP就是冒牌货，拦截时不需要犹豫。

行为模式比身份标签更可靠

当UA被伪装、IP被轮换之后，剩下的判断依据只有行为本身。这里有几个在日志里可以直接观察的维度。第一是路径分布。真实用户访问的页面通常集中在首页、栏目页、文章页这些入口，深度有限。而一个采集脚本或者扫描器会尝试访问大量深层页面、参数化URL、甚至根本不存在的路径。如果某个IP在短时间内请求了数百个不同的文档页，且Referer为空或固定不变，这个模式本身就很说明问题。第二是Cookie和会话的稳定性。正常浏览器会携带会话Cookie，在多次请求之间保持一定的连续性。自动化脚本往往不处理Cookie，或者每次请求都换一个，日志里表现为同一IP的请求之间缺乏会话关联。

有一个内容站的真实案例值得参考。该站日志里出现了一个IP，请求量并不算特别高，每小时两百次左右，但它的访问路径覆盖了站点过去三年发布的几乎所有文章，且请求间隔精确到毫秒级地均匀。它没有触发任何频率限制，UA伪装成了Chrome，但它访问了正常用户根本不会打开的第47页归档、已经删除但URL仍返回301的旧链接、以及只有通过站内搜索才能到达的参数页面。这种“穷举式”的路径覆盖，比高频请求更能暴露采集意图。后来在Nginx层面对这个IP的路径模式做了拦截，服务器负载没有明显变化，但数据库查询量下降了一截，因为那些深层页面原本每次都要走完整的动态渲染。

把识别结果转化成可执行的分级策略

日志分析的目的不是生成一份报告，而是产出可以落地的处置规则。比较务实的做法是把识别出的来源分成三档。第一档是确认的搜索引擎爬虫，经过反向DNS验证的Googlebot、Bingbot、Baiduspider，不仅放行，还应该在日志里单独标记，方便后续观察它们的抓取频次是否合理。第二档是已知的低价值自动化来源，UA命中工具特征的、高频触发404的、路径穷举的，直接用Nginx的 limit_req 限速或者返回444关闭连接。第三档是灰色地带，请求量偏高但行为特征不明显，先不封禁，加上频率上限观察几天，如果持续触发限流再升级处理。

需要留意的细节是CDN和反向代理带来的IP失真。如果站点前面有Cloudflare或者负载均衡，日志里 $remote_addr 记录的是代理节点的IP，直接按这个IP封禁会误伤所有经过该节点的正常用户。这时需要检查 X-Forwarded-For 头，并在Nginx中配置 set_real_ip_from 信任代理网段，确保日志记录的是真实客户端地址。另外，限流触发时返回429而不是503，避免被CDN缓存成错误页影响真实访客。

总结来说，日志识别的价值在于把“感觉服务器变慢了”变成“知道是哪一类流量在消耗资源”。高频统计给出线索，状态码和路径分布提供行为证据，UA和反向DNS用于区分真假搜索引擎，最后把判断结果落到Nginx的分级规则上。不需要一上来就追求完美的识别率，先处理那些特征最明显、证据最充分的来源，观察一周日志的变化，再逐步收紧策略。这套流程跑顺之后，日志就不再是出事后才翻的流水账，而是一面能提前看到异常的镜子。

纵横云服务器租赁，欢迎随时联系，客服联系方式：QQ3494196421，手机微信19906048601。