最近一个开源社区事件引起了我的注意Gentoo 项目因为 AI 爬虫访问量过大决定关闭 Bugzilla 的常规开放访问。用户在访问 bug 追踪系统时会被强制要求通过来源质询注册和提交流程也被限制。表面看这只是一次“服务器招架不住”的运维事故往深一层看这是开源基础设施与 AI 公司爬虫之间的一次正面交锋。先说一个明确判断反爬虫已经不是电商平台、搜索引擎 SEO 或内容社区的专属话题而是每一位自建站开源维护者的基础工作。如果你的项目有公开的 Wiki、Bugzilla、论坛或者哪怕只有一个老旧的 WordPress 站点AI 爬虫都可能在你不知情时把带宽和数据库连接占满。这篇文章会围绕三件事展开第一复盘这次事件的背景和影响第二从技术角度解释为什么 Bugzilla 这类经典 Web 应用会被爬虫轻松打爆第三基于 robots.txt、Nginx 限流和应用层配置给出可落地的三层防护方案。无论你是开源社区维护者还是只想给自己的小站点做一次防御加固这篇文章都能派上用场。1. 事件复盘AI 爬虫如何让 Gentoo 关闭 Bugzilla1.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?id100会根据 URL 中的 bug 编号动态生成详情页。buglist.cgi会执行复杂的 SQL 查询返回 bug 列表。每一个页面请求都可能涉及多次数据库查询和模板渲染。这带来一个问题爬虫每访问一个页面服务器就要实时查一次数据库。如果爬虫有 100 个并发数据库的连接池很快会被占满。随着访问量提升查询变慢CPU 飙升最终正常的用户请求也被阻塞。2.2 开放的访问理念Bugzilla 的默认配置是允许匿名访问的。任何只要知道 URL 的人不需要注册就能阅读公开 bug。这个理念对开源协作非常友好但对服务器防护来说却是一个薄弱点。爬虫不需要注册账号不需要维护登录态只需要循环递增 bug 编号就能遍历整个数据库。show_bug.cgi?id1、show_bug.cgi?id2、show_bug.cgi?id3……只要你没有限制它就能一直刷下去。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 爬虫如果是直接返回 429Too 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 zonebugzilla_limit:10m rate5r/s; server { listen 443 ssl http2; server_name bugs.example.org; location / { limit_req zonebugzilla_limit burst10 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/ - [R429,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-Agentawk -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 爬虫 UABash 适合快速看一眼但如果要做更精细的分析可以用 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(?Pip\S) \S \S \[[^]]\] r[^]* (?Pstatus\d) \S [^]* (?Pua[^]*) ) ua_counter Counter() ai_counter Counter() total 0 with open(/var/log/nginx/access.log, r, errorsignore) 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 限流、应用层加固的顺序逐步配置。实践中你会发现大部分流量样本并不复杂真正需要花费精力的是持续监控和调整那些在爬虫与正常用户之间动态变化的灰度地带。