你不需要 Anubis
近年来，大型语言模型训练公司运营的爬虫变得愈发猖獗。它们不再遵守robots.txt协议，伪造用户代理和IP地址，甚至通过恶意请求对小型网站发起DDoS攻击。这种现象似乎主要集中在Anthropic的ClaudeBot身上。相比之下，OpenAI的GPTBot行为模式相当规范，易于拦截。
这促使越来越多网站采用Anubis——这种基于工作量证明的爬虫防护方案，要求所有访问者在设备上解决小型加密问题才能继续操作。
但问题在于：Anubis 并不奏效。好吧，它确实有效——尤其对不愿使用Cloudflare的用户而言，它能成为优秀的DDoS防护方案。但多数Anubis用户 根本不需要DDoS防护，他们真正需要的是抵御激进的大型语言模型抓取工具。若仅此用途，您可能根本不需要阿努比斯。
人们常宣称Anubis通过大幅增加访问网站的计算成本来阻断爬虫。遗憾的是，大型语言模型公司若要爬取所有Anubis部署实例，所需成本仅为约0.00美元。
但它确实有效，对吧？人们使用Anubis是因为它确实能阻止LLM爬虫抓取网站，所以它肯定有效，对吧？
是的，但仅因LLM爬虫根本不运行JavaScript。
我近期自建了Redlib，尽管未与他人共享实例，却因大量抓取爬虫试图获取优质Reddit内容而遭到Reddit限速。以下是我用12行Caddyfile解决该问题的方案：
domain.com {
# 匹配所有未携带“verified”Cookie的请求
@unverified not header Cookie *verified*
# 返回设置Cookie的JS页面
handle @unverified {
header Content-Type text/html
respond <<EOF
<script>
document.cookie = ‘verified=1; Path=/;’;
window.location.reload();
</script>
EOF 418
}
# 其他请求正常代理
reverse_proxy localhost:3001
}
是的，它确实有效，且效果不逊于Anubis，同时不会让访客忍受10秒的页面加载时间。
当然，爬虫可能某天开始运行JS代码，届时此方案将失效。但Anubis同样面临此问题——即便是常用户也坦言它只是“在爬虫学会绕过前的一时权宜之计”。事实上，华为的爬虫能运行JavaScript，它们轻松破解了Anubis的验证机制。既然都采用临时方案，何不选择对用户近乎透明的方案？
遗憾的是，Cloudflare(此处泛指所有类似爬虫防护服务)几乎是抵御爬虫的唯一可靠方案。尽管高级防护模式仍会带来诸多困扰(尤其对VPN用户)，但在实际DDoS攻击等情境下别无选择。就连Anubis的官方文档也承认：
大多数情况下您无需此方案，仅需使用Cloudflare保护源站即可。但若您无法或不愿使用Cloudflare，Anubis将为您提供解决方案。
我理解许多人强烈反对Cloudflare的互联网垄断地位，他们选择Anubis等方案来防御真实攻击的行为完全可以理解。我显然无意贬低Anubis项目及其开发者。作为DDoS防护方案它确实有价值——只是被大量不需要它的人过度使用了。
因此，若您仅需防范ClaudeBot(这似乎是多数使用Anubis网站的诉求)，请务必用更优雅的方案取代这个令人困扰的权宜之计。
本文文字及图片出自 you don't need anubis
我最喜欢Anubis的一点是(在默认配置下)，如果你将User-Agent头设置为curl，它会完全绕过实际的验证挑战。
例如：若在浏览器中打开此链接，将触发验证码：https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/13ce36fef98a3f4…
但若通过命令行运行：
我敢肯定这种漏洞会被AI爬虫大量滥用。若您正在运行Anubis，请花点时间正确配置它，或者像楼主那样搭建更不影响访客体验的方案。
这是我为避免破坏那些能正确识别自身的良性自动化程序而做的战术性决策。为此我遭到了无休止的嘲讽。这根本没有赢的可能。
该机制仅针对名称含Mozilla的用户代理进行挑战，因为其他用户代理本就可被识别。若Anubis迫使机器人更改用户代理，则已达成目标——此类流量现可直接处理。
这基本是维基百科长期以来的机器人政策。运行机器人时应通过用户代理进行标识。
https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Found…
若每个机器人请求都使用不同UA呢？
此时可通过常规WAF规则区分机器人与真实用户，因为浏览器早已冻结UA值。
成功。目标是区分真实用户与伪装成用户的机器人。
能否解释具体含义？为何特指Mozilla而非WebKit等引擎？
由于历史原因[0][1]，所有现代浏览器的用户代理均以“Mozilla/5.0”开头——即便它们与Firefox毫无关联。
[0]: https://en.wikipedia.org/wiki/User-Agent_header#Format_for_h…
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/…
Anubis系统本不该给访问网站的真实用户带来困扰。
我从事ffmpeg相关工作，因此需要定期访问其错误追踪器和邮件列表网站。几乎每隔几天就会遭遇Anubis的访问阻断，其中三分之一到五分之一的情况会彻底失败。其余时候则延迟几秒。长期如此，让我对最初支持的Anubis项目逐渐心生不满。
我终于找到一套有效的规则集，最新版本已修复此问题。
感谢！
不客气。真希望我能更早发现这个方案，但白天要全职工作，晚上周末还要处理这些事——帮丈夫找新工作、应对教育机构采购部门的复杂流程、处理其他让我厌烦的事务——实际编程的时间实在有限。真希望我能全职投入这个项目。政府拨款申请一直没通过，因为我拿不出他们要求的数据指标。恐怕得惹恼一些人才凑齐最低限度的数据，才能证明我值得获得这些拨款。
我在GNOME的错误追踪器上遇到过相关问题，通过修改用户代理就能绕过；但Cloudflare的安全验证在qutebrowser里却屡试不爽，无论我怎么折腾都过不了关。
我不理解人们为何看到针对不道德行为的反制措施时，抱怨的不是那些不道德行为本身，反而对反制措施横加指责。更荒谬的是反向操作——比如把Cookie横幅归咎于GDPR而非某些网站运营商的卑劣行径。
我不明白为何有人不明白：你可以同时对双方都糟糕的现状感到愤怒，也可以既憎恶某种行为又反对针对它的反制措施。这两者并不矛盾。
我没看到楼主对双方都感到不满。任何地方都没暗示他考虑过这种可能性。
>这最初是我支持的方案。
这段引文强烈表明他确实持这种观点。
没错，我反对AI抓取行为。但对我个人而言，当访问bug追踪器时遭遇延迟和错误，这个平衡就彻底崩溃了。
不过听起来问题可能很快就能修复
另外阿努比斯吉祥物超可爱！ 😉
我理解ffmpeg这么做的原因。毕竟没人指望它收费。在大型语言模型(LLM)时代来临之前，当机器人流量尚未主导网络时，ffmpeg网站的运营成本或许尚可承受。但如今他们大概不愿继续免费为大型LLM运营商提供数据支持——这些公司却能从用户身上榨取利润。
这就像飞机安检。我们是否感到不便？是的。该怪谁？恐怕不是航空公司或安检服务商，而是那些想无票登机或携带爆炸物的人。
只要Anubis项目及其参与者不试图两头下注，不以黑帮敲诈的方式恶化LLM现状，我认为只要可行就该推行。
虽与主题无关，但我认为机场诸多安检措施的深层动因在于：营造安全假象能提升民众的乘机意愿。
[已删除]
遗憾的是在巴西、印度等人口密集国家，高性能计算机被征收极高税率，普通民众几乎无力承担。
> 遗憾的是，大型语言模型公司若想爬取所有Anubis部署实例，所需成本约为$0.00。
本文引用的来源网站计算存在谬误。该网站作者假设爬虫会保存一周的访问令牌，但多数全网爬虫并不如此操作。Anubis系统的核心设计初衷，正是要让每秒多次重复请求同一站点的机器人付出高昂代价。
执行JavaScript工作量证明的“成本”其实无关紧要，整个概念在悲观检测下根本站不住脚。Anubis要求用户用低效的JavaScript执行大量无关紧要的sha256哈希运算，而抓取工具用原生代码能快得多——这根本就是游戏结束。这与我们不用哈希现金验证邮件的道理相同：普通用户能承受的工作量远低于专业人士的实施能力。该工具若真有价值，纯粹源于其晦涩难懂且非标准的特性。
在审查过程中，我注意到作者存在一个常见误解：认为工作量证明中的“难度”仅取决于哈希值前导零字节的数量，这将精度限制在2的幂次方。我理解部分问题源于JavaScript的局限性，但最常执行的代码路径似乎被编写得极其低效。
毫不夸张地说，即使稍作优化的原生实现，也能将“工作量证明”耗时压缩至低于SSL握手过程。
这种思路并不明智，因为它会让你误以为只需设计更聪明的证明算法即可。这种算法必须同时具备抗GPU、抗ASIC和抗原生代码攻击的能力——但现实并非如此。
即便假设攻击者与合法用户处于完全平等的条件(例如双方运行完全相同的JavaScript挑战实现)，工作量证明也无法有效抵御滥用行为。其经济模型根本无法成立。核心问题在于：攻击者消耗的是可替代且极其廉价的CPU时间，而真实用户承受的是用户可感知的高昂延迟成本。
他们在安全场景中确实使用了SubtleCrypto摘要[0]，该算法原生支持哈希运算。
具体针对Firefox[1]时，他们会切换至JavaScript后备方案——因其实际运行更快[2](可能源于开销问题)：
[0] https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt…
[1] https://github.com/TecharoHQ/anubis/blob/main/web/js/algorit…
[2] https://github.com/TecharoHQ/anubis/releases/tag/v1.22.0
若您能优化代码，欢迎提交拉取请求！本人并非JS专家。
没错，但关键就在这里。问题不在于这个想法本身不好，而在于工作量证明机制(PoW)根本不适合它。互联网范围内的爬虫不保存状态？好吧，那就强制客户端执行需要保存状态的操作。你根本不需要通过破解SHA2难题来实现这个目标；你根本不需要破解任何东西。
整件事毫无意义。
OpenAI Atlas通过 成为用户的网页浏览器 击溃了所有防御。他们插在你与目标用户之间，将用户浏览的所有内容吸光吸净，再回传用于训练。
防火墙此刻形同虚设。
更大的AI公司谷歌数十年来一直在这么做。他们始终是读者与你之间的中介，这个地位不可撼动。没有他们，你就没有读者。
此时此刻，大型语言模型防火墙真正阻隔的只有小玩家，这反而巩固了巨头的统治地位。
OpenAI和谷歌希望你封锁所有其他竞争者。
> 谷歌数十年来一直在这么做
你有任何证据或间接证据能证明此事吗？
如果Chrome真的抓取过你访问过的所有网站并发送给谷歌，那么在网络流量中找到相关迹象简直易如反掌——甚至在Chromium代码里都能发现。
抱歉，我的意思是他们夹在客户关系中间。
谁敢阻止谷歌搜索索引自己的网站？
这种关系虽对立却不可或缺。
网站加载数据进入训练数据库的事实是否已确认？
但对主要关心服务器稳定性的人来说，Atlas并非问题。它不会额外增加百万次加载。
> 是否确认网站访问数据会被纳入训练数据库？
若OpenAI声称没有，你会相信吗？
若你会相信，那当Meta投入数十亿美元训练模型时，你是否也相信他们会坦白——这些模型是基于公司通过BitTorrent下载的数千兆盗版媒体训练而成？
我们无需判断可信与否。若真有此说法，总该有人能指出至少一个未知连接的pcap文件，或某些反编译代码。否则这不过是阴谋论。
数据必然会传至OpenAI服务器，否则他们如何用大型语言模型处理？我们无从知晓这些数据是否最终进入训练集。
个人认为现阶段还是相信官方声明为宜；采取其他行动可能招致反弹，甚至法律风险。
我认为最初的质疑指向不同层面。“是否确认网站加载…”——我理解作者讨论的是基于页面上下文的常规浏览行为，而非仅限于明确提问的情境。
凡是包含在上下文中的内容，从那一刻起就处于OpenAI的掌控之下，你只能信任他们不会滥用这些数据。
这并非阴谋论，而是第三方托管大型语言模型交互机制的本质。
据我理解，Anubis的核心价值在于降低AI公司机器人造成的成本，而代理生成的访问量远低于全网爬取；其实际消耗可能与用户手动浏览相当接近。
除非用户提出的问题需要访问大量页面——比如谷歌Gemini在查询本地购物中心咖啡馆的典型价位和菜单时就相当实用，这类信息绝非单页可涵盖。
> 这整个方案毫无意义。
若完全错失核心要义，确实毫无意义。
> OpenAI Atlas通过充当用户浏览器彻底破解了这些限制。他们插入在您与目标用户之间，将用户浏览的所有内容吸纳回去用于训练。
很酷。不过阿努比斯的核心目的并非阻止所有机器人访问，其概述已明确说明：
> 本程序旨在保护小型网站免受人工智能公司无休止请求洪流的冲击。
OpenAI Atlas 借道用户常规浏览的行为不在阿努比斯管辖范围内，因为这既不会让小型网站瘫痪，也不会大幅增加托管成本。
> 当前大型语言模型防火墙真正阻挡的，只有小型参与者
哎呀，谁来保护这些小混蛋呢？
关键在于，只要刮取者有意为之，就能轻易绕过防护
如何实现？
嗯…通过在每次网站请求中设置verified=1的cookie？
我是不是漏了什么？这不就是设置个明文cookie然后刷新页面吗？
他们可以这么做，但如果每个网站的实现略有不同，他们要么得为每个站点单独处理(虽然麻烦但重要站点尚可接受)，要么干脆启用JS(不过…我以为他们早就这么做了？毕竟还有大量站点仍在使用单页应用？)
若多数爬虫已运行JavaScript，我将大感意外。这种“爬虫不运行JavaScript”的普遍认知令我困惑。
我不喜欢这个方案，因为它对使用UMatrix/NoScript等浏览器插件、使用TUI浏览器(如chawan、lynx、w3m等)或直接禁用JavaScript的用户构成敌意。
诚然，这与Anubis对相同用户群体的敌意如出一辙，实属公地悲剧。
所有批评者都忽略了关键点。Anubis确实有效阻止了针对多个生产环境网站(尤其是自主托管的代码仓库和论坛)的DDoS级爬取攻击。若其失效，要么Anubis贡献者会推出修复方案，要么网站开发者自行解决，要么遭受攻击的网站直接关闭。这本质上是场军备竞赛，不存在永久解决方案。每次防御升级都将被轻易绕过(理论上)，直到多数攻击者发现进一步投入不值得额外收益，或防御体系彻底崩溃。
Anubis绝非某种阴谋论工具，更不是展示动漫猫娘图片的把戏，而是抵御机器人攻击导致网站瘫痪的最后防线。许多管理员安装它时心怀不甘，因为访问网站时出现延迟确实令人恼火。没人会为乐趣而这么做。
当前形态的互联网——理论上我能在卧室里ping通地球上任何服务器——似乎难以持续。我认为它终将走向终结。
虽难以完全阐明，但我感觉当前设计中存在某种博弈论层面的缺陷，与现实环境根本不相容。
多年前谷歌之类公司不是提议过搜索引擎推送通知吗？这样机器人就不必反复检查是否有新内容，而是由我们主动通知它们。我认为这会是公平的折中方案：你们不进行DDoS攻击，我们便及时告知更新内容(爬虫需建立订阅机制)。
我个人网站有时整年不更新，但爬虫仍占访客多数(虽未严重到需反制措施)。若采用这种机制，多数爬虫访问本可避免。
个人经验是：当我想查看页面却被迫面对阿努比斯那种愚蠢的3秒烦人提示时，我会非常恼火，反而更倾向于绕过网站直接从LLM或搜索引擎获取信息。
这简直是自我实现的预言——你们恶化用户体验，反而为LLM提供内容的正当性提供了借口。
这一切都源于当前Lambda/云计算环境下，处理少量请求的成本变得极其高昂。
遗憾的是，选择并非在于采用Anubis类系统的网站与提供自由无障碍访问的网站之间。真正的抉择在于：要么忍受阿努比斯，要么眼睁睁看着网站消失。
我常逛的某个论坛今年大半时间都在与LLM爬虫玩打地鼠游戏，多次遭遇蝗虫般的大规模攻击，导致真实用户数周无法访问。
管理员尝试了各种封禁手段，甚至最终封锁了整国IP范围，却始终徒劳无功。
论坛的存续关键在于能否抵御滥用爬虫。偶尔忍受半秒的阿努比斯启动画面，是维持论坛生命的小代价。
我同意，每次页面加载前都要看到阿努比斯少女的动画画面确实令人反感。Codeberg.org也常弹出提示界面，这让我对他们的服务印象大打折扣。
父文章中的Caddy配置使用了418状态码。这个做法虽巧妙，但会破坏搜索引擎索引吗？为何不采用307状态码？
我用于个人Redlib实例，搜索索引无关紧要。即使使用307状态码也不确定能否被索引——或许只需为Googlebot添加例外规则。
“遗憾的是，Cloudflare几乎是抵御机器人攻击的唯一可靠方案。”
注：
“虽不知是否有优质替代方案，但此处'Cloudflare'泛指所有同类机器人防护服务。”
这正是关键所在。Cloudflare已成为默认选择，不知为何无人愿意冒险尝试其他服务商。虽然存在替代方案，但当被问及时人们甚至说不出具体名称。
(说来惭愧，我一直在用AWS Cloudfront，但刚才还得想半天才想起它的名字。)
问题在于，越来越多的情况下，它们确实正在运行JS。
在这场持续的军备竞赛中，我们很可能看到诸如此类的简单检测手段——仅凭“设置cookie”或至少“在无头Chrome中打开页面并测量cookie”这类操作，就能被少数检测系统识别出来。
> 越来越多的攻击者开始运行JS。
有人能提供证据吗？
我发现更多大型僵尸网络部署在阿里云、华为云上，还有一个腾讯云上的僵尸网络运行无头Chrome。目前采用IP段封禁策略应对。我正与腾讯云滥用部门沟通，他们苦苦哀求我别默认封禁他们的IP。
> 他们越来越频繁地运行JS。
我指的是他们拥有惊人的计算资源，却只用其中一小部分提升数据质量——因为他们深信(这符合他们的现状)规模即一切，何不也用JS？该死，就算得在满载浏览器的容器里运行，哪怕不是无头模式，他们也会这么干。
Chrome甚至发布了开发者工具管理器，允许任何大型语言模型在浏览器中全权操作。
导航、截图等功能一应俱全，仅此模块就包含30余种工具。
如今我们能直接运行搭载语言模型的真实浏览器。真不知如何才能破解这种方案。
但刻意选择略显麻烦的方案自有其道理。我想到的是某种政治宣言：“我们正面临混蛋AI公司的困扰，且看它们如何让所有人生活更糟。”
所以我不用Cloudflare。只服务支持Brotli压缩且持有有效Cookie的客户端。所有实际内容都通过SSE连接传输。在5美元的VPS上从未遇到过机器人问题。
最近我意识到：对于非用户浏览器，我的演示程序本质上就是zip炸弹。
为什么？
因为我流式传输每个帧，而每个帧未压缩大小约180kb(压缩后最小可达13字节)。这在用户浏览器中不成问题，因为浏览器不会保留这些帧。
但爬虫会缓存这些帧，很快就会陷入灾难性延迟。
当然这些内容毫无价值可言，基本是徒劳无功。不过看到某些卑劣爬虫被复选框炸得粉碎，确实令人会心一笑[1]。
– https://checkboxes.andersmurphy.com
完全正确。我不明白在少数核心上运行10秒的计算，怎么可能比大型数据中心运行的机器人更具成本优势
阿努比斯系统的核心并非彻底阻止抓取，而是提高其成本。
具体高出多少？我完全不理解这里的成本模型。
你那12行代码里是不是画了个可爱的动漫女孩？果然如此
按预期运作！;-)
宏观而言，为何人人都要抓取网页？
为何不让一家公司垄断抓取后转售数据？是法律/责任问题吗？抓取本身属于法律灰色地带，但转售抓取内容显然构成版权侵权？
我猜他们认为https://commoncrawl.org不够完善，而正如你所言，“剩余部分”正是他们竞争优势的来源。
在我看来，认为在LLM末日之后还有值得抓取的内容纯属狂妄自大。外界充斥着垃圾信息，除非你拥有完美无缺的分类器，否则抓取到的所谓“优质新内容”中99.9%都是AI生成的。
E: 事实上这个想法愚蠢至极，我不得不怀疑它是否本质上就是一次DDoS攻击——通过疯狂抓取导致系统崩溃，从而阻断竞争对手的获取渠道。
我简单试用了下Pangolin——号称是自托管版的Cloudflare Tunnels，挺酷的。
不过注意到Digital Ocean Marketplace的镜像会询问是否安装名为Crowdsec的“多人防火墙”。虽然是付费服务，但似乎有个广受好评的社区版本。其实我很想知道它的缺点(除了显而易见的——为安全牺牲部分用户隐私)，但至少理论上，如果它能正常工作且商业模式可行，这个方案似乎在Cloudflare和完全不设防之间找到了不错的平衡点。
不确定Crowdsec是否适合此用途。它更像是fail2ban的替代品，而非DDoS防护方案。
Cloudflare能够避免向大量用户展示验证码，同时仍能过滤海量非人类流量的核心方法之一，正是凭借其遍布互联网的海量数据。
> 但它确实有效吧？人们使用Anubis是因为它能阻止LLM机器人抓取网站，所以肯定管用对吧？
> 是啊，但仅因为LLM机器人根本不运行JavaScript。
我认为并非如此，因为当Anubis自身从工作量证明机制切换到基于JavaScript的新挑战机制时，我的服务器曾出现过载，而切回工作量证明方案后问题就解决了[0]。
我其实有点讨厌Anubis，因为它迫使我给原本不使用JS的网站添加了脚本。但(1)这是唯一能解决我机器人问题的方案，(2)部署极其简单，(3)误拦截真实访客的概率极低(不像验证码或IP/ASN封禁那样误判率极高)。
[0]: https://github.com/TecharoHQ/anubis/issues/1121
以下是基准测试结果，简而言之：Anubis的性能不如在相同HEDT CPU上运行的优化客户端验证器。
因此“PoW税”本质上仅适用于低需求请求者——这类用户既无动力进行优化，其定制化方案也过于复杂难以实现规模化优化。
https://yumechi.jp/en/blog/2025/proof-of-mutex-outspeeding-a…
https://github.com/eternal-flame-AD/pow-buster
该问题曾被“修复”，但因修复方案存在死锁漏洞而撤回。(变更日志记录：“移除导致生产环境问题的bbolt actorify实现”)
人们似乎尚未意识到局势早已败局已定。当初问题尚小且存在恶意行为者时，无人重视——“不过几个坏分子，不必担心，他们迟早会厌倦离开”。不，他们不会离开，只会不断壮大。如今连多数好人都沦为恶徒，只因恶行毫无惩罚。正如我所言，游戏结束。
是时候建立自己的封闭花园了，为人类搭建覆盖式VPN网络。将服务迁移至此，若有人违规？封禁其IP。屡禁不改？再次封禁。还敢回来？搞什么鬼？直接封禁其VPN服务商。彻底清理门户——不同网络可相互对等连接。看，互联网本就是网络之网，这并不难。
好主意。另一种方案是将业务迁移至点对点网络。这些企业需要昂贵的服务器来运行庞大模型或单纯收集数据。有时制胜之道在于不参与游戏：真正的无服务器架构。
这话题早有讨论(该帖链接了Tavis Ormandy引发Anubis风暴的原文)，且不论Anubis的初衷或执行方式，仅从计算机科学角度重申：其采用的工作量证明机制毫无意义。
工作函数在密码哈希中合理，因为它利用了非对称性：攻击者每次验证成功需猜测数百万次无效密码，因此攻击者承担了绝大部分(几乎全部)成本。
反垃圾邮件系统采用工作量证明的原理相同：垃圾邮件“攻击”依赖于极低的尝试成本，使其能高效覆盖数百万受害者以期命中一次。
比特币采用工作量证明的合理性在于其同步机制功能。解决SHA2谜题本身并无实际价值，但这些谜题为整个协议提供了时间基准。
工作量证明若作为代币税则毫无意义——其反垃圾邮件机制中的非对称性在此完全倒置。每个机器人请求网页都会为人工智能公司创造代币收益，而数量远超机器人的合法用户反而承担了更高成本。
以上论述并非否定构建严密反爬火墙的可能性！我常以YouTube的解决方案为例：他们采用JavaScript构建内容保护系统，刻意设计成高成本逆向工程结构，还能在用户创建新账号时隐蔽探测浏览器配置参数。
Anubis的下个版本就该实现这个功能，届时他们就该彻底抛弃工作量证明机制。
恕我直言，本帖几乎全是些对成熟方案嗤之以鼻的评论，满口建议却不愿付诸实践。我理解你身为_重要人物_需要支付账单赚取收入，但至少该谦逊地承认：现有方案已优于那些“若由他人构思实现或许更佳”的空想。
[已删除]
奇怪的是，你竟因并非针对你的言论而感到被冒犯。
这项工作正在为Anubis提供更优的替代方案，除了Xe之外，本帖所有参与者似乎都对此了如指掌。
谦逊在于承认这个解决方案对某些人确实有效——那些遭受DDoS攻击和不道德的大型语言模型过度爬取困扰的小型网站运营者，尽管它并非完美无缺。若这给您作为用户带来不便——我想您所谓的“用户反弹”指的就是这个——您的解决之道是停止访问这些站点，而非对他们采取应对措施的行为指手画脚。
我何来受辱？我可曾指责过您？我甚至没指责过Anubis。是你要求提供依据，我才按你要求贴出工作成果和证据，让讨论立足于“事实”。
但yt-dlp依然能抓取YouTube内容，显然这还不够。
> 工作函数作为令牌税毫无意义；实际存在反向反垃圾邮件不对称性。每个机器人请求网页都会为AI公司产生令牌。合法用户(远超机器人数量)反而承担更高成本。
同意，住宅代理成本远高于计算资源，但机器人似乎能轻松获取数百万住宅IP。因此我不确定阿努比斯系统为何有效——我的推测是机器人对每页访问设有时限，而它们并未针对启用阿努比斯的页面延长该时限。
> 该系统采用JavaScript构建内容保护机制，刻意设计为难以逆向工程，并能隐蔽探测创建新YouTube账户时浏览器的精确配置。
> Anubis的下个目标就该是实现这个功能，届时他们应该直接废弃工作量证明机制。
他们确实做了[0]，但效果不佳[1]。当然，Anubis的实现比YouTube的 简单得多，但 (1) Anubis 没有数十名员工能测试数百种浏览器/操作系统/版本组合，确保不会误伤真实用户；(2) 设计抗逆向工程的开源程序远比闭源程序复杂得多，若 Anubis 转为闭源，我绝不会使用它。
[0]: https://anubis.techaro.lol/docs/admin/configuration/challeng…
[1]: https://github.com/TecharoHQ/anubis/issues/1121
谷歌的内容保护系统不仅确保客户端能运行JavaScript。它实现了一个混淆虚拟机，若我记忆无误(部分细节可能与蓝光BD+方案混淆)，该机制通过运行时产物构建哈希输入。据我所知，这是个人作品而非团队成果。此处所称“源代码”实为客户端JavaScript。
无论如何：从计算机科学角度看，Anubis当前的做法毫无意义。
“没错，它确实有效，且效果不逊于Anubis，同时不会让访客忍受10秒的页面加载时间。”
不错…但现在我们需要这类方案的基准测试。我不认识作者，但大致了解问题所在(因我自建服务器，当前流量主要来自AI抓取机器人，而非常规索引机器人或——请注意——人类)。当多维问题存在多种解决方案时，我需要统一的比较标准。
新方案固然值得欢迎，但若无法高效比较，我仍难以选择最适合的方案。
这场不断升级的军备竞赛终将走向何方？难道要变成处处需要登录的封闭网络？更多验证码涌现，Cloudflare成为互联网的守门人？必定存在更优解。
我们至今仍被验证码(及其他挑战机制)所困——这个诞生25年的概念，已浪费数百万工时并造成数十亿基础设施成本浪费[0]。
[0] https://arxiv.org/abs/2311.10911
或许该建立这样的网络：用户预先提供信用卡号，每次外发请求都需付费。
否则我该如何安葬逝者，确保他们抵达来世？
阿努比斯的设计借鉴了顶级僵尸网络防护机制——你用内存廉价提供JavaScript服务，迫使客户端为使用你的高性能计算而进行高成本运算。这能极大阻止攻击者浪费你的时间，将1:1000的计算成本放大比转化为1000:1。
但这显然是防止抓取流量的拙劣方案。抓取流量目的并非压垮网站，而是快速读取内容。若让单次读取成本高得离谱，访客自然远离；若成本仅略有增加，抓取者根本不在乎。
Anubis本质是DDoS防护工具，而非通用反爬工具——它仅能抵御不模拟完整浏览器的基础爬虫。许多网站因误解其功能而盲目部署，但这种伪装显然难以持久。
> 抓取流量的目标并非压垮你的网站，而是快速读取一次内容。
若抓取程序的作者真正关心网站存续，我们本不会面临此类问题。但如今更准确的说法是：目标在于以最快速度尽可能多地抓取数据，最好在网站崩溃前完成。他们根本不在乎其他副作用。搜索引擎有动力维持网站运行，AI公司则不然(或许除了困惑度评估)。
首先，Anubis并非为保护仅被读取一次的简单网站而设计。它针对的是GitLab实例这类场景——AI机器人会索引每个文件的每次提交。这将导致数千次甚至数百万次的读取。而且读取安努比斯页面一次的成本也不高。因此我实在不明白你的论点何在，因为前提似乎完全错误。
有些人部署安努比斯并非为了阻止抓取，而是为了阻止同一页面每秒被多次抓取。
我发现阿努比斯对我确实很有用，因为它能有效地提供一份便捷清单，标明哪些项目由无能之辈管理而应当避而远之。撇开吉祥物不谈，正如本文所述，它通常毫无用处。老式蛇油倒还有些实用功效。