AI 爬虫暴力抓取导致 Gentoo Bugzilla 宕机，开源社区的耐力快到极限了

最近 Gentoo 社区把 Bugzilla 关停的消息在开发者圈子里引起了不小的讨论。这件事最讽刺的地方在于，一个以极致优化、追求对系统掌控力著称的发行版，其核心的 Bug 追踪系统竟然被 AI 爬虫给“刷”宕机了。这不仅仅是一个技术故障，更是目前大模型公司在数据采集逻辑上与开源社区之间的一次激烈碰撞。

很多不关注细节的人可能觉得，不就是多了一些流量吗？但在实际运维中，AI 爬虫的抓取逻辑与普通用户完全不同。它们追求的是全量、快速地索引所有页面，往往会忽略服务器的实时负载，甚至在后台疯狂并发。当成千上万个请求在极短时间内涌入 Bugzilla 这种基于数据库驱动的系统时，服务器的 CPU 和 IO 会迅速被榨干。结果就是，真正的开发者在尝试提交一个关键 Bug 或查看修复进度时，面对的是无尽的 504 Gateway Timeout 或者响应时间高达数秒的页面。

对于 Gentoo 这种由志愿者维护的项目来说，基础设施的资源是非常有限的。AI 公司在训练模型时，往往采取一种“先暴力抓取，至于对方压力大不大，那是对方的问题”的逻辑。很多爬虫甚至直接无视 robots.txt 里的频率建议，导致服务器在无形中承受了巨大的带宽和计算压力。如果每个开源项目都因为被 AI 爬虫刷爆而选择关门或增加极其苛刻的访问限制，那么 AI 训练所依赖的高质量数据源反而会因为社区的“防御性关闭”而枯竭。

从技术实现层面来看，这种由于流量激增导致的宕机其实是有成熟解决方案的，但问题在于，很多开源项目的维护者没有时间去实时应对这种规模的攻击式抓取。如果你也在维护类似的自建系统，最稳妥的办法是在 Nginx 层直接实施频率限制，或者利用 Cloudflare 等 CDN 的 WAF 功能进行拦截。

以 Nginx 为例，可以通过配置 limit_req_zone 来强制限制单个 IP 的请求频率。例如，在 http 块中定义一个 10MB 的共享内存区域，将请求频率限制在每秒 1 次（1r/s），然后在具体的 location 块中应用该限制，并设置 burst=5 的缓冲区。这样即使爬虫尝试并发抓取，多出的请求也会被排队或直接丢弃，从而保证核心服务的可用性。

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;

server {
    location / {
        limit_req zone=mylimit burst=5 nodelay;
    }
}

但单纯靠技术拦截只能解决“生存”问题，解决不了“生态”问题。现在的现状是，AI 公司在通过抓取开源社区的数据获利，但这些数据的产生依赖于无数志愿者的无偿维护。如果抓取协议不能达成共识，或者 AI 公司不能在抓取时提供更智能的负载感知机制，这种“被动关门”的现象可能会在更多的小众开源项目中出现。

Gentoo 这次关停 Bugzilla 实际上是一个强烈的信号：开源社区的耐心是有限的。当数据的提取变成了对基础设施的破坏时，开发者宁愿选择暂时关闭服务，也不愿在无尽的服务器崩溃中挣扎。