最近，一个开源社区事件引起了我的注意：Gentoo 项目因为 AI 爬虫访问量过大，决定关闭 Bugzilla 的常规开放访问。用户在访问 bug 追踪系统时会被强制要求通过来源质询，注册和提交流程也被限制。表面看，这只是一次“服务器招架不住”的运维事故；往深一层看，这是开源基础设施与 AI 公司爬虫之间的一次正面交锋。
先说一个明确判断：反爬虫已经不是电商平台、搜索引擎 SEO 或内容社区的专属话题，而是每一位自建站开源维护者的基础工作。如果你的项目有公开的 Wiki、Bugzilla、论坛，或者哪怕只有一个老旧的 WordPress 站点，AI 爬虫都可能在你不知情时把带宽和数据库连接占满。
这篇文章会围绕三件事展开：第一，复盘这次事件的背景和影响；第二，从技术角度解释为什么 Bugzilla 这类经典 Web 应用会被爬虫轻松打爆；第三，基于 robots.txt、Nginx 限流和应用层配置给出可落地的三层防护方案。无论你是开源社区维护者，还是只想给自己的小站点做一次防御加固，这篇文章都能派上用场。
1. 事件复盘：AI 爬虫如何让 Gentoo 关闭 Bugzilla
1.1 发生了什么
Gentoo 是一个以源码包管理著称的 Linux 发行版，它的 Bugzilla 长期对外开放，任何人都可以搜索 bug、查看补丁、参与讨论。这种开放是开源项目的传统，也是协作的一部分。
根据公开信息，近段时间 Gentoo 基础设施团队发现，有大量 AI 爬虫抓取 Bugzilla 和 Wiki 页面。这些爬虫不是为了提交 bug，也不是为了阅读文档，而是把整站内容当作训练语料。结果是服务器的数据库查询量、带宽消耗和会话数量都迅速增长，甚至影响到正常用户的访问。
最终，项目方不得不收紧访问策略：启用严格的来源质询，限制新注册，对部分流量直接拒绝。从用户体验看，就像这个 Bugzilla“关门”了。
1.2 这次事件的性质判断
我倾向于把这个事件理解成一次“基础设施层面的资源挤占”，而不是单纯的网络攻击。它没有恶意篡改数据，也没有利用漏洞，只是用合法的 HTTP 请求把服务挤垮了。这恰恰是更麻烦的地方，因为传统安全防护手段对“合法请求洪峰”并不敏感。
从材料看，这不是 Gentoo 一家的问题。越来越多的开源项目开始抱怨 AI 爬虫带来的带宽和计算成本。区别在于，有的项目还扛得住，有的项目已经被迫修改对外开放策略。Gentoo 这次做出关闭访问的决定，更像是把矛盾摆到了台面上：当 AI 公司免费爬取开源社区的数据去训练模型，而基础设施成本却由社区自己承担，这种模式是不可持续的。
对运维人员和开发者来说，这件事真正的启示是：公开 Web 服务不能继续“裸奔”下去了，防护策略需要从“防攻击”升级为“防无差别抓取”。
2. 为什么 Bugzilla 这类 Web 应用扛不住爬虫
2.1 动态页面 + 数据库查询
Bugzilla 是一个由 Perl 编写的经典 Web 应用，早期设计时面向的是“少量用户、大量交互”的场景。它和现代前后端分离应用的架构完全不同。
show_bug.cgi?id=100会根据 URL 中的 bug 编号动态生成详情页。buglist.cgi会执行复杂的 SQL 查询，返回 bug 列表。- 每一个页面请求都可能涉及多次数据库查询和模板渲染。
这带来一个问题：爬虫每访问一个页面，服务器就要实时查一次数据库。如果爬虫有 100 个并发，数据库的连接池很快会被占满。随着访问量提升，查询变慢，CPU 飙升，最终正常的用户请求也被阻塞。
2.2 开放的访问理念
Bugzilla 的默认配置是允许匿名访问的。任何只要知道 URL 的人，不需要注册就能阅读公开 bug。这个理念对开源协作非常友好，但对服务器防护来说却是一个薄弱点。
爬虫不需要注册账号，不需要维护登录态，只需要循环递增 bug 编号就能遍历整个数据库。show_bug.cgi?id=1、show_bug.cgi?id=2、show_bug.cgi?id=3……只要你没有限制，它就能一直刷下去。
2.3 缺少应用层治理
很多老式 Web 应用在最初部署时没有考虑“爬虫治理”问题。没有 API 限流，没有用户行为分析，没有针对匿名用户的请求频率控制。
这一点并不奇怪，因为 Bugzilla 的定位是给项目成员和贡献者使用的，不是给“全网爬虫”抓取的。但当 AI 训练语料收集者盯上它时，这种“设计上的信任”就变成了漏洞。你没法怪应用本身，只能说它在设计时没预料到今天会因为“内容太有价值”而遭到资源挤占。
3. AI 爬虫与传统爬虫的本质区别
很多人会觉得，爬虫不就是爬虫吗，为什么要单独讨论 AI 爬虫？这其实是一个误区。AI 爬虫的行为模式和传统搜索引擎爬虫差别很大。
| 对比维度 | 传统搜索引擎爬虫 | AI 训练爬虫 |
|---|---|---|
| 抓取目的 | 建索引、返回搜索结果 | 收集语料、训练模型 |
| robots.txt 遵守情况 | 绝大部分遵守 | 部分遵守，但也有不少无视 |
| 并发规模 | 中等，且来源相对固定 | 极高，IP 分布广、轮换快 |
| 重复抓取 | 按更新周期抓取变化页面 | 可能反复抓取同一批页面，不识别版本变化 |
| 浏览器伪装 | 一般会在 UA 中声明身份 | 越来越多的爬虫伪装成普通浏览器 |
| 对服务器的价值 | 带来自然流量 | 几乎为零 |
传统爬虫虽然也会消耗资源，但它通常会给站点带来搜索流量，从商业角度说“有来有回”。AI 爬虫则完全不一样，它把内容拿走训练模型，用户以后通过搜索引擎访问原站的概率反而下降了。对于开源项目来说，这种“利出而力不返”的交换极不划算。
另外，AI 爬虫的抓取速度往往比传统爬虫激进很多。因为训练语料需要海量数据，爬虫调度系统会尽量打满并发。这也解释了为什么 Gentoo 的 Bugzilla 会在短时间内被冲垮——不是一次访问多突然，而是持续的高并发请求在消耗资源。
4. 第一道防线：robots.txt 和 User-Agent 策略
4.1 一份反 AI 爬虫的 robots.txt 示例
第一道防线是最简单也最基础的：通过 robots.txt 声明哪些爬虫不能抓取你的站点。虽然 robots.txt 只是一个“君子协定”，并不是强制的，但它能让那些遵守规范的 AI 爬虫主动停手，降低大部分合法 AI 爬虫的流量。
下面是一个针对常见 AI 爬虫的 robots.txt 配置示例，放在站点根目录：
# /robots.txt User-agent: GPTBot Disallow: / User-agent: OAI-SearchBot Disallow: / User-agent: anthropic-ai Disallow: / User-agent: ClaudeBot Disallow: / User-agent: CCBot Disallow: / User-agent: Bytespider Disallow: / User-agent: Google-Extended Disallow: / User-agent: Amazonbot Disallow: / User-agent: PerplexityBot Disallow: / User-agent: Applebot-Extended Disallow: /注意，这里禁用的不是 Googlebot，也不是 Bingbot，而是 Google 的 AI 训练爬虫Google-Extended。Google 官方把Google-Extended与普通搜索爬虫区分开，方便网站管理员单独禁止它抓取用于 AI 模型训练的内容。这是一个很值得借鉴的设计。
如果你的站点主要面向开源协作，可以保留普通搜索引擎的抓取权限，只禁止 AI 训练爬虫，这样既能保住搜索流量，又能降低不必要的资源消耗。
4.2 robots.txt 的边界
需要说明一个事实：robots.txt 拦不住不愿意遵守的爬虫。一个恶意爬虫完全可以无视 robots.txt，直接抓取内容。所以，robots.txt 只是“意愿声明”，不是“技术防线”。
真正能拦住不守规矩爬虫的，还是下一层的访问控制。
另外，在配置 robots.txt 之前，建议先想清楚一个问题：哪些路径应该对 AI 爬虫开放？如果 Bugzilla 和 Wiki 的内容本身是希望被公开索引的，那还是那句话，保留普通搜索引擎，只封掉训练爬虫。如果这个站点只给内部使用，那可以直接对整个域名执行Disallow: /，不给任何爬虫机会。
5. 第二道防线：Nginx 层限流与拦截
5.1 Nginx 基础反爬配置
当 robots.txt 不管用时，就需要在 Nginx 这一层做强制拦截。先通过 User-Agent 判断请求是不是 AI 爬虫，如果是，直接返回 429（Too Many Requests）或者 403。
这段配置可以放在 Nginx 的http块中，使用map指令定义一个变量：
# /etc/nginx/conf.d/bot-block.conf map $http_user_agent $blocked_bot { default 0; ~*GPTBot 1; ~*OAI-SearchBot 1; ~*anthropic-ai 1; ~*ClaudeBot 1; ~*CCBot 1; ~*Bytespider 1; ~*Google-Extended 1; ~*Amazonbot 1; ~*PerplexityBot 1; }然后在server块中引用这个变量：
# /etc/nginx/conf.d/default.conf server { listen 443 ssl http2; server_name bugs.example.org; if ($blocked_bot) { return 429; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里把服务放在一个前端 Nginx 后面，上游是原始应用。配置完成后，GPTBot、ClaudeBot这些爬虫的请求会在 Nginx 层直接收到 429 响应，不会进入后端应用，也就不会消耗数据库连接。
5.2 请求频率限流
只靠 UA 判断有一个问题：很多 AI 爬虫会伪装成普通浏览器或者声称自己是 Googlebot。这时候按 UA 做拦截就不够用了，还需要对 IP 做速率限制。
Nginx 的limit_req模块可以限制单位时间内的请求数量：
# /etc/nginx/conf.d/rate-limit.conf limit_req_zone $binary_remote_addr zone=bugzilla_limit:10m rate=5r/s; server { listen 443 ssl http2; server_name bugs.example.org; location / { limit_req zone=bugzilla_limit burst=10 nodelay; proxy_pass http://127.0.0.1:8080; } }这里的含义是：每个 IP 平均每秒只允许 5 个请求，突发时可以允许 10 个请求排入队列并且不延迟处理。对于正常用户来说，每秒 5 次请求已经足够使用；对于爬虫，尤其是多线程高频抓取的爬虫，这个限制能直接卡住它。
这里真正容易踩坑的地方是，你的站点的“正常用户”可能来自同一个出口 IP，比如单位 NAT 代理或者学校网关。如果限流策略太严格，一个出口 IP 下的几十个用户会互相影响。所以限流参数要结合真实访问日志来调整，不能拍脑袋设一个极端值。
5.3 慎用 if 指令
Nginx 的if指令在社区里一直有争议。它不像普通编程语言里的条件判断，有时会在不合预期的上下文中执行，导致 rewrite 或 proxy_pass 行为异常。
但是，if ($blocked_bot) { return 429; }这种写法是被证明安全的。因为return指令不会触发后续的 location 匹配问题，也不会改变请求重写流程。如果你的需求仅仅是“判断之后直接返回状态码”，可以放心用。如果打算在if里面做复杂的 rewrite 或 proxy_pass，那建议换一种实现方式，比如用 OpenResty 的 Lua 脚本。
6. 第三道防线：CDN/WAF 与 Bugzilla 应用层加固
6.1 引入 CDN/WAF 的思路
当服务器已经出现被爬虫打崩的迹象，说明单纯的请求层限流可能不够。这时候就需要考虑引入 CDN/WAF 来做前端隔离。
很多开源项目会采用 Cloudflare、阿里云 WAF 或者自建的 ModSecurity 网关。这些产品的一个共同特点是：在到达应用服务器之前，就先对请求做一次“人机识别”。
比如 Cloudflare 的“托管质询”（Managed Challenge），会在浏览器第一次访问时弹出一个轻量验证，通过后放行。对于普通用户来说，这个过程只需要一两秒；对于爬虫来说，很多爬虫根本不具备执行 JavaScript 验证的能力，于是就被拦在入口之外。
需要强调的是，使用 CDN/WAF 并不是一劳永逸。你要做的是把 Bugzilla 的前端 DNS 指向 CDN，让 CDN 先过滤一遍流量，再回源到 Nginx。这样即使某个爬虫伪装了 UA，也必须先过 CDN 这一关。
6.2 Apache 虚拟主机拦截
如果你的 Bugzilla 直接跑在 Apache 上，没有单独的前端 Nginx，也可以通过 Apache 的mod_rewrite和mod_http2来拦截 AI 爬虫。
在虚拟主机配置文件里加入：
# /etc/apache2/conf-available/bugzilla-bot.conf <VirtualHost *:443> ServerName bugs.example.org RewriteEngine On RewriteCond %{HTTP_USER_AGENT} GPTBot|ClaudeBot|CCBot|Bytespider|anthropic-ai [NC] RewriteRule ^/bugzilla/ - [R=429,L] # 其他 Apache 配置 </VirtualHost>这段配置会把 UA 中带有指定关键词的请求直接返回 429。和 Nginx 的实现思路一样，只是换了一个服务器软件。
6.3 Bugzilla 参数调整
在应用层，Bugzilla 本身也提供一些参数可以降低爬虫的影响。虽然这些参数不是专门为反爬设计的，但实操中很有用。
第一是requirelogin参数。把它的值调整为开启之后，匿名用户无法直接查看 bug 详情，必须登录才能访问。这个做法能极大减少爬虫的可用攻击面，因为大部分爬虫不会注册账号。
第二是限定注册邮箱。通过管理界面的参数emailregexp，可以限制允许注册的邮箱域名。比如只允许@gentoo.org或已贡献者的域名注册，避免爬虫批量注册账号。
第三是关闭不需要的公开功能。如果站点不需要开放 API，可以关闭 REST API 或者要求 API 请求必须带 key。每一个减少开放入口的配置，都是在降低被爬虫抓取的概率。
这一层配置要遵循最小权限原则：只关闭确实不需要的入口，不要因为怕爬虫就把整个站点锁死。毕竟 Bugzilla 的公开性也是它作为开源协作工具的价值所在。
7. 验证效果：日志分析与数据对比
7.1 用 Bash 快速统计
做任何防护配置之前和之后，都应该先看日志。只有知道敌人在哪里，才能判断防线有没有起作用。
先用一条命令统计访问量最高的 User-Agent：
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -50这段命令会提取 access.log 中的 User-Agent 字段，并统计每个 UA 的出现次数，按从高到低排序。如果看到GPTBot或ClaudeBot出现在前几位，说明确实有 AI 爬虫进来了。
7.2 用 Python 分析 AI 爬虫 UA
Bash 适合快速看一眼，但如果要做更精细的分析，可以用 Python 脚本。下面这段脚本会从日志中提取 User-Agent，并识别出哪些属于 AI 爬虫，输出它们的访问量占比。
#!/usr/bin/env python3 # analyze_ai_bot.py —— 分析 Nginx 日志中的 AI 爬虫访问量 import re from collections import Counter BOT_KEYWORDS = [ "gptbot", "oai-search", "anthropic", "claudebot", "ccbot", "bytespider", "perplexity", "google-extended", ] # 适配 Nginx combined 日志格式 LOG_PATTERN = re.compile( r'(?P<ip>\S+) \S+ \S+ \[[^]]+\] ' r'"[^"]*" (?P<status>\d+) \S+ "[^"]*" "(?P<ua>[^"]*)"' ) ua_counter = Counter() ai_counter = Counter() total = 0 with open("/var/log/nginx/access.log", "r", errors="ignore") as f: for line in f: match = LOG_PATTERN.search(line) if not match: continue ua = match.group("ua") total += 1 ua_lower = ua.lower() ua_counter[ua[:80]] += 1 for keyword in BOT_KEYWORDS: if keyword in ua_lower: ai_counter[keyword] += 1 break print(f"总请求数: {total}") print("\nTop 20 User-Agent:") for ua, cnt in ua_counter.most_common(20): print(f"{cnt:8d} {ua}") print("\nAI 爬虫关键词命中情况:") for keyword, cnt in ai_counter.most_common(): print(f"{cnt:8d} {keyword}")运行方式：
python3 analyze_ai_bot.py如果这个脚本输出的 AI 爬虫关键词命中数在防护前后有大幅下降，说明配置生效了。如果命中数没有变化，那就要考虑爬虫是否伪装了 UA，或者是不是从新的 IP 池过来的。
7.3 验证步骤
- 配置 robots.txt 后，隔天对比日志中对应爬虫的 UA 访问量。
- 配置 Nginx 限流后，用
curl -I模拟带 AI 爬虫 UA 的请求，确认是否返回 429。 - 观察正常用户接口的响应时间是否恢复。
- 如果引入了 CDN/WAF，还要检查回源量，确认是否真的有流量被打回源站。
8. 常见误伤与排查清单
爬虫防护最怕的不是挡不住，而是误伤正常用户。这里列几个常见问题。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 搜索引擎收录量下降 | robots.txt 误拦了合法搜索爬虫 | 检查 robots.txt 是否禁用了 Googlebot 或 Bingbot | 只禁用 AI 训练爬虫，保留普通搜索引擎爬虫 |
| 正常用户被频繁要求验证 | CDN 质询策略过于敏感 | 查看 WAF 拦截日志，确认是否为高频访问 IP | 提高阈值，或只对注册接口做质询 |
| 单位/学校出口 IP 被限流 | NAT 下多个用户共用 IP，触发 limit_req | 查看 Nginx error.log 中的 limit_req 条目 | 上调速率阈值，或设置limit_req不包括静态资源 |
| 爬虫绕过 UA 拦截 | 爬虫伪装浏览器 UA | 用日志分析实际 UA 和 IP 分布 | 增加 IP 速率限制和行为分析，不只依赖 UA 识别 |
| CDN 回源失败 | 源站防火墙封了 CDN 节点 IP | 查看源站访问日志 | 在源站只允许 CDN 的 IP 段回源，避免直接封禁 |
这个排查清单并不是一次性做完就结束。爬虫策略是动态对抗，今天的配置只能应对今天的爬虫特征。建议每隔一段时间重新看一次日志，更新拦截规则。
9. 开源基础设施的 AI 爬虫防御最佳实践
结合这次 Gentoo 事件，我给开源项目和小型自建站总结一份可执行的最佳实践清单。
| 层面 | 最佳实践 | 备注 |
|---|---|---|
| 声明层 | 在 robots.txt 中禁止 AI 训练爬虫 | 保留普通搜索引擎，保住自然流量 |
| 入口层 | 接入 CDN/WAF，启用来源质询 | 能拦截 JavaScript 执行能力弱的爬虫 |
| 代理层 | Nginx 按 UA 和 IP 双重限流 | UA 拦截 +limit_req组合 |
| 应用层 | 关闭匿名查看、限制注册邮箱 | 适合 Bugzilla、论坛等可登录系统 |
| 数据层 | 对热点数据做缓存 | 减少动态请求对数据库的压力 |
| 日志层 | 定期分析 UA 分布和异常流量 | 用脚本统计，形成持续监控 |
| 机制层 | 建立误伤回退机制 | 紧急规则要先灰度，确认无问题再全量 |
另外还有三个容易被忽略的原则：
第一，对公开服务做权限收敛。如果一个功能不需要匿名开放，就不要开放。匿名访问是爬虫最大的便利条件。
第二，所有拦截规则都要有回滚方案。不要在生产环境直接改完配置就跑，最好先在预发环境验证。特别是 CDN 的防护规则，如果配置不当，可能直接挡住整个站点的访问。
第三，日志保留周期要足够长。分析爬虫行为至少需要保留 7 到 30 天的访问日志，否则无法看到趋势变化，也就无法判断防护措施是否真的有效。
10. 总结
这次 Gentoo 关闭 Bugzilla 的事件，表面看是一次“AI 爬虫把服务器打爆”的运维事故，实际上暴露了开源社区一个更深层的成本问题：当 AI 公司用爬虫刷取社区数据来训练模型时，产生的带宽和计算成本却要由开源项目自己承担。这个模式长期看一定不可持续，而防御 AI 爬虫就成了基础设施维护者的必修课。
本文从事件背景说到技术原理，再给出三层防护方案：第一层用 robots.txt 声明边界，第二层用 Nginx 或 Apache 做请求拦截和频率限制，第三层用 CDN/WAF 和应用层参数加固。无论你的项目是大型开源社区的 Bugzilla，还是个人博客和论坛，这套思路都可以复用。
下一步建议你打开自己的 Nginx 访问日志，先跑一遍文中的 awk 命令，看看是否有 AI 爬虫已经在访问你的站点。如果发现异常流量，再按照 robots.txt、Nginx 限流、应用层加固的顺序逐步配置。实践中你会发现，大部分流量样本并不复杂，真正需要花费精力的，是持续监控和调整那些在爬虫与正常用户之间动态变化的灰度地带。
