小站遭AI爬虫围剿：不到100张图片却被抓取266k次

一个荒诞的数字对比

一位 Reddit 用户分享了一个令人啼笑皆非的观察：他运营着一个规模极小的德语 Piwigo 相册站点，托管的图片不到 100 张，内容对任何搜索引擎而言都谈不上有多少价值。然而在过去 24 小时内，这个站点收到了来自德国的 685 次正常请求，却同时被来自美国的 266000 次爬虫请求淹没。

换算下来，真正的人类访问只占总流量的 0.26%，剩下 99.7% 全部是自动化爬虫。而根据 User-Agent 标识，其中约 95% 来自 Meta 的网页索引机器人。一个不足百张图片的个人小站，为何会成为科技巨头爬虫的重点关照对象？这背后折射出的，是当前 AI 数据抓取生态的失控状态。

为什么 Piwigo 会成为"爬虫陷阱"

发帖者用了一个很形象的说法——Piwigo 是一个 bot trap（机器人陷阱）。这并非 Piwigo 本身设计上的问题，而是相册类 CMS 的结构特性使然。

Piwigo 是一款始于2002年的开源自托管相册管理系统，前身为 PhpWebGallery，采用 PHP + MySQL 技术栈构建。它允许用户在自己的服务器上搭建完整的图片管理平台，支持批量上传、多级相册分类、标签管理、多种缩略图尺寸自动生成、用户权限控制等功能。与 Google Photos 或 Flickr 等商业服务不同，Piwigo 的核心卖点在于数据完全自主可控，因此在隐私意识较强的欧洲用户和摄影爱好者群体中拥有稳定的用户基础。

组合爆炸式的 URL 空间

Piwigo 作为一款开源相册管理系统，会为每张图片、每个相册、每种排序方式、每个标签组合、每种尺寸缩略图生成独立的 URL。对于一个只有几十张图片的站点来说，这些维度相互交叉，可以轻松衍生出成千上万个可访问的页面路径。

这里涉及计算机科学中的一个经典概念——组合爆炸（Combinatorial Explosion）。当多个独立维度相互叠加时，可能的组合数量会以指数级速度增长。以一个具体的 Piwigo 站点为例，假设有5个相册、50张图片、4种排序方式（按日期、名称、评分、随机）、3种显示模式（缩略图、列表、地图）、10个标签，那么理论上的 URL 组合就可以达到数百个目录级页面，每个页面又链接到各图片的不同尺寸版本。加上分页参数、语言切换等维度，可访问的 URL 总数远远超出站点的真实内容量。

对人类用户而言，这些页面大多是重复或无意义的；但对一个只知道"沿着链接不断深入"的爬虫来说，它看到的是一个近乎无限的链接迷宫。爬虫会一层层展开这些组合页面，每发现一个新链接就加入待抓取队列，导致抓取次数呈几何级数增长——这正是"陷阱"一词的由来。发帖者提到，他那些内容多得多的其他站点反而没有这个问题，恰恰说明问题不在于内容量，而在于 URL 的组合结构。

爬虫缺乏基本的收益判断

更值得玩味的是发帖者的调侃："看它们如此浪费资源真是太搞笑了。"一个理性的抓取系统本应对低价值站点降低抓取频率，但 Meta 的索引机器人显然没有做这种判断，而是机械地把整个 URL 空间反复扫了一遍又一遍。这暴露出当前大规模爬虫在抓取调度与去重策略上的粗放。

AI 数据抓取的"军备竞赛"背景

这个个案并非孤例，而是过去两年 AI 训练数据抓取狂潮的一个缩影。随着大模型对训练语料的需求急剧膨胀，各大科技公司的爬虫开始以前所未有的强度扫荡整个互联网。

许多开源项目和独立站长都反映，来自 GPTBot、ClaudeBot、Meta 爬虫等 AI 相关 User-Agent 的流量在急剧上升，部分站点的爬虫流量甚至已经超过真实用户流量数十倍。对于依赖捐赠或个人维护的小型服务而言，这种"无差别扫荡"带来的不仅是带宽浪费，还可能拖垮服务器、抬高托管成本。

有意思的是，本例中被点名的主要是 Meta 的网页索引机器人，其身份界定介于传统搜索索引与 AI 训练数据采集之间。Meta 运营着多个不同用途的网络爬虫，本例中被大量识别到的爬虫 User-Agent 很可能是 meta-externalagent，这是 Meta 近年来新部署的抓取工具，其用途在官方文档中被描述为"帮助构建 AI 产品的数据采集"，但具体边界并不透明。与传统搜索引擎爬虫不同的是，搜索引擎的抓取至少会通过搜索结果页回馈流量给被抓取站点，形成某种互惠关系；而 AI 训练用途的爬虫则是纯粹的单向数据提取——抓取方获得训练数据，被抓取方除了承担服务器负载外一无所得。这种不对称关系，正是当前围绕 AI 爬虫争议的核心所在。

廉价 VPS 意外扛住了26万次请求

整件事中有一个反差极大的细节：承载这些请求的，只是一台每月 6 欧元的廉价 VPS。面对每天 26 万次的爬虫请求，这台小机器居然毫无压力，以至于站长自己一开始都没察觉异常，是事后翻日志才发现的。

这个结果在技术上并不意外。现代廉价 VPS（Virtual Private Server，虚拟专用服务器）即便是入门级配置（通常为1-2核 CPU、1-2GB 内存），在处理静态资源请求时也具备相当可观的吞吐能力。静态文件（如图片、CSS、预渲染HTML）的响应路径极短：Web 服务器（如 Nginx）直接从磁盘或内存缓存中读取文件并返回，无需调用数据库或执行应用逻辑。Nginx 在处理静态文件时可以轻松达到每秒数千甚至上万次请求的处理能力。而本例中26万次日请求平均下来，每秒仅约3次请求，对于静态内容服务来说根本不算负载。

这从侧面说明了两点：

• Piwigo 与现代 VPS 的性能冗余足以应对相当规模的请求，静态图片和缓存页面的响应成本很低；
• 也正因为"扛得住"，很多小站长可能根本意识不到自己正在被爬虫反复扫刷，直到某天带宽账单或日志暴露真相。

换句话说，这次是运气好——遇上的是抓取内容有限的图片站。如果是数据库密集型的动态应用（如 WordPress 文章页面，每次请求都需要执行 PHP 代码、查询 MySQL 数据库、渲染模板，单次请求的资源消耗可能是静态文件的50-100倍），同样强度的抓取很可能早已让服务瘫痪。

站长如何应对AI爬虫：拦截与防御手段

发帖者提到一个令人无奈的现实：他尝试用 Cloudflare 的 AI Crawl Control 来拦截，结果这个工具的列表里甚至没有列出 Meta 的这个爬虫。这说明现有的商业化防爬工具在覆盖面上仍有明显滞后。

对于面临类似困境的站长，可以考虑以下几种组合手段：

1. robots.txt 屏蔽AI爬虫（治标）

针对已知的 AI 爬虫 User-Agent（如 meta-externalagent、GPTBot、ClaudeBot 等）在 robots.txt 中显式禁止。

robots.txt 是1994年由 Martijn Koster 提出的爬虫排除标准（Robots Exclusion Protocol），以纯文本文件的形式放置在网站根目录下，告知爬虫哪些路径可以抓取、哪些应该回避。然而，这个协议完全基于"君子协定"——它只是一个建议，没有任何技术强制力。传统的搜索引擎爬虫通常会遵守 robots.txt 的指令，因为违规可能导致法律风险和声誉损失。但随着 AI 爬虫生态的爆发，越来越多的抓取工具选择性地忽视 robots.txt，或者频繁更换 User-Agent 以规避屏蔽规则。因此，robots.txt 只对遵守规则的爬虫有效，无法阻止无视协议的抓取。

2. 服务器层 / WAF 拦截（治本）

通过 Nginx/Apache 的 User-Agent 匹配规则，或 Cloudflare 的自定义防火墙规则，直接对匹配的爬虫返回 403。这比 robots.txt 更硬核，因为它在请求层面就切断了访问——爬虫发出的 HTTP 请求在到达应用程序之前就被 Web 服务器或防火墙拦截并拒绝，从而将资源消耗降到最低。

3. 收敛 URL 空间减少爬虫入口

针对 Piwigo 这类"陷阱型"应用，从根源上限制爬虫能触达的组合页面，例如为多余的排序、过滤参数页面添加 noindex meta 标签（指示搜索引擎不要索引特定页面），或用 canonical 标签合并等价 URL。

Canonical 标签（rel="canonical"）是 HTML 中用于解决重复内容问题的标准化机制，由 Google、Yahoo 和 Microsoft 在2009年联合推出。当同一内容可以通过多个不同 URL 访问时（例如带有不同排序参数或会话ID的页面），canonical 标签会告诉搜索引擎哪个 URL 才是"权威版本"，从而避免爬虫将这些重复页面视为独立内容进行逐一抓取。通过合理使用这些标签，可以有效缩小可被无限展开的链接迷宫。但需要注意的是，canonical 标签同样属于建议性指令，行为良好的爬虫会尊重它，而激进的 AI 数据采集爬虫可能完全无视这些 HTML 层面的信号。

4. 设置速率限制

对单一来源 IP 段设置请求频率上限（Rate Limiting），即便无法完全屏蔽，也能将资源消耗控制在可接受范围内。常见的实现方式包括 Nginx 的 limit_req 模块、Cloudflare 的 Rate Limiting 规则，或使用 fail2ban 等工具根据日志模式自动封禁异常 IP。对于大型科技公司的爬虫，其出口 IP 段通常可以通过 ASN（自治系统号）查询来批量识别，从而实现更精准的限速策略。

结语：独立站长面对AI爬虫的新挑战

这个略显滑稽的案例，实际上提出了一个严肃的问题：在 AI 数据抓取失控的今天，互联网基础设施的成本正在被单方面转嫁给内容托管方。一个不到百张图片的个人小站，都能每天承受 26 万次爬虫扫刷，那些体量更大的公共资源、开源项目和文档站，面对的压力可想而知。

幸运的是，本例中廉价 VPS 的从容表现说明问题目前尚在可控范围内。但随着 AI 爬虫的强度持续攀升，如何在"开放共享"与"防止资源被无节制榨取"之间取得平衡，将成为每一位独立站长都无法回避的课题。围绕 robots.txt 对 AI 爬虫是否具有法律约束力的讨论已在多个司法管辖区升温，但目前尚未形成统一的法律共识。在法律框架明确之前，技术层面的主动防御仍然是站长们最可靠的自我保护手段。

核心要点