Anubis到底阻止了谁?
摘要
本文批评了Anubis——一个旨在阻止AI爬虫的HTTP工作量证明代理——指出它很容易被AI绕过,同时给人类用户带来了倒退性的负担,尤其是那些使用弱设备或非JavaScript浏览器的用户。
<p><a href="https://lobste.rs/s/ktew3s/who_does_anubis_actually_stop">Comments</a></p>
查看缓存全文
缓存时间: 2026/07/12 10:48
# Anubis 到底挡住了谁?
来源:https://fzakaria.com/2026/07/09/who-does-anubis-actually-stop
我一直在为 Linux 内核开发一个补丁,通过 bpf 在 `binfmt_misc` 中支持解释器 (`PT_INTERP`) 的 `$ORIGIN` [线程](https://lore.kernel.org/linux-mm/[email protected]/T/#t)。
当然,我正在借助一个 LLM 来完成这项工作!为了提前给 LLM 注入上下文,我让它阅读了 https://lore.kernel.org/ 上的那个线程。
[Anubis 挑战页面](https://fzakaria.com/assets/images/anubis-challenge.png)
哎呀。看来他们采用了 [Anubis](https://github.com/TecharoHQ/anubis),这是一个 HTTP 代理,要求在允许访问资源之前完成*工作量证明*。
这真的起到作用了吗?
不幸的是,没有。
我的 AI 勤奋地编写了 **anubis-fetch**,你可以在 https://github.com/fzakaria/anubis-fetch 找到它。这个工具会尝试原生解决工作量证明,或者作为最后手段,启动 Chromium 来访问该 URL。
> 该工具还会通过 [req](https://req.cool/) 原生模拟真实 Chrome 的 TLS/JA3 指纹,因此也能绕过被动的 Cloudflare 封锁。☝️
```
# 输出 HTML 到标准输出
$ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/
# 输出可读的纯文本
$ anubis-fetch --text https://lore.kernel.org/linux-mm/some-thread/T/
```
那么,我们到底挡住了谁?
Anubis 想要针对的对手,恰恰能轻易击败它。
使用 Anubis 的整个做法感觉是一种倒退,并且边缘化了那些无法获得“优质”AI 的人。
对于爬虫来说,解决 Anubis 挑战是一次性的、成本可摊销为零的操作,因为 cookie 可以被缓存和复用。对于人类来说,每次新访问都要经历几秒钟的旋转加载、电池消耗。他们无法在彼此之间摊销任何成本。
这种“累退税”对使用较弱设备或通过手机访问内容的人更甚。那些不利用 JavaScript 的客户端(例如,文本浏览器 w3m/lynx、屏幕阅读器、RSS 阅读器)则被完全排除在外。
部署 Anubis 是否阻止了上述任何一种机器人农场?还是说它们只是暂时遇到了轻微不便,不得不为机器人增加对新工作量证明解决方案的支持?
讽刺的是,Anubis 的目标是阻止 AI,但 AI 却轻而易举地绕过了它,而人类和开放网络却要为此付出代价。
假设 Anubis 现在是一种累退税,那么它要我们付出多少代价?
这里的每个数字都是粗略估计。这根本不是环境方面的论证,因为机器人农场和 AI 工具本身消耗的能量要多出几个数量级。尽管如此,看看人们花费大量时间来完成边缘化群体的工作量证明挑战,还是很有意思的。
> 难度 `d` 表示哈希必须具有的前导零*十六进制*字符数,因此每次解决的预期工作量是 `W = 16^d` 次哈希。
| 难度 | 哈希数 / 次解决 | 原生 Go | 浏览器 JS | 感觉上的墙钟时间 |
|------|----------------|---------|-----------|-----------------|
| **4** | 65,536 | ~1.3 ms | ~130 ms | ~1–5 秒 |
| **5** | 1,048,576 | ~20 ms | ~2 秒 | ~5–15 秒 |
| *难度 4 是常见的默认值。假设速率:原生 Go 约 50 MH/s,浏览器内 JS 约 0.5 MH/s;“感觉上的墙钟时间”包括页面加载、web worker 和重新加载。* |
令 `C` 为全球每天解决的 Anubis 挑战次数。假设每次解决的感觉时间为 `t = 2 秒`,设备能量消耗为 `E = 20 焦耳`(屏幕 + CPU)。
- **每年消耗的人类时间** = `C × t × 365 / 3.15×10^7`
- **每年消耗的能量 (kWh)** = `C × E × 365 / 3.6×10^6`
| `C` (次解决/天) | 每年浪费的人类时间 | 每年消耗的能量 |
|----------------|-------------------|----------------|
| 1 M | **~23 人·年** | ~2 MWh |
| 10 M | **~230 人·年** | ~20 MWh |
| 100 M | **~2,300 人·年** | ~200 MWh |
总的来说,我们花费了大量时间等待访问网站;这些时间在 AI 时代之前是不需要花的。作为人类,时间对我而言是宝贵且有限的,而对机器人来说则不是。
相似文章
少复用软件
本文讨论了一个网站使用Anubis(一种工作量证明系统)来防止AI公司的大规模爬取,凸显了内容提供者与AI数据收集之间持续存在的斗争。
爬虫情况更新
关于AI爬虫机器人日益严重的问题的最新更新,这些机器人导致网站不堪重负,并探讨了住宅代理网络及其对开放网络的影响。
AI让大规模网页抓取变得触手可及。这是一个问题吗?
本文探讨了AI编程助手如何使普通大众能够进行大规模网页抓取,由此引发了关于忽略robots.txt和速率限制的道德问题,并对AI提供者的责任提出质疑。
激进的AI爬虫让维基运营变得有些糟糕
讨论了激进的AI爬虫如何通过模仿人类流量和使用住宅代理来干扰维基运营,大幅增加服务器成本并导致服务不稳定。
AI用量限制就像一个黑箱
本文批评了AI代币用量与定价缺乏透明度,认为Claude和Cursor等提供商故意模糊消耗情况以掩盖成本并促使升级。