5个地理分布的节点，90个CPU核心，每天600万次请求涌入。合法开发者只占其中2%，剩下98%的流量不是为了写代码，而是为了把你最宝贵的数据喂给AI模型。
Linux Foundation的IT基础设施总监Konstantin Ryabitsev在博客中披露了这个数字。他用的词是「background radiation」——一种持续不断的背景辐射。这种辐射的表现形式很具体：在任何给定时刻，90个CPU核心中有14到16个正在做同一件事，把git commit渲染成HTML页面。这些页面的唯一用途是被爬虫抓取后喂给大模型训练。
CPU核心在被榨干
合法开发者只有2%，其余全是爬虫
这个比例听起来反直觉。git.kernel.org是Linux内核开发的官方仓库，按理说每天应该挤满提交代码的开发者。实际情况是，真正用Git协议克隆、拉取、推送代码的开发者只占2%。剩下98%的流量来自AI训练数据爬虫。
更准确地说，这些爬虫不是直接用Git协议操作。如果它们这样做，只需要一次克隆就能拿到全部历史数据，服务器负载很低。但它们选择了一种更高效的方式消耗服务器算力：逐个commit访问网页端，每次请求都触发一次HTML渲染。
[[reaction=shell-command-spells|caption=git clone一次就完事，你非要每次点]]
这就像你想喝一碗汤，正确的做法是直接端走整碗。而这些爬虫选择了一滴一滴地舀，每舀一次都要让你把锅重新烧热。
Ryabitsev指出，渲染commit消耗的CPU甚至超过了所有其他合法访问的总和。这不是偶尔的流量高峰，而是持续性的资源占用。20%的算力，长期、稳定地被用于生产一种只对训练模型有价值的输出。
Linux内核为什么是AI眼中的金矿
理解这个现象，需要先理解AI训练数据的需求。
大型语言模型的训练依赖于海量代码数据。GitHub上的公开仓库是主要来源之一。但问题在于，经过多年发展，公开代码库已经被AI生成内容污染。Stack Overflow、各种教程网站、代码问答平台上的答案，很多本身就来自早期模型的输出。这些「合成数据」被反复抓取、训练，形成闭环。
Linux内核代码的历史恰好避开了这个问题。
纯净数据金矿
内核开发有严格的审查流程。每一个commit都经过maintainer审核，有明确的作者 attribution，有Developer Certificate of Origin签名。最重要的是，内核开发实践形成于大规模AI生成内容泛滥之前。这意味着内核历史是一份未被AI污染的训练数据——这是当前AI数据管道中最稀缺的资源之一。
内核代码的技术价值也不言而喻。它是系统编程的教科书级参考，涵盖内存管理、调度、文件系统、网络栈等核心子系统。对训练代码模型的AI来说，这是高质量的「ground truth」数据。
这就是为什么爬虫愿意付出高昂的服务器成本去逐个渲染commit。它们买的不是代码本身，而是代码背后的历史纯净性和技术权威性。
从封IP到算力挑战的攻防升级
面对这种消耗，维护者采取了一系列防御措施。
最早的策略是IP封禁。识别出爬虫的来源IP，直接拒绝访问。但这很快就被绕过了——爬虫切换到住宅代理池。这些代理IP来自真实的家庭网络，伪装成普通用户。
第二个策略是ASN（Autonomous System Number）封禁。某些AS被确认专门用于爬虫服务，封禁整个AS可以一次性阻断大量请求。但这种做法有副作用，可能误伤共享同一AS的正常用户。
最新的手段是引入名为Anubis的proof-of-work挑战机制。每当请求到达时，服务器会要求客户端完成一个计算密集型任务。这个任务对浏览器友好——正常用户点击几次页面，等待几百毫秒就能完成。但对爬虫来说，这意味着每秒钟的请求处理能力下降了几个数量级。
攻防天平在移动
数据表明，Anubis拦截了约66%的请求。但剩下的34%中，大多数仍然来自自动化系统——它们只是愿意付出计算成本来通过验证。
这锅服务器背
Anubis挑战机制工作流程
住宅代理与物联网设备让封禁失效
真正的变化发生在近几个月。爬虫不再依赖数据中心IP，而是转向了住宅代理网络和物联网设备。
这意味着什么？你的智能电视、网络摄像头、甚至某些智能家居设备，都可能成为爬虫流量的一部分。这些设备被植入恶意软件后，会加入僵尸网络，向外发出git.kernel.org的请求。
你的设备可能在帮爬虫打工
封禁策略在这里完全失效。你无法因为某个IP来自住宅网络就拒绝它——这可能真的是一个开发者的家庭宽带。你更无法封禁一个AS，因为住宅IP分散在成千上万个不同的运营商网络中。
维护者尝试过更激进的措施。有报道提到，某个时期曾短暂封禁了整个巴西的访问——因为大量爬虫流量来自巴西的住宅IP。这种做法显然是临时性的应急手段，也说明了问题的严重程度。
开源数据免费，但获取门槛在变高
这个问题的本质是开源基础设施的可持续性挑战。
git.kernel.org的运行资金来自捐赠和基金会支持，预算是基于服务真实开发者的需求计算的。当98%的流量是AI爬虫时，实际的使用模式已经完全偏离了设计意图。
[[reaction=workplace-grind|caption=开源维护者的日常]]
Ryabitsev等人的应对方式是在资源和技术之间寻找平衡。他们不拒绝爬虫（技术上也很难完全做到），而是通过Anubis提高了爬虫的成本。这相当于在免费公路上设了一个收费站——开车的人还能过，但要等多一会儿。
对于开源社区来说，这是一个需要持续关注的趋势。AI训练对高质量数据的渴求不会停止，而Linux内核作为最优质的代码数据源之一，将持续面临压力。维护者需要不断升级防御，而社区也需要讨论：当基础设施被超出设计规模的流量冲击时，谁该为此买单？
目前的答案是：由已经承担开发维护成本的那些人继续承担。但这能持续多久，值得怀疑。
最蠢的抓取方式，最高效的成本
git.kernel.org 管理员 Konstantin Ryabitsev 在官方博客《Creepy crawlies》里披露了一组数字：服务器90个CPU核心中长期有14到16个被用于渲染 git commit 的 HTML 页面。这些算力不用于构建代码、不用于服务 Patchwork 审核、不用于支持任何开发者工作流，只为向爬虫吐出一页页静态 HTML。
服务器CPU被榨干了
不克隆仓库，非要逐个渲染HTML
正常开发者用 Git 协议拉代码：git clone，服务器端执行 pack 打包，一次性返回几GB的 commit 对象链。这种方式CPU开销极小，带宽集中在传输层。而 AI 爬虫选择了另一条路：通过 web 界面逐个访问每个 commit 的详情页，让服务器用 Ruby on Rails 渲染 HTML。
这不是技术限制导致的无奈之举，而是有意识的选择。原因很直接——Web 界面返回的 HTML 可以直接喂给 LLM 阅读理解，不需要二次解析 Git 对象；而且单个 commit 页面包含 diff、author、date、commit message 等结构化信息，比 raw diff 更接近自然语言描述。模型训练方不在乎你用了多少 CPU，他们只在乎数据拿到的成本。
Ryabitsev 原文中的说法很诚实："we spend more CPU cycles rendering commits for scrapers than we spend on all other kinds of legitimate access." 这句话翻译成大白话就是：给爬虫渲染页面的算力，比服务所有合法开发者的总和还多。
SourceHut 创始人 Drew DeVault 在《请不要再当着我的面把你们的成本转嫁给我了》一文中也表达了类似困境——他每周要花 20% 到 100% 的时间应对 LLM 爬虫，而不是做产品。这不是 kernel.org 一家的问题，而是整个开源基础设施正在面临的结构性成本转嫁。
从10ms到100ms，一个细节决定胜负
Anubis 是一个 proof-of-work 机制，部署在 lore.kernel.org 和 git.kernel.org 入口。它的核心逻辑不是验证身份，而是提高每次请求的计算成本。正常情况下一个页面请求耗时约10ms，引入 Anubis 后首次请求需要完成一定的计算量，延迟提升到约100ms。
爬虫被迫搬砖
这对人类用户几乎没有感知差异。一个人浏览 git.kernel.org 通常点击5到6次页面，总等待时间在可接受范围内。但对爬虫来说，这意味着抓取速度下降了10倍。如果原来一分钟可以爬1000个页面，现在只能爬100个。更重要的是，每次请求都需要真实的 CPU 计算，而不只是一个内存占几十MB的 Python 脚本。
Reddit 上有用户提到 Anubis 的设计目的："It changes the economic cost of crawling from 'a simple Python script using tens of MBs of memory' to 'at least 256MB of memory'." 这不是一个技术壁垒，而是一个经济壁垒——当爬取的边际成本显著上升，部分爬虫会直接放弃。
实际效果如何？kernel.org 团队的数据显示，Anubis 拦截了约66%的请求。但剩下34%的爬虫并不在乎这100ms的延迟，它们继续爬取。更麻烦的是，这些通过验证的请求中仍有约98%来自自动化客户端。PoW 能筛掉低成本脚本，筛不掉愿意为数据付费的大模型公司。
爬虫访问路径成本对比
这里有一个关键的不对称性：合法开发者使用 Git 协议时，服务器端只做 pack 输出，不渲染任何 HTML；而爬虫强制走 web 路径，等于在服务器上跑了一个完整的 Ruby on Rails 应用栈来渲染纯文本数据。这就像为了喝一杯水，你把整条河流的水都烧开了一样。
Ryabitsev 在 blog 中透露，团队已经尝试过封禁 IP、封禁 ASN（自治系统编号），甚至一度封锁了整个巴西的访问作为临时措施。但住宅代理和物联网设备的泛滥让这些手段逐渐失效——当攻击流量分散在数百万个随机住宅 IP 上时，封禁任何一个来源都会误伤正常用户。这也解释了为什么 PoW 成为了当前最可行的方案：它不按来源封禁，而是按行为成本筛选。
从架构角度看，这个问题暴露了开源基础设施的一个脆弱点：我们习惯把「免费」等同于「开放」，但开放的数据如果缺乏合理的访问成本设计，就会被最高效的掠夺者搬空。kernel.org 的选择——用 PoW 提高爬取成本而不是直接关闭入口——是一种折中，它的边界在于：能拦住低成本脚本，拦不住愿意承担算力的商业爬虫。对于依赖自愿捐赠和有限预算的开源项目来说，这已经是当前条件下最不坏的选择。
防御战的升级与失效
封禁IP、ASN，然后发现全没用
最初管理员采取的是最直观的防守方式：封禁异常IP和ASN。这套逻辑在传统的反爬虫场景里是有效的——识别出非正常访问模式，直接拉黑即可。
问题在于，AI爬虫的来源结构与传统爬虫完全不同。
传统爬虫通常来自云服务器集群，IP地址相对集中，ASN特征明显。而现在的攻击方使用的是住宅代理网络（residential proxy networks），这些代理分散在全球数百万个普通家庭中。一个典型的住宅代理池可能包含超过5000万个IP地址，每个IP都带有真实的家庭宽带标识。
更麻烦的是，这些流量并非来自单一攻击者。据 kernel.org 管理员 Konstantin Ryabitsev 披露，攻击呈现分布式特征，不同时间段的来源IP几乎没有重叠，且每次访问都会更换User-Agent和请求路径。
封禁ASN的效果同样有限。很多住宅代理的出口IP属于不同的ISP，而ISP的网络结构本身就高度碎片化。当你封禁一个ASN时，可能会误伤大量正常的本地用户。
Anubis算力挑战拦截66%，还剩34%
既然封IP没用，管理员引入了 Anubis 挑战机制。这是一种工作量证明（proof-of-work）方案：服务器向请求方下发一个计算任务，只有完成计算的客户端才能获得响应。
效果立竿见影。数据显示，Anubis 成功拦截了 66% 的恶意请求——这些请求因为无法或不愿承担计算成本而放弃访问。
算力门槛是个好筛子
Anubis 防线拦截效果
但 34% 这个数字依然触目惊心。对于一个日均 600 万次请求的系统来说，仍有 200 万次请求能够穿透防线，消耗服务器的 HTML 渲染算力。
这些能够通过挑战的请求有一个共同特征：它们愿意承担计算成本。对大型 AI 公司而言，几毫秒的额外延迟完全可以接受。它们甚至可能部署了专门的 GPU 集群来批量解决这些挑战。
挑战机制变成了新的成本中心
更讽刺的是，Anubis 本身也消耗服务器资源。每次挑战的计算和验证都需要 CPU 周期，这意味着防御本身也在增加负载。管理员不得不在「拦截效率」和「防御成本」之间做取舍。
攻击流量已转向智能电视和住宅代理
当简单的住宅代理池不足以支撑大规模抓取时，攻击方开始利用更广泛的设备网络。
Smart TV、机顶盒、智能家居设备——这些设备通常运行着嵌入式的 Linux 系统，拥有固定的公网 IP，且很少受到严格的安全限制。它们的网络流量往往被 ISP 视为「正常家庭用户流量」，难以被规则引擎识别。
从架构角度看，这形成了一种分布式的计算资源网络。数百万台家用设备被间接纳入到爬虫的基础设施中，每台设备的贡献很小，但总量足以对单一服务器集群造成压力。
| 住宅代理池 | | (5000万+ IP) | ↓ | 家庭IoT设备 | | (智能电视等) | ↓ | AI训练数据管道| 这种演进让传统的边界防御几乎失效。你无法通过规则引擎区分「正常家庭用户查看内核文档」和「爬虫利用同一IP进行批量抓取」。两者的网络特征几乎一致。
防御方不得不重新思考架构策略
管理员面临的真正困境是：开源项目的基础设施依赖志愿维护和有限的捐赠资金，而攻击方是拥有无限算力的商业实体。这种资源不对称决定了单纯的防御策略很难长期奏效。
开源基础设施的至暗时刻
维护者的崩溃：每周20%到100%时间在对抗爬虫
Konstantin Ryabitsev，Linux Foundation IT基础设施主管，在Creepy Crawlies一文中给出了硬数据。任意时刻，五个节点上都有14至16个CPU核心在空转，唯一的任务是「把git commit渲染成HTML页面」——而这些页面没有任何人类读者，它们的用途是喂给数据管道。
更值得关注的数字来自SourceHut创始人Drew DeVault。他在一篇公开博客中写道，过去几个月里，他每周花在应对LLM爬虫上的时间从20%到100%不等。这不是孤例。Ryabitsev的描述是「系统负载的背景辐射」——它不是突发性的DDoS，而是一种持续存在、无法关掉、必须时刻防守的状态。
后台一直在跑，人已经麻了
这种「背景辐射」式攻击最难受的地方在于，它不会像传统攻击那样触发告警阈值。CPU使用率从平时的60%跳到80%，运维人员可能以为是业务增长，直到某天发现某个请求链路需要100毫秒才能返回一个静态HTML页面。
关闭部分功能自保，还是继续开放？
kernel.org团队的选择是分阶段的。
第一阶段是封禁。封IP，封ASN范围，尝试用边界规则把异常流量挡在外面。结果如上所述：住宅代理和物联网设备（包括智能电视）让封禁策略形同虚设。
第二阶段是引入Anubis算力挑战。原理是让每个请求在获取资源前先完成一定计算量。结果显示，66%的请求在挑战阶段就被拦掉了。但剩下的34%——也就是每天约200万次有效请求——仍然以合理延迟拿到了数据。
[[reaction=overtime-bricks|caption=搬不完的砖，挡不住的爬虫]]
这就引出了一个根本性的取舍。kernel.org选择引入计算挑战，本质上是把成本从服务器转移到了请求方。对合法开发者而言，偶尔多等100毫秒几乎无感；但对爬虫来说，这意味着单位时间内能获取的数据量下降一个数量级。
问题是，开源协议决定了数据本身是公开的。你能提高访问门槛，但你不能拒绝访问。Ryabitsev在博客中承认，这种防御是「不断升级的军备竞赛」。
这不只是kernel.org的问题
SourceHut的案例说明这已经是一个行业性问题。DeVault的措辞直接：「请不要当着我的面，把额外的成本转接到我身上。」他的平台被频繁抓取，服务器中断，核心工作被迫让位于反爬防御。
[[reaction=programmer-core|caption=运维日常：人在做，题在算]]
Arch Wiki也已经部署了Anubis机制，目的是把爬虫的经济成本从「一个占用几十MB内存的Python脚本」提升到「至少256MB内存」。这不是针对某一类攻击者的精确打击，而是一种成本不对称策略——让防御方的投入远低于攻击方的规模化成本。
从更宏观的视角看，这个问题揭示了一个尚未被行业充分讨论的矛盾：AI训练数据的获取，正在从「合法授权」走向「裸取资源」，而承载这些资源的开源基础设施的维护者，既没有法律武器，也没有足够的工程资源来阻止这种行为。
Linux内核本身已经在Linux 7.0中引入了AI编程助手的治理规则（见Documentation/process/coding-assistants.rst），要求AI工具在贡献代码时遵守许可和DCO规范。但这只是对「使用AI贡献代码」的约束，并没有解决「用AI爬取代码库」的问题。
[[reaction=questioning-rebuttal|caption=规则是有了，但执行力在哪]]
可执行的判断很明确：如果你是某个开源项目的维护者，且你的基础设施已经出现异常流量，不要试图封禁（效果有限），也不要假装没看见（成本在累积）。考虑部署类似Anubis的计算挑战机制，把攻击方的规模化成本抬上来。同时，把相关的运维成本记入项目预算——这不是某个志愿者的副业，而是AI时代的基础设施公共品问题。
如果攻击已经导致你的服务器频繁中断，那说明你已经在某家公司的成本表里了。区分善意和恶意的访问者，不再是一个技术判断，而是一个经济判断。
