日志里的三类高频请求，正在悄悄推高你的带宽账单

网站没有改版，广告没有加码，流量曲线也没有出现肉眼可见的暴涨，但带宽账单就是比上个月高出一截。这是2026年不少站长正在经历的事。全球网页请求中非人类流量占比已经超过一半，Cloudflare Radar 2026年6月的数据是57.5%，Kinsta在自己的托管集群里测到典型一天约54%是自动化流量。但“一半以上是机器人”这个数字本身并不能解释账单为什么涨——真正被计费的不是请求数量，而是那些穿透了边缘缓存、一次又一次回到源站的请求。

访问日志里反复出现的高频请求，可以归成三类。它们看起来都是“有人在频繁访问”，但消耗带宽的机制和应对方式完全不同。

先理解一件事：带宽账单计的是回源，不是请求数

爬虫的请求分布是平的，访客是尖的

正常访客的访问集中在少数热门页面。首页、几篇主力文章、几个产品页，这些内容在CDN边缘节点是热的，缓存命中率高，源站几乎不需要出手。爬虫的行为逻辑不同：它按sitemap或链接图一路往下走，不挑热门还是冷门，三年没人点过的长尾页也会被翻出来。而长尾页在边缘通常没有缓存，每一次抓取都变成一次回源。

Kinsta 对超过5000个WordPress站点的分析进一步印证了这一点：AI爬虫77%到91%的请求指向动态内容或无法缓存的内容，而人类访客的这一比例只有约18%到19%。也就是说，即使两类请求的数量相同，爬虫对源站带宽的消耗也远高于人类。

回源才是账单上被计价的那一行

所以判断一笔带宽成本该不该花，不能只看“来了多少请求”，要看“有多少请求绕过了缓存、让源站真正传了字节”。日志里能用来看这件事的核心字段是 $body_bytes_sent，它记录的是响应体实际发送给客户端的字节数。下面三类请求，正是在这个字段上露出特征的。

第一类：AI爬虫对长尾页和参数化URL的“平推式”抓取

日志特征：UA集中，路径分散，单请求字节不大但总量惊人

这一类请求在日志里最直接的信号是 User-Agent。GPTBot、ClaudeBot、Bytespider、Meta-ExternalAgent 这些标识会反复出现，但它们的请求路径极其分散。一个内容站如果有五千个页面，一只爬虫完整走一轮，就是五千次回源。单看每一条日志，响应体可能只有几十KB，但乘上页面数和抓取轮次，带宽量级就上去了。

更隐蔽的一种模式是参数化URL的膨胀。一个带颜色、尺寸、排序、分页、库存筛选的产品页，在人类眼里是一个页面；爬虫可能把它识别成几十上百个独立URL，逐一抓取。日志里表现为同一路径基础下 ? 后参数组合大量重复，且全部命中动态渲染。

Kinsta的数据还显示，AI爬虫的带宽占比在不同站点之间差异极大：中位数站点只有1.57%，但第90百分位是17.8%，第99百分位达到90.3%。“平均AI爬虫占多少带宽”这个问题没有统一答案，只能在自己的日志里算。

低成本应对：先限速，不要急着封

对AI爬虫一刀切封禁的代价是，其中包含搜索引擎和正常索引流量。更稳的顺序是先用 Nginx 的 limit_req 对单IP做速率限制，让高频抓取在边缘或源站入口被降速，而不是直接返回403。有站长的做法是：识别不出来的高频访问直接限速而不是封，误伤更小。如果某只爬虫的UA明确且抓取量确实不带来任何回访，再针对UA做更精确的管控。

第二类：CC式请求对动态路径的集中打击

日志特征：QPS飙升但带宽不一定高，请求高度集中在“贵”的路径

CC攻击和爬虫的日志画像不同。爬虫是路径分散、总量大；CC攻击的请求往往高度集中，同一批IP反复砸向登录页、搜索接口、评论提交、AJAX端点这类需要执行PHP、查询数据库、处理会话的动态路径。这类请求的响应体通常不大，所以从 $body_bytes_sent 上看单次带宽消耗并不突出，但它消耗的是CPU和数据库连接，而且量大之后同样会把带宽和连接资源打满。

日志里还有一个辅助判据在连接层：如果 TIME_WAIT 状态的连接占比超过一半，说明大量连接建立后立即被丢弃，这是CC攻击比较典型的指纹之一。请求方法异常（大量PUT、DELETE）、UA高度重复但为空或伪装浏览器，也是常见信号。

低成本应对：先定位路径，再设阈值

CC攻击最忌讳的是发现被打就立刻升级配置，攻击者看到资源变大只会加大请求量。更有效的第一步是确认“打在了哪条路径上”，然后只对那条路径做限流。Nginx的 limit_req 可以按IP限制每秒请求数，阈值参考正常访客行为来定——一个人读完一个页面至少停留几秒，全站阈值设在每秒个位数到十几次通常已经足够宽松。如果请求来自代理池、单IP计数不可靠，则需要把限流下沉到路径级别，对登录、搜索这类高消耗接口单独设更紧的规则。

第三类：静态大文件被脚本批量拉取或盗链

日志特征：响应体字节数异常巨大，Referer缺失或来自陌生域名

这一类对带宽账单的打击最直接，因为单个请求的 $body_bytes_sent 就是MB甚至GB级别。视频、安装包、PDF、ISO镜像、高清图片，一个请求的字节数可能超过前面两类一整天的总和。日志里如果某个静态路径的累计字节数排在前列，同时请求来源的User-Agent是 python-requests、curl，或者Referer为空、来自与你的业务无关的第三方域名，基本可以判定为脚本批量拉取或盗链。

盗链的特殊之处在于：请求可能来自真实用户的浏览器，Referer里写的是别人的网站，但消耗的是你的带宽。阿里云侧的排查建议也指向同一组信号——同一IP大量请求图片资源，配合异常Referer，优先按盗链处理。

低成本应对：Referer校验 + 大文件独立限流

防盗链的常规做法是在Nginx里对静态资源目录配置 valid_referers，对空Referer和非法来源直接返回403。但要注意，Referer可以被脚本伪造，它防的是普通网页盗链，防不住蓄意爬取。更根本的缓解方式是把视频、安装包这类大文件从应用服务器上剥离出去，交给对象存储或CDN承载，让源站不再直接经手这些字节。如果暂时做不到迁移，至少对 mp4|zip|pdf|iso 这类后缀单独设 limit_conn 和 limit_req，限制单IP的并发下载数，避免一个脚本用多线程把带宽抽干。

防御的顺序比规则本身更重要

三类请求对应三种不同资源：AI爬虫消耗的是回源带宽和数据库连接，CC消耗的是计算和连接数，静态盗链消耗的是纯出网流量。把它们混在一起用同一条“封IP”规则处理，要么误伤，要么漏掉。

一个可操作的排查顺序是：先确认 log_format 里启用了 $body_bytes_sent，按URL聚合字节数排出带宽消耗的Top路径；再看这些路径的请求分布是分散还是集中——分散且UA指向爬虫的，走限速；集中且落在动态接口的，走路径级限流；单请求字节巨大且Referer异常的，走防盗链或卸载到CDN。日志分析的目的不是“找到坏人就封”，而是把每条高频请求归到它真正消耗的那类资源上，然后用最低误伤的方式把成本摁住。