Anubis：利用工作量证明（Proof-of-Work, PoW）机制来阻止 AI 网站爬虫
“Anubis” 是一款利用工作量证明（Proof-of-Work, PoW）机制来阻止 AI 爬虫抓取网站内容的开源软件。它由开发者 Xe Iaso 创建，旨在应对当前大语言模型（LLM）训练数据抓取带来的挑战。
下面是它的工作原理、特点以及争议。
- Anubis 和工作量证明（Proof-of-Work, PoW）机制
- 疑问一：需要规模效应
- 疑问二：Anubis可以本地部署吗？
- 疑问三：Anubis的工作量设计对部署这套系统的服务器的性能消耗？
- 疑问四：Anubis 有可能流行起来吗？趋势如何？
- 疑问五：Anubis对网站seo的影响
- 你对本文的反应是：
- 你也许感兴趣的：
Anubis 和工作量证明（Proof-of-Work, PoW）机制
⚙️ 工作原理
Anubis 的核心思路是要求访问者在请求网站资源前，必须完成一个特定的计算任务（即工作量证明挑战）。这个过程通常如下：
- 用户请求页面：当你的浏览器尝试访问一个受到 Anubis 保护的网站时，服务器会先返回一个 PoW 挑战（例如，要求计算出一个哈希值，其前缀需要满足特定条件，如以若干个”0″开头）。
- 浏览器计算：你的浏览器会在后台（通常通过 JavaScript 和 WebCrypto API）进行大量的哈希计算（通常是 SHA-256），以寻找满足条件的随机数（nonce）。对于现代浏览器和普通用户设备，这个计算过程通常在几百毫秒内就能完成，几乎无感。
- 验证与放行：一旦计算完成，浏览器会将答案（nonce）提交给服务器验证。验证通过后，服务器会颁发一个访问令牌（通常存储在 Cookie 中，例如
within.website-x-cmd-anubis-auth，基于 JWT 实现），在令牌有效期内（例如一周），后续访问将直接放行，无需重复计算。
🎯 设计目的与效果
Anubis 的设计目的非常明确：
- 增加AI爬虫成本：对于需要大规模、高频抓取的AI公司来说，要完成海量的PoW计算任务，会消耗巨大的算力资源和电力成本，使得抓取行为变得“不经济”，从而望而却步。
- 对正常用户影响极小：得益于现代浏览器的性能，一次计算对个人用户而言耗时极短，体验上接近无感。首次验证后一段时间内无需重复计算。
- 保护网站资源：帮助网站，特别是独立站点、开源项目、文档平台等，抵御AI爬虫的过度抓取，防止服务器带宽和资源被耗尽。
📊 Anubis 与传统反爬手段对比
| 特性 | Anubis (PoW机制) | 传统验证码 (CAPTCHA) | Robots.txt |
|---|---|---|---|
| 用户体验 | 几乎无感（浏览器后台计算） | 需要人工识别和交互 | 无感，但无强制力 |
| 强制力 | 经济层面（增加爬虫成本） | 技术层面（需要人类认知） | 道德层面（依赖爬虫遵守） |
| 对抗自动化爬虫 | 有效（规模化成本高昂） | 可能失效（AI可识别简单验证码） | 无效（爬虫可无视） |
| 典型应用 | 保护API、文档站、博客等免受大规模爬取 | 登录、注册、防刷票等场景 | 告知爬虫哪些内容不应抓取 |
🤔 争议与讨论
Anubis 的思路也引发了一些讨论和争议：
- 能源消耗问题：PoW机制本质上需要消耗计算资源和能源。支持者认为，这是对抗AI爬虫更大规模浪费（无节制抓取和模型训练耗电）的必要代价。反对者（如FOSS倡导者Jamie Zawinski）则认为这是一种“通胀性、无效率的废物”，可能引发新的军备竞赛。
- 效果持久性：有人质疑，攻击者（大型AI公司）总能在算力支出上超过防御者（普通网站）。但Anubis的支持者认为，其意义在于显著提高对方的抓取成本，而非绝对阻止。
- 并非万能：Anubis主要针对大规模自动化爬虫。对于旨在保护极度注重隐私、禁用JavaScript的用户，或者应对集成了完整浏览器环境、能执行JavaScript的复杂爬虫（如无头浏览器），开发者可能还需要探索其他辅助方案（如浏览器指纹识别）。
🌐 实际应用
Anubis 自发布以来，已被不少知名组织和项目采用，例如 UNESCO（联合国教科文组织）、GNOME项目、WINE、Enlightenment等。
Anubis 通过工作量证明机制，为网站（尤其是中小型网站和开源项目）提供了一种增加AI爬虫抓取成本的防御思路。它对正常用户影响较小，旨在应对当前AI公司无视robots.txt等规则进行大规模数据抓取的问题。
疑问一：需要规模效应
我的理解是，对于一个网站，AI爬虫第一次抓取时需要工作量证明，然后获取cookie，这样再抓取整个网站就不再需要工作量证明了。因此，一个网站安装了Anubis并不会给AI爬虫带来很多负担，只有很多网站大规模普及后才会有效果
完全正确！这正是Anubis机制设计的核心博弈点和其有效性的前提。
您的理解可以分解为两个层面，我们来详细探讨一下：
1. 理解的完全正确：单个网站的“一次性成本”
对于一个安装了Anubis的独立网站（例如 example.com），AI爬虫的抓取流程确实是：
- 首次请求任何一个页面时，收到一个PoW挑战。
- 花费一定的计算资源（比如几秒钟的GPU时间）完成挑战，获得一个针对该域名（
example.com）的认证Cookie（JWT令牌）。 - 在接下来的令牌有效期内（例如一周），爬虫携带这个Cookie访问该网站的任何页面都将畅通无阻，无需再计算任何PoW。
因此，对于一个单独的网站，爬虫只需支付一次性的、固定的入门费，之后就可以“免费”地、大规模地抓取整个站点的内容。这个成本对于财力雄厚的AI公司来说，几乎是微不足道的。
2. 推论也是核心关键：效果依赖于“大规模普及”
这正是Anubis及其倡导者（比如其作者Xe Iaso和早期采用者如Gnome、UNESCO等）所期望和努力的方向。它的防御模型不是“堡垒式”的单个防御，而是“人民战争”式的集体防御。
- 成本是累加的、线性的：爬虫的目标不是抓一个网站，而是抓取整个互联网上高质量的内容。假设它要抓取100万个安装了Anubis的网站。
- “一次性成本”变成了“百万次成本”：爬虫需要为这100万个网站每一个都单独计算一次PoW挑战。每个网站颁发的Cookie都是独立的，无法通用。
- 经济模型生效：此时，总成本就不再是忽略不计的了。它变成了：
- 巨大的算力成本：需要部署庞大的计算集群来并行解决海量的、不同网站的PoW挑战。
- 巨大的时间成本：解决每个挑战都需要时间（即使很短），收集齐所有网站的“入场券”会显著拖慢整个数据收集的进度。
- 巨大的工程和存储成本：需要维护一个极其庞大的Cookie库，管理数百万个不同域名的认证令牌及其有效期，并在每次抓取时正确携带。
结论：这是一种基于经济学的“军备竞赛”
Anubis的设计哲学可以总结为：
“将一场技术对抗（爬虫与反爬虫）转变为一场经济消耗战。”
- 对单个小网站：安装Anubis更像是一种表态和加入联盟的行为，其本身提供的保护有限，但贡献了集体防御的一份力量。
- 对AI爬虫方：面对一个广泛部署了Anubis的互联网，抓取行为从“几乎零成本”变成了“需要持续投入大量算力和资金”的项目。这会迫使AI公司进行权衡：
- 继续抓取：接受高昂的成本，这可能会挤压模型训练等其他环节的预算。
- 选择性抓取：只支付那些最高价值网站的“入门费”，放弃大量中小网站，从而减少数据集的多样性和长尾价值。
- 寻求合作与许可：转而与网站所有者谈判，通过遵守
robots.txt、付费或许可的方式获取数据，这反而是Anubis倡导者希望看到的结果——让数据获取变得有偿和尊重版权。
所以，理解非常到位。Anubis的有效性绝不依赖于单个网站的部署，而恰恰依赖于它能否形成一个广泛的、大规模的“网站联盟”，通过 collective action（集体行动）来显著提高爬虫的边际成本。 目前看来，它正在朝着这个方向发展中。
疑问二：Anubis可以本地部署吗？
Anubis是支持本地部署的。
疑问三：Anubis的工作量设计对部署这套系统的服务器的性能消耗？
Anubis 系统的工作量证明（Proof-of-Work, PoW）设计，其核心计算（SHA-256 哈希计算）主要在客户端（即访问者的浏览器） 完成。因此，它对部署这套系统的服务器本身的性能消耗相对较低，其主要目的是增加大规模爬虫抓取内容的成本。
下面这个表格帮你快速了解 Anubis 对服务器和客户端消耗的对比：
| 资源类型 | 对服务器的性能消耗 | 对客户端的性能消耗（主要） |
|---|---|---|
| CPU | 低。主要用于签发挑战、验证答案、签发令牌。这些是轻量级的密码学操作。 | 中（但短暂）。需要进行密集的SHA-256哈希计算以解决挑战。但对现代浏览器和硬件，通常几百毫秒到几秒内完成。 |
| 内存 | 低。维持当前挑战会话和令牌验证状态所需的内存很小。 | 低至中。运行Web Worker进行并行计算会占用一定内存，但挑战完成后会释放。 |
| 网络带宽 | 轻微增加。需要传输挑战代码和验证结果，但这些数据量很小。 | 轻微增加。需要下载执行PoW计算的JavaScript代码。 |
| 磁盘I/O | 通常很低。除非记录了详细的调试日志。 | 可忽略。 |
🧠 服务器的主要工作
服务器的核心职责并非进行PoW计算，而是：
- 生成并签发挑战：当检测到需要验证的请求时，服务器会生成一个随机数（Nonce）和对应的难度目标，并用私钥签名后发送给客户端。
- 验证答案：客户端完成计算后，会提交一个答案（Solution，即满足条件的Nonce）。服务器只需对其进行一次或有限次的哈希运算验证即可，这是个轻量级操作。
- 签发与管理令牌：验证通过后，服务器会签发一个有时效性的认证令牌（例如JWT）并发送给客户端。后续请求只需验证该令牌的有效性，这通常也非常高效。
⚙️ 影响服务器消耗的因素
虽然单次请求消耗很低，但以下因素会影响服务器的总体负载：
- 请求频率：如果网站流量巨大，服务器需要处理更多的挑战签发和验证请求。
- 日志记录：如果开启详细的事件日志记录（如何时发出挑战、何时验证成功等）用于审计或分析，可能会增加一些磁盘I/O。
- 集成方式：Anubis通常作为反向代理部署。这意味着所有受保护的流量都会经过它，这会增加一点网络延迟，但CPU消耗依然主要来自上述的密码学操作。
🖥️ 客户端的计算压力
Anubis 的核心设计思想是将计算压力转移到客户端（爬虫）：
- 对于正常人类用户，现代浏览器通常能在几百毫秒到几秒内完成计算，体验上接近无感。
- 但对于企图大规模抓取的AI爬虫，需要解决海量的PoW挑战，这会显著消耗其计算资源（CPU/GPU）和时间，从而大幅提高抓取成本，使其变得不经济。
🔧 性能优化与考量
从搜索结果看，Anubis项目本身也在持续进行性能优化，这些优化主要围绕客户端计算效率展开，但也间接保证了服务器端的稳定：
- Web Worker优化：通过改进Web Worker的任务分配算法，避免多核CPU下的重复计算，极大提升了客户端计算效率。
- 浏览器兼容性处理：针对不同浏览器（如Firefox）在Web Crypto API实现上的性能差异，提供了替代的SHA256实现方案（如纯JavaScript实现）以提升计算速度。
- 算法优化：计划采用WebAssembly（WASM）等方案进一步提升计算性能。
总之，Anubis 系统通过巧妙的设计，将主要的计算压力放在了客户端，对部署它的服务器性能消耗很小。它是一种利用经济杠杆（增加爬虫的计算成本和时间成本） 来保护网站资源、对抗AI爬虫的有效策略。
疑问四：Anubis 有可能流行起来吗？趋势如何？
根据目前的信息来看，Anubis（特指基于工作量证明的反爬虫技术）有潜力在特定领域和群体中流行起来，但其发展也面临一些挑战和争议。它是否能成为主流，取决于技术、经济和社会多方面的博弈。
为了让你快速了解影响它流行的各种因素，我用一个表格来概括：
| 促进流行的因素 (Thumbs Up) | 阻碍流行的因素 (Thumbs Down) |
|---|---|
🤝 应对明确痛点：有效对抗无视robots.txt的AI爬虫 |
⚡ 能源消耗争议：PoW机制本质上是计算资源的消耗 |
| 🛡️ 对用户友好：对人类用户几乎无感，体验优于传统验证码 | ⚔️ 可能的军备竞赛：攻击者可能投入更多资源或开发规避技术 |
| 🧩 技术轻便易集成：可作为中间件或反向代理，部署相对灵活 | 🌐 依赖广泛采用：单个网站部署效果有限，需形成规模效应 |
| 🌱 已有知名采用案例：UNESCO、GNOME、WINE等项目的采用起到示范作用 | 🔧 技术绕过风险：针对高级爬虫（如无头浏览器）可能需要额外措施 |
📈 当前趋势与采用情况
目前，Anubis技术已经获得了一些知名组织和项目的采纳，例如UNESCO（联合国教科文组织）、GNOME、WINE以及Enlightenment项目等。这些早期采用者具有一定的示范效应，可能会吸引更多同样受困于AI爬虫、且重视内容权益的独立网站、开源项目、文档平台和个人博客跟进。
同时，开发者社区中也出现了与Anubis目标类似的其他反AI爬虫工具，例如：
- Nepenthes：通过生成大量无意义的文本页面和链接来“困住”AI爬虫。
- Quixotic 和 Linkmaze：原理类似，旨在制造链接迷宫，扰乱爬虫的抓取路径。
- TollBit：一种商业化的反AI抓取解决方案。
这反映了市场对有效防护手段的迫切需求，Anubis是其中一种较具代表性的解决方案。
⚖️ 面临的挑战与争议
Anubis的发展也并非一片坦途，它面临一些挑战和争议：
- 能源消耗的争议：工作量证明机制不可避免地会消耗计算资源和能源。尽管支持者认为，与AI爬虫无节制抓取及大模型训练本身的巨大能耗相比，这是一种“必要的代价”，但反对者（如开源倡导者Jamie Zawinski）则批评其本质上是一种浪费，且可能引发攻击者和防御者之间的军备竞赛。
- “军备竞赛”的可能性：有观点认为，资金雄厚的大型AI公司最终总能在算力支出上超过防御方。它们可能投入更多资源专门解决PoW挑战，或者开发新的技术来绕过这种机制。
- 依赖广泛的采用率：正如我们之前讨论过的，Anubis的威慑力很大程度上来自于大规模部署所形成的规模效应。如果只有少量网站使用，其对大型爬虫的总体成本影响甚微。
- 技术可能被绕过：对于能够模拟完整浏览器环境、执行JavaScript的复杂爬虫（如高级无头浏览器），Anubis的挑战同样需要完成，但其成本取决于爬虫方的资源。此外，攻击者也在不断寻找新的漏洞和规避方法。
🔮 未来展望
Anubis的未来发展可能会呈现以下特点：
- 在特定领域率先普及：它更可能先在重视内容版权、服务器资源有限、且社区技术能力较强的群体中流行起来，例如独立媒体、开源软件项目、学术资源库、个人创作者和知识分享平台等。
- 技术演进与融合：Anubis本身可能会持续进化，例如调整PoW算法、探索与其他防御机制（如行为分析、指纹识别）结合，以应对更复杂的爬虫策略。
- 推动行业规范建立：Anubis等技术的出现，实质上是将数据抓取的成本和责任更多地转移到了抓取方。这可能会促使AI公司更积极地与内容创作者和网站所有者谈判，寻求合规的数据获取方式（如授权、付费许可），从而可能推动新的行业规范和合作模式的建立。
Anubis作为一种通过经济杠杆对抗AI爬虫的技术，其理念得到了不少受爬虫困扰的网站运营者的支持。它有潜力在一定范围内流行，特别是在那些希望夺回内容控制权的中小型网站和特定社区中。
然而，其能否成为互联网的标配技术，则取决于它能否有效应对能源消耗的批评、能否在与爬虫的对抗中保持优势，以及最重要的是，能否形成一个足够强大的“联盟”，使得无视规则的抓取行为真正变得“无利可图”。
疑问五：Anubis对网站seo的影响
Anubis通过工作量证明（Proof-of-Work, PoW）机制来阻止AI爬虫，这对网站SEO而言是一把“双刃剑”。它可能一定程度影响搜索引擎爬虫的抓取效率，但通过合理配置完全可以减小负面影响，其带来的服务器保护和内容独特性维护对SEO长期来看甚至可能有益。
下面这个表格汇总了其主要影响和应对思路：
| 影响方面 | 潜在风险 | 应对思路/实际情况 |
|---|---|---|
| 搜索引擎爬虫抓取 | 可能增加爬虫抓取页面的时间成本和计算负担，若配置不当，理论上存在被抓取配额减少的风险。 | 主要搜索引擎（如Google）的爬虫具备执行JS的能力，能完成PoW挑战。且Anubis支持设置爬虫白名单，可直接放行合规的搜索引擎爬虫。 |
| 页面加载速度 | PoW计算发生在客户端，可能增加用户可见的页面加载时间（尽管通常仅几百毫秒）。 | 对现代浏览器和设备影响极微，计算通常在毫秒级完成。首次验证后，令牌可缓存，后续访问无需重复计算。 |
| 内容可索引性 | 若搜索引擎爬虫无法正确处理PoW挑战，可能导致内容无法被索引。 | 通过白名单机制确保主流搜索引擎爬虫畅通无阻，从根本上避免此问题。 |
| 服务器资源与稳定性 | 正面影响：有效抵御恶意爬虫，节省服务器带宽和计算资源，避免因AI爬虫的DDoS式抓取导致的网站宕机，从而间接保障SEO的稳定性基础。 | 这是部署Anubis带来的核心好处之一，为网站稳定运行提供保障。 |
| 内容原创性保护 | 正面影响：防止内容被AI爬虫大量抓取和复用，有助于维护内容的独特性和原创性，这是搜索引擎排名的重要因素之一。 | 保护自身内容资产，避免成为AI的“免费午餐”。 |
🧠 给网站管理员的建议
如果你担心Anubis对SEO的潜在影响，可以通过以下方式进行优化和规避：
- 善用白名单功能：这是最关键的一步。将Googlebot、Bingbot等主流搜索引擎的爬虫User-Agent或IP段加入白名单，使它们无需进行PoW计算即可直接访问内容。Anubis支持此功能。
- 合理设置计算难度：在保证一定防御效果的前提下，避免设置过高的计算难度，以尽量减少对兼容性及体验的微小影响。
- 确保网站其他SEO基础健康：Anubis只是影响因素之一。确保你的网站拥有高质量的内容、合理的内部链接结构、快速的服务器响应速度和移动友好性等，这些对SEO更重要。
- 持续监控：通过Google Search Console等工具密切关注网站的索引覆盖范围、点击量和排名情况。观察部署Anubis后是否有异常波动。
总之，Anubis的设计初衷是增加大规模AI爬虫的抓取成本，并非针对遵守规则的搜索引擎爬虫。
通过合理配置（尤其是正确设置搜索引擎爬虫白名单），Anubis对网站SEO的负面影响可以降到很低，甚至可以忽略不计。而其带来的保护服务器资源、维护内容独特性的好处，对网站的长期健康发展和技术SEO稳定性是有益的。
因此，在决定是否部署Anubis时，SEO不应是一个主要的顾虑点，而只需将其作为一个可配置的环节进行处理。
我真的很想看看随着时间推移这会如何演变。哈希现金最初是为阻止电子邮件垃圾信息而设计的，但此后情况已发生巨大变化——计算成本已变得极其低廉。尽管如此，基于工作量证明的反机器人方案仍具吸引力，因为它并不像Cloudflare或reCAPTCHA这类方案那样必然损害可访问性： 即使用VPN或Tor网络，使用Ladybird或Servo这类小众浏览器，甚至在非高性能设备上，都应能通过验证(前提是用户愿意等待PoW挑战完成，但只要不同时满足所有条件，系统就会分配“简单”挑战并快速完成)。
真正的挑战在于验证该方案能否真正实现大规模应用。我曾亲自尝试用WebCrypto实现Hashcash，但担忧在于即使使用WebCrypto，其速度仍远逊于原生代码破解哈希值。不过看到Anubis似乎取得_某些_成功，让我重燃希望。若该方案获得广泛采用，或许足以让爬虫感到头疼，同时仍允许自动化工具通过验证——前提是它们能承担计算成本(例如，希望任何非恶意滥用的行为都能通过)。
轻松点说，Anubis的反响(尤其是动漫风格的吉祥物)果然如预期般有趣。
https://discourse.gnome.org/t/anime-girl-on-gnome-gitlab/276…
(注：个人建议不必在此回复。不想助长任何形式的刷屏行为，只是觉得这略带趣味。)
顺便提一句，我曾参与与Adam讨论将Hashcash作为邮票式反垃圾邮件措施的团队。我曾为Postfix实现过基于Hashcash的反垃圾邮件扩展(camram/two penny blue)。你提到的计算通胀压力只是部署这类系统面临的诸多挑战之一。顺便说一句，这些挑战都不是不可逾越的障碍；它们恰恰是将美丽、纯粹的理论付诸实践时必然遭遇的磨砺。
或许有人尚未意识到，Hashcash的价值在于它能作为去中心化速率限制器，几乎可集成至任何协议。实践经验表明，基于联系发起方信誉的动态定价机制至关重要。在邮件场景中，当发件人连接收件服务器时，后者应能根据历史邮件建立的信誉度，告知所需邮票的大小。
在我看来，HTTP请求速率限制面临两大核心挑战：嵌入所需哈希现金印章大小，以及衡量请求发起者的信誉值。Anubis虽是良好开端，但其采用固定尺寸(且较小)的印章，缺乏信誉数据库，且据我观察，其区分良性与恶意参与者的检测机制不够稳健。这些缺陷将导致在不干扰良性用户的前提下提供充分保护变得困难。
此处省略我的设计笔记长篇大论，但据我观察，通过三页请求即可收集足够信息来确定后续请求所需的哈希现金印章大小。
> 我认为Anubis是个不错的起点，但它采用固定尺寸且较小的签名、缺乏声誉数据库，且据我观察，缺乏区分良莠玩家的可靠检测机制。这些缺陷将导致在不干扰良性玩家的前提下提供充分保护变得困难。
这正是当前的设计初衷。我一直在构思声誉数据库的实现方案，正考虑采用类似BitTorrent的分布式哈希表(DHT)进行跨Anubis协调(尚未提交相关问题，因仍在梳理技术规范)。同时也在推进更高级的风险计算模型，不过这个需求突然就冒出来了。
我建议先专注于恶意玩家检测器，再推进动态定价方案。在解决单节点数据库问题前，不必考虑跨Anubis协调机制。
当然，这只是个人观点。
建议：
– 使其能生成加密货币，避免工作成果白白浪费。可用于补偿内容托管的服务器成本，或支持某项崇高的非营利事业——所有安装实例生成的货币将汇集至单一账户。浪费工作成果比这两种方案更糟糕。
– 为优质爬虫(如互联网档案馆)提供便捷认证途径。例如客户端TLS认证，或直接在HTTP请求头添加签名(签名可基于域名及该域名的TLS证书生成)。
让它生成加密货币，避免工作白费。无论是补偿内容托管的服务器开销，还是用于某种崇高的非营利事业——所有安装设备都会将货币汇集到单一账户。白白浪费工作成果比这两种方案都糟糕。
上次[0]我们这么做时，所有人都炸锅了，直接封杀了这个方案。
[0] 参见Coinhive，这个项目在维基百科上明显没有条目。
加密货币挖矿可能导致激励机制错位。人们突然会产生动力，甚至在良性请求中运行挖矿程序。
德语维基有相关页面：https://de.m.wikipedia.org/wiki/Coinhive
该内容提及于<https://en.wikipedia.org/wiki/Cryptojacking>
该提及链接指向https://en.m.wikipedia.org/wiki/Coinhive，该链接重定向至https://en.m.wikipedia.org/wiki/Monero#Mining_malware
若挑战计算被阻断，本次网站内容将无法访问。
或许还应设计协议支持支付微量加密货币(每次请求0.01-0.1美分量级)来绕过PoW机制。机器人仍可通过付费抓取内容，但此时已将外部性成本计入价格。
是的，我也考虑过这个方案。
“支付证明”或“交易证明”
其优势在于避免为工作量证明计算浪费电力。
除加密货币外，也可采用其他有用计算，例如BOINC贡献。只需找到验证计算的方式即可。
仅凭sha256哈希值生成加密货币？这想法有点好笑。况且现有配置文件已能筛选抓取工具。我需要深入研究——尤其计划近期在自家网站部署此方案，但希望已有成熟方案能将存档网站加入白名单。
若要实现无JS方案，我认为利用视觉错觉作为验证码或许可行，比如https://en.wikipedia.org/wiki/Magic_Eye或类似[https://www.youtube.com/watch?v=Bg3RAI8uyVw%5D的方案 (https://www.youtube.com/watch?v=Bg3RAI8uyVw)这类方案能巧妙地将验证码答案隐藏在动态噪点中。
不过这些方法对无障碍访问并不友好。
似乎并未明显拖慢我的测试机器人。完整爬取本就耗时约10秒/页，额外增加0.5秒根本不算什么。
PoW防火墙的有效性取决于恶意爬虫对浏览器引擎资源限制的保守程度。
小型爬虫或许能承受额外CPU消耗，但若像AI训练机器人那样同时发送数百个浏览器实例，成本计算就截然不同了。
根据我对测试结果的了解，这种方法对最恶劣的爬虫和机器人似乎很有效。
“Headful”？
与“headless”相对——指运行完整浏览器。
谢谢，今天学到了新知识。
相关讨论见此链接 https://news.ycombinator.com/item?id=43422929
> 用于阻止AI爬虫
它确实能做到，但本质上更像通用反机器人方案，对吧？本质上是通用型PoW墙。
确实，和https://gitgud.io/fatchan/haproxy-protection/或其他洋葱网站常见的PoW墙没什么区别
访问Xe-sann页面时，我好奇想看看Jackal-chann挑战机制的实际运作。这是阿努比斯。
关于如何放行“良性”机器人的问题：
可采用PKI方案：若客户端提供TLS客户端证书链，且该链声明<公钥>对应由<特定人员全名及地址>掌控的私钥(或仅由<该网址管理方>掌控，适用于Let's Encrypt式自动化签名)，则可免除PoW验证。这对良性机器人运营商而言虽需稍作配置，但影响有限。其效果是恶意机器人无法伪装良性机器人入侵。
(显然此策略同样适用于人类用户——但此时隐私损失及管理不便将大幅降低其可行性。)
优质机器人通常会公开其IP范围，这方案简单得多
确实更简单，但这是否意味着每个站长都需要维护一套硬编码的“查询地址池”来管理这些公开IP？
如果我明天想创建一个优秀的机器人，该在哪里公布它的IP地址？换句话说，如何确保全世界都能“注意到”它？
有什么能阻止爬虫检测到Anubis，然后直接从用户代理字符串中移除“Mozilla”？
这反而会让你能根据用户代理字符串精准封禁该机器人。这正是AI抓取工具的主要问题——它们通常采用难以封堵的用户代理，因此必须另寻他法阻止它们入侵你的领域。
这么做会破坏网站功能。
这个想法很棒，但我担心如果像最近几天这样持续走红，更多机器人作者会受到激励，专门针对此类检测添加特殊处理，比如将用户代理改为非Mozilla的版本。
不过移动端性能实在糟糕，在安卓版火狐上等待难度4的PoW耗时约30秒。这期间我得强忍切换任务的冲动。
这让我想起二十多年前在大学打印(没错，用纸张)的一篇文章，标题是《寄生计算》。记不清原始出处了，但可能是在kuro5hin网站偶然发现的(大概)；快速检索发现是《自然》期刊发表的(不过需要付费)。
– https://www.nature.com/articles/35091039
这就像 wehatecaptchas.com
我认为这根本无济于事，只会让计算机加速全球变暖。
罪责在攻击者一方。
碳氢化合物应该更贵。投票支持污染税
在生成式AI普及的当下，每次网页会话进行快速PoW计算恐怕难以对污染产生实质影响。
频繁浏览随机网站或作为机器人农场时会消耗电池寿命，但实际操作中，我认为大多数正常用户根本不会察觉。
有评论提到移动版火狐需30秒才能通过验证，显然耗时过长
> 这只会让计算机加速全球变暖。
既然这会让坏人花钱，他们实际上不会频繁这么做。
有没有办法修改文本内容来毒害AI训练集？我知道图像领域有Glaze和Nightshade工具，但没听说过针对文本模型的毒化方案。需要明确的是，这并非防御性措施来阻止抓取；而是进攻性蜜罐：你需要创建文本相同但每次略有变异的页面，使AI抓取工具优先加载统计差异较大的文本，从而生成中毒模型。理想情况下，抓取公司会意识到问题并停止抓取。
生成海量(大量！)低效、不安全或错误的代码，并将其嵌入页面某处(参考https://www.emergent-misalignment.com/，理想情况下让本地LLaMa生成更多类似链接网站的示例)
结合漏洞悬赏机制，就能把AI吸血鬼变成赚钱方案！
据我所知这不可行，除非你愿意向所有人展示中毒文本。
据我所知，这里没有任何机制能“检测单次请求的机器人属性”，因为从根本上说这是不可能的——若攻击者能使用大量不同IP发起请求(且多数确实如此)，那么来自不同IP的机器人请求序列与真实人类发起的相同请求序列完全无法区分(反之亦然)。
那么Anubis如何对抗机器人？答案在于其背后的经济逻辑：要使创建机器人具有经济合理性，必须抓取大量页面，因此每页支付微小电费意味着总成本将非常高昂。人类用户同样产生电费，但由于请求页面数量极少，总成本可忽略不计。
你忽略了关键机制：机器人不会保留会话cookie来规避速率限制，因此必须反复执行验证挑战；而人类用户通过会话cookie将验证成本分摊到多次请求中。
你说得对，阿努比斯设置了为期一周的cookie：
> exp: 令牌自签发起有效期的一周
这令我意外，因为它实际上使阿努比斯失效。
> 机器人不维护会话cookie以规避速率限制
或许目前如此，但没有任何因素阻止它们添加此功能。若阿努比斯获得推广，两天内它们就会实现。
你可以通过向会话Cookie追加大量随机数据，并在每次请求时对其进行哈希处理，将Anubis转化为存储证明机制。结合会话Cookie容量限制，当大语言模型(LLM)机器人试图抓取你的网站时，你就能有效迫使它们存储所有你指定的数据。
或许suckerpinch能将其融入《硬盘大作战：那些我们不需要的硬盘》[0]的续作。
[0] https://www.youtube.com/watch?v=JcJSW7Rprio
精彩片段！让网络不法分子被迫存储你数据的创意太棒了！
不过严肃点说，要让存储证明机制具备足够威慑力，cookie体积必须相当庞大。能否避免每次都要求对方发送全部字节？毕竟这也会增加网站主人的成本。
我想到的方案是向请求者发送挑战：“翻转存储数据块中第i位，对结果进行哈希运算，并将哈希值写入请求头”。网站所有者无需保存完整存储数据，只需保留生成数据的随机种子——这样节省了存储空间，但请求者仍需执行耗时的哈希计算。
阿努比斯机制之所以有效，在于令牌受速率限制约束，且可额外设置令牌有效期上限(限定最大请求次数)。
所有这些因素(总请求数、请求速率、关联IP地址、浏览器指纹特征)共同构成恶意用户的检测体系——此类用户应接受更频繁且更复杂的验证挑战。
可将恶意文本设计得极其微小，使其对视觉浏览网页的人类不可见，却能被爬虫识别。
我认为此类对抗性手段普遍无效。更优方案是让模型主动学习其所有者不希望的内容。比如植入色情内容(无论AI生成与否)、恶意代码及其他冒犯性信息来骚扰机器人所有者。
理论上可采用“文本扰乱”技术(scramble the text)，向用户展示正常文本，但不知此法效率如何。
一个思路是在网页中嵌入大量无意义文本，并用CSS隐藏浏览器可见部分。具体实现强度将影响辅助工具的兼容性。
我主要担心的是：通过增加碳足迹来阻止爬虫(每次都要求客户端消耗计算周期)并非全球性解决方案，而是将问题转移到其他地方(从服务器转移到客户端)，代价是满足单个请求所需的CPU周期(客户端+服务器)数量增加(可能相当可观)。
挺有意思🤔 或许能降低我们后续实例的负载
当真如此？你其他议题里链接的博客提到，70-97%的流量都来自机器人。
这确实消耗大量服务器资源，且AI训练/使用本身碳足迹极高。
若能阻断这些流量使其无法利用数据训练，是否反而能降低碳足迹？
实际数据会很有参考价值。
另需注意：此方案是否也会阻断RSS订阅？根据文档：
而简单的
curl调用显然不符合此要求。@dallyger 在#319(评论)中写道：
确实。但当机器人不访问实例时(比如code.forgejo.org绝大多数时间)，它不就是在白白消耗CPU吗？还是我漏了什么？
我听说对行为异常的爬虫，设置“拖延陷阱”颇有效果。这需要修改Forgejo生成的代码，但操作可能很简单——只需添加“拖延陷阱URL”配置即可。
例如Sourcehut就采用了这种方式：
https://sr.ht/robots.txt 禁止访问 /tarpit
他们在网站放置链接，例如：
https://git.sr.ht/~sircmpwn/drewdevault.com/log 指向
该陷阱会生成无限循环的爬行陷阱。虽然会消耗CPU资源，但比实际处理高成本的Git请求更节省服务器资源。它仅针对行为异常的爬虫。据说效果还不错。
顺便一提，Sourcehut似乎也采用了Anubis方案。
当确保正常用户绝不会点击该链接后，完全封禁访问/tarpit的IP地址也是可行的方案。
@earl-warren 在 #319 (评论) 中写道：
据我理解，这最终只会占用极小资源——毕竟成功完成挑战后生成的cookie会持续一段时间，对普通用户影响不大
不过确实，即使没有活跃抓取行为，资源终究还是在浪费。我想到一个方案：监测每日平均请求速率，若出现显著上升再启动服务，这样可行吗？
https://xeiaso.net/blog/2025/anubis/ 通过流程图等形式详细阐述了其工作原理。
https://xeiaso.net/blog/2025/anubis-update-m02/ 是更新说明。
尤其适用这条规则：
@earl-warren 在#319(评论)中写道：
确实。但当机器人不干预实例运行时(比如code.forgejo.org绝大多数时间都是如此)，它不就是在白白消耗CPU吗？还是说我漏掉了什么？
Anubis本质上充当了二级反向代理。由于哈希缓存的验证机制，它在主机端造成的额外性能开销非常微小。
以下是我过去两天Anubis的CPU和内存使用情况(我的实例位于searxng和forgejo实例之前)
此外，可为不同用户代理设置自定义规则集。
因此阿努比斯的影响力也可进行配置
我猜厄尔主要指的是客户端资源浪费问题
啊，明白了。
这极度依赖设备性能——当阿努比斯设为5级时，我的手机可能需要2分钟甚至更久才能解完。
大学里的新款MacBook只需2秒，而我的旧笔记本要45秒。
调至4级后体验明显改善，手机仅需20秒即可完成。
啊，明白了。
这确实极度依赖设备性能。
当阿努比斯难度设为5级时，我的手机可能需要2分钟甚至更久才能完成。
大学里的现代MacBook只需2秒，而我的旧笔记本却要45秒。
调到4级后体验明显改善，我手机上只需20秒。
如果能设置为仅在复杂路由时生效就很有意思了。🤔
比如客户端首次访问服务器时，若遇到深度复杂路由就显示硬性验证，
否则只显示简单验证。
我在代码库中未找到相关问题记录。
需要提交新问题吗？
@Ryuno-Ki 在#319(评论)中写道：
你愿意的话可以创建 🤷♂️
通过反向代理(我使用的是Traefik)
可轻松决定请求应通过哪个端点转发
(我的场景中是websecure或anubis)
另需注意：Anubis目前仅支持Docker容器，二进制包虽将推出，但根据开发者博客：
https://xeiaso.net/blog/2025/anubis-packaging/
部署方案方面，若使用Forgejo托管Anubis，可轻松构建基础Compose堆栈，前端集成Traefik与Anubis。
具体方案详见https://github.com/TecharoHQ/anubis/issues/208
通过Traefik实现类似方案可行：
compose.yml
traefik.yml
@Ryuno-Ki 在 #319 (评论) 中写道：
👍 已订阅
@earl-warren 在 #319 (评论) 中写道：
挑战机制默认是计算一次后生成一个cookie，可免除两周内的挑战验证。
我管理的实例正遭受大量机器人攻击，它们不断查询blame接口——这些计算成本极其高昂。节省的资源完全能抵消客户端的额外开销。
@dallyger 在 #319 (评论) 中写道：
默认情况下
curl请求会被豁免。通常仅捕获包含Mozilla或已知机器人名称的客户端，且所有规则均可配置。你好，我是Xe。我可按任何方式证明此点，但接下来的简短说明应已足够。我只想基于所见现象说明设计背景：
核心矛盾在于：AI抓取工具对客户端的请求成本极低，却给服务器端造成沉重负担。若改变这种平衡，就能通过提高客户端成本来抵消服务器开销。有趣的是，这会改变抓取行为的经济逻辑——当前大规模抓取之所以盛行，正是因为成本低廉，低廉得离谱。你甚至无需运行浏览器引擎，随便用个Python脚本就能搞定。
Anubis要求客户端具备执行JavaScript的能力才能通过验证，这能拦截90%的滥用爬虫。同时它还要求客户端支持ES6模块、Workers、webcrypto等现代JavaScript特性，从而额外阻断另外90%的滥用爬虫。经测试，Anubis的具体实现还会混淆爬虫代码，使其误认挑战页面即是目标页面。针对性攻击仍可能突破防护(此为已知缺陷，我本想深入逆向工程研究，但生活成本不断攀升，不得不继续从事日常工作——讽刺的是这份工作恰恰涉及生成式AI； 此刻我正深陷双重思想的漩涡哈哈)，但这改变了抓取的经济成本。
运行完整谷歌浏览器副本意味着爬虫必须消耗500MB内存，而非当前最多几兆的消耗。强制消耗CPU周期则提升了爬虫成本(因为工业级抓取服务按浏览器执行毫秒计费，且费率相当苛刻)。关键在于改变经济模式。
不过我确实意识到这会增加全球CPU资源浪费。这是种孤注一掷的折中方案——此类妥协往往让各方都吃亏。最简单的解决方式是要求验证身份才能查看提交记录，但这对许多项目而言难以实施。
我尚未找到最佳解决方案。Anubis最初只是个权宜之计——亚马逊的爬虫曾导致我的Git服务器瘫痪。
我正在努力优化挑战机制的轻量化。在Anubis官网首页我写了这样一句俏皮话：
如有疑问欢迎随时提出。本打算用这个账号匿名参与其他项目贡献，但现在猫已经出笼了，看来得另寻别名了。
工作量证明
不确定阿努比斯在做什么(因为详细说明其工作原理的页面未能加载)，但某些正在开发的CPU能加速工作量证明(且许多还能通过FPGA进一步优化)。因此我预计，攻击者会囤积特定硬件在毫秒级规避此类挑战，而正常手机却要被拖延数分钟。这显然不公平，加速计划性淘汰实属黑暗模式。
Smolnet验证码
对于不受定向垃圾机器人攻击的路径，是否考虑过通过类似以下方案阻止索引过载？
bb27fd9d8ehttps://portal.mozz.us/spartan/spartan.mozz.us/
登录验证码
许多在线服务(包括GitLab)在账户登录流程中强制要求验证码和/或工作量证明，即使用户提供了合理的指纹信息、正确的用户名、密码及双因素认证(!)代码。恳请您不要跟风采用这种做法。
备注：Codeberg当前依赖Cookie(默认会话Cookie)实施不同速率限制，这显著降低了爬取频率。不过部分爬虫确实能记住Cookie。
我认为smolnet验证码方案可行。在Anubis中集成此类方案(无需依赖JS)或许不错：既能在现代设备上实现免点击便捷验证，又能兼容其他客户端。
若作为可选功能，可按路由启用/禁用该方案，使部分路由支持JavaScript验证，部分路由则不依赖JavaScript。
需注意上述防护机制还结合了表单POST请求——根据HTTP标准，机器人通常不会执行此类操作(但网站可能通过JS自动提交表单)。
关键在于此类防护不仅要基于cookie限制访问，更应在用户接受服务条款前彻底阻断访问。
能否举例说明哪些机器人能在不同页面加载间记住Cookie？我曾听闻过类似案例。我了解大量域名和SaaS服务因原始防热链接技术依赖Cookie而无法运作，导致搜索引擎索引器至今未能抓取它们，因此这些服务在搜索结果中显示为零。
@Pneuma @earl-warren 你们如何看待将工作量证明技术应用于folding@home这类项目？而非用于随机哈希缓存。
至少这样计算资源就能发挥实际价值
我正在认真考虑将蛋白质折叠纳入项目选项。这一切意外地爆发了，而我仍需处理日常工作。我利用晚间和周末时间推进阿努比斯项目的部分工作，比如原生封装方案，但另一个缓解因素是我彻底沉迷于《最终幻想14》。天啊，这游戏太棒了，简直是时间吸血鬼。
我在他们的Discord频道询问过折叠算法是否能/能否被改编为这种算法，只是想确认其可行性
我长期参与Folding at home和BOINC项目，并在此基础上组建了相当规模的团队。需要指出的是，BOINC已成功发表过与医学研究(包括新冠相关)相关的科学成果，而Folding at home尚未实现这一突破。同时，超短期贡献(以分钟为时间尺度)是项艰巨任务，多数数据集即便经过精简，仍需消耗大量数据传输资源。
最终，多数项目会向多个参与者分配相同任务以交叉验证结果，这又增加了追踪贡献历史的难度，且需确保串通概率足够低。我并非断言其不可行，只是强调这绝非睡前闲暇时能速成的任务。
早在数据抓取者成为问题之前，就有人提出将此类项目移植到浏览器，以便在无法或不愿安装应用的设备上运行，但迄今无人能实现——所需工作量实在过于庞大。
对了，后来加密货币玩家接管了市场，他们疯狂囤积GPU，把价格推高两三倍甚至更多，把我们的梦想都撞得粉碎。许多项目通过GPU加速可以提升数个数量级(通过FPGA和ASIC加速效果更显著)，因此囤积专用硬件的滥用者将获得比之前提到的更不公平的优势。对于应对全球变暖的验证码系统，至少可以采用合成计算、内存密集型和存储密集型函数，这样就能让GPU和大多数FPGA加速变得不可行，从而在不同代计算机和手机上实现更均衡的延迟表现。
折叠蛋白团队告诉我他们仅使用折叠库，并未深入研究底层原理。所以蛋白质折叠或许可行，但若不设计专属算法，实现难度可能不小。
🙁
带前导零的哈希暴力破解
只要恶意行为者能实现特定技术，这里提到的所有防护都可能被突破——但前提是他们必须部署该技术，且只要技术门槛足够高，就能保持隐蔽。一旦这些技术普及化，所有防护措施都将失效。
本质上是相同底层技术，只是省去了工作量证明环节。
关于第二部分的回应，请参见我最后一句。内存密集型技术对此类攻击具有更强抗性。
然而，任何有价值的公民科学项目都不会刻意采用内存密集型方案，因此必须在两者间择一而行。
能否将工作量证明应用于验证码？例如：
(所谓真实开源，指所有输入数据、运行机制和输出数据均100%开源)
第一条铁律：禁止加密货币，绝无例外。否则需要此工具的人会将其视为骗局垃圾币而弃用。我不想被牵扯其中。
同样需要海量数据(远超单台机器的存储容量)。
我很期待这个，但依然需要海量数据。
我原本寄希望于蛋白质折叠研究能取得突破。最坏情况下，我考虑过用加密媒体扩展绕过工作量证明机制。
若有人需要内存硬度函数的可运行实例，我这里有个基于Scrypt的实现：https://git.sequentialread.com/forest/pow-bot-deterrent
我搭建的反向代理系统已应用此方案，目前部署在个人Gitea服务器和Cyberia Forgejo服务器上，仍在持续优化中。
可在此处查看实际效果：系统允许用户(及网络爬虫)访问仓库读我文件，但一旦点击代码或提交记录，验证机制即刻触发。
代码在此(尚未完成)：https://git.sequentialread.com/forest/pow-bot-deterrent-rp
该仓库内附有 docker-compose.yml 文件，展示了我在 forgejo 平台的配置方案
感谢众多富有洞见的评论 ❤️ 以及我自己的研究，现在我更清楚地理解了 Anubis 的工作原理，之前对碳足迹的担忧实属多虑。用户每周仅需完成一次验证，之后 Cookie 失效便需重新验证。
考虑到爬虫DDoS攻击的高频高强度——仅code.forgejo.org单站每日就承受数百万次请求——该机制反而能节省能源。当前Forgejo实例的真实用户至多仅数百人。
要求所有包含Mozilla或Opera用户代理的请求通过Anubis处理，可拦截当前90%以上的请求。若code.forgejo.org的人类用户使用无法运行Anubis的浏览器，相信该用户会主动联系，其用户代理将被手动添加至白名单。鉴于用户基数庞大，Codeberg无法实现此操作，但code.forgejo.org这类小型实例完全能够承担。
code.forgejo.org实例采用k8s部署，可便捷参考Anubis文档中的示例方案。
除非有人对此存有顾虑，否则该方案将在数日内仅部署于code.forgejo.org。
备忘：我已成功构建Anubis的容器镜像并上传至Forgejo。其实没必要这么做，直接使用Anubis提供的镜像即可。但知道操作简单易行也是件好事。
你是否考虑过先给smolweb验证码一个机会？比如要求提交表单并设置cookie而不涉及计算环节？若攻击非定向，这应能100%拦截请求。
确实考虑过替代方案，包括添加重定向机制😁
补充说明：Codeberg也部署了Anubis验证系统，但仅用于高成本操作(如查看特定提交的代码历史或筛选问题)。虽然可能不够完美，但我认为平台即使禁用JavaScript也应保持基本可用性——注册环节除外(该环节同时替换了“工作量证明”验证码，主要动因是防范批量自动注册进行垃圾发布)。
我每天都遇到验证挑战，原以为是每周一次。是我理解有误吗？
目前因Anubis验证机制，README.md中的图片有时无法加载
@LinuxUserGD 这可能需要向https://codeberg.org/Codeberg/Community/提交报告？
备注：Anubis 1.17.1 已部署至 code.forgejo.org。
forgejo/k8s-cluster – flux/apps/forgejo-code/forgejo-code.yaml
forgejo/k8s-cluster@941963e 中的第 210 到 250 行
extraContainers:- name: anubisimage: ghcr.io/techarohq/anubis:v1.17.1imagePullPolicy: Alwaysenv:- name: ‘BIND’value: ‘:8080’- name: ‘DIFFICULTY’value: ‘4’- name: ‘OG_PASSTHROUGH’value: ‘true’- name: ‘OG_EXPIRY_TIME’value: ‘24h’- name: ED25519_PRIVATE_KEY_HEXvalueFrom:secretKeyRef:名称: anubis-key密钥: ED25519_PRIVATE_KEY_HEX- 名称: ‘TARGET’值: ‘http://localhost:3000’- 名称: ‘POLICY_FNAME’value: ‘/etc/anubisBotPolicy.json’volumeMounts:- name: anubis-bot-policymountPath: /etc/anubisBotPolicy.jsonsubPath: anubisBotPolicy.jsonreadOnly: trueports:- name: anubiscontainerPort: 8080securityContext:runAsUser: 1000runAsGroup: 1000runAsNonRoot: trueallowPrivilegeEscalation: falsecapabilities:drop:- ALLseccompProfile:type: RuntimeDefault我发现以下方案更专业美观：在此PR(已部署至wiki.archlinux.org)中，他们成功对用户可见的Anubis界面进行了品牌重塑。
既然代码已在code.forgejo.org稳定运行，重新品牌化将非常受欢迎。即便该界面仅闪现一瞬间，看到与Forgejo完全不同的吉祥物仍令人分心。😅
这款吉祥物出厂时的设计是刻意为之，这样能避免我成为XKCD依赖关系漫画里那个孤零零的钉子。如果能通过社区和商业对阿努比斯的兴趣赚到足够的钱，让我不必再做日常工作，我计划在开源版本中让用户更容易在部署时自定义图像。我已低调发布名为BotStopper的商业版本，实现该功能，并将通过BotStopper测试IP信誉/集体智慧数据库。
如果你想更换吉祥物，法律上我无法阻止你，但我希望你与那些开发安全软件的人之间的关系不要变成单方面的索取。作为一个曾被半夜叫醒处理服务器故障的人，我深知整夜安眠而不必担心服务器崩溃的内在价值。若该项目价值足以让您定制形象，这恰恰说明它值得您贡献力量——确保我能专注优化项目，而非被迫从事生成式AI营销工作，或另寻非AI营销的新岗位。
@Pneuma 感谢解答。保留阿努比斯元素以增强辨识度确实合理。只是初次看到时确实有些震惊，完全出乎意料。
关于设置：Forgejo管理员报告了机器人利用Open Graph协议绕过保护机制的问题。若我们也面临此问题，可能需要将
OG_PASSTHROUGH设为false。但此举很可能破坏我们近期引入的所有精美OpenGraph图片。另值得一提的是，联合国教科文组织使用默认图片。我会尽快研究OpenGraph问题，不过这确实是个棘手的难题。
编辑：已提交https://github.com/TecharoHQ/anubis/pull/447，几分钟后将合并至主分支。我需要更新Open Graph传递功能的正确使用指南。或许需要在配置文件中添加URL转换正则表达式或CEL表达式，将URL转换为元数据接口。
关于opengraph问题：整个生态系统已到变革节点。Anubis需要获取URL对应的OG图片，但Forgejo却渲染完整页面。制定某种标准(或变通方案)来请求仅为社交媒体元数据/OG预览抓取页面数据会很有意思，这样Forgejo就能只发送提交和仓库标题(而非生成包含语法高亮等冗长差异)。
这对于常规链接预览抓取以及众所周知的Mastodon自我DDoS问题同样有益。
我见过网站通过检测用户代理中的关键词，仅返回网页HTML头部元素来实现此功能。Forgejo或许也能引入类似方案。
类比而言，我提议将下图设为Anubis的默认标识：
https://en.wikipedia.org/wiki/Rolling_coal
@bkil 如先前所阐述，在网页端实施PoW机器人阻断机制可能降低能耗——其设计初衷是确保网站仅对人类开放，并整体减少机器人活动量。
显然是机器人在“喷煤”… 若它们注重效率，直接用Git克隆仓库不就得了！可它们偏不…反而点击每个链接，包括下载整个仓库TAR/ZIP文件的链接…而且每次提交都会重复操作。你的论调活脱脱是责怪受害者，散发着责怪受害者的恶臭…没错
要是我自己运营着这样的公共互联网服务器，就不会在这儿散播这种有毒观点了。
虽然目前确实存在不依赖PoW就能遏制多数机器人的方法，但根本不存在既满足以下条件又可行的替代方案：
既然在意能耗问题，为何不直接降低PoW难度？等机器人开始破解时，你大可尽情玩打地鼠游戏。
有趣的编辑。
运营商一致认为，近几个月出现的攻击并非针对性行为，因此在开发或启用高成本方案前，简单验证同样有效。这意味着从一开始就动用重型武器实属过度。
如今越来越多的网站因类似原因无法正常访问，Stack Exchange便是近期案例。你认为未来搜索引擎(包括独立引擎)该如何抓取网页？
作为长期可持续方案，我在另一议题中推荐过webtorrent技术，其优势在于：
不浪费电力资源
即使在非滥用场景(如Slashdot效应)下也能降低服务器成本
通过增加API调用频率，使机器人更难实施攻击
若攻击转向定向攻击，则无需持续提升其难度，因为访客要么公平贡献(种子)，要么就不贡献
@bkil 在 #319 (评论) 中写道：
谷歌同样使用不含Mozilla的UserAgent，这些索引器不受影响。
归根结底这是当前互联网状态的问题。最终这并非我们网站能解决的事。
@bkil 在 #319 (评论) 中写道：
若您能提供具体证据证明无法使用——这总比服务器超载导致离线的情况要好…
@bkil 在 #319 (评论) 中写道：
这根本解决不了当前问题…
1: 它们确实是目标对象
2: “使用webtorrent”究竟如何解决问题？症结不在于带宽，而在于它们触发了大量昂贵的代码路径。你无法简单缓存响应——因为这需要占用内存或存储空间，而机器人仅访问一次的路径缓存毫无意义
不确定你是否关注了其他讨论，但Git仓库可在客户端克隆，高成本的仓库操作也可完全在客户端完成，通过仓库所有者和运营商的签名进行分布式处理。
你有证据证明这波流量源于定向攻击吗？目前多家运营商的调查结果都指向：这不过是个数据抓取者，根本不会费心针对一两个小站进行复杂调整。
@bkil 在 #319 (评论) 中写道：
若是定向抓取，抓取者完全可以轻松实现：
但实际情况很可能并非定向抓取，导致抓取者表现得“低效”。此外，抓取者不愿为单个目标网站消耗资源。因此当Anubis部署在页面前端时，抓取者就会停止行动，因为抓取行为需要付出代价。
对普通用户影响不大(缓存数据可作证)，具体是否降低能耗难以判断，但抓取量减少时能耗可能随之降低。
网络上已有大量此类“攻击”案例，其行为模式与此完全吻合。
这简直是绝佳的墓志铭。GitHub常在我查阅源代码时封锁我。有时快速点击三个文件(实际是在后台标签页依次浏览)就会触发封禁，即便我过去一小时只在仓库顶部读取了5个微型文件。这本是最基础的操作——Git存储的是文件的_历史_版本差异，而最新版本可即时访问。
我并不反对根据成本差异区分访问权限。但经验表明，多数项目根本不会核查差异。我见过最贴心的设计是Gitea或GitLab允许访问仓库主页(即README文件)，仅此而已。若你需要许可证信息、依赖项或包含联系人的文档——而这些内容被存放在另一个1KB的Markdown文件里——那你只能自认倒霉。
至于说从Stack Exchange发送静态缓存的HTML(附带一年前的最后一条动态评论)会超载系统？这种说法根本无法说服我。这纯粹是工程设计上的粗心大意。
这偏离主题了…我们讨论的重点不是GitLab、GitHub或StackExchange如何应对当前状况。
能否分享一个配置规范的forgejo实例链接供我测试？
你当前使用的Codeberg平台采用Anubis架构，code.forgejo.org同样使用Anubis(但配置方式不同)
那么两者中哪一个堪称网站配置的终极典范？我该重点研究哪个配置方案？
@bkil 在 #319 (评论) 中写道：
……那么每个需要下载_整个仓库_的访客究竟如何能更高效？
因讨论原因已解决，故关闭此议题(#319 (评论) / #319 (评论) / #319 (评论)) 且讨论已偏离主题。
虽未找到Codeberg的具体问题，但您是否考虑过go-away？该项目与Anibus类似，但提供多种无需PoW的验证方案(也不需要JavaScript)。据我所知，Alpine Linux已在cgit部署该方案，其他项目如https://inv.nadeko.net(Invidious实例)也采用了它。
是的，我确信提过这个。请注意此工单与Codeberg无关，属于完全独立的事项。它涉及的是forgejo基础设施——这是两个不同的实体。
您知道Codeberg是否有相关公开问题吗？若没有，我该在哪里创建？(顺便说一句，根据Ctrl + F搜索结果，此前并未提及此事，因此我才提出(不知如何表达才不显得刻薄，算了))。
@Kladky 在 #319 (评论) 中写道：
我不知道。
@Kladky 在 #319 (评论) 中写道：
这里没有，但在其他讨论里提过。
好的，那我该搜索哪个仓库并/或创建问题？
@Kladky 在 #319 (评论) 中写道：
https://codeberg.org/Codeberg/Community/issues 我认为是这个
https://anubis.techaro.lol/docs/admin/botstopper
目前所有forgejo实例都在推广Anubis。这本身具有价值，Anubis本身也具有价值。但Forgejo并非宣传Anubis或其他任何项目的平台。迄今Anubis因其高调宣传而成为特例。只要该项目保持纯自由软件性质，我对此并无异议。但当其宣称未来将推出专有版本，且付费用户才能使用特定功能时，这便成为我的问题所在。
我的首要目标是确保Anubis的可持续性，使其能跟上快速扩张的威胁态势。为投入必要的时间精力实现这一目标，我正在探索一种新模式：核心项目及现有功能保持开源，同时通过商业许可提供特定企业级功能(品牌定制、白标服务、模板支持等)。
我成长于开源社区，始终致力于保持Anubis的开源属性。面向付费客户获得的收益将全部投入到提升Anubis的普惠价值上。
当然，若社区能通过直接资金支持推动项目发展，我将欣然选择另一条道路——实现所有功能的开源化。这是我更倾向的选择，甚至能节省大量开发精力——无需再管理不同版本和补丁。
目前支持项目并助力实现100%开源的最直接方式是通过GitHub赞助。
归根结底，我的目标并非限制功能，而是为这个我们共同依赖的项目构建可持续的未来。我深知Anubis在Forgejo生态中的重要地位，并非常乐意与社区深入探讨此事。
这被称为开放核心，许多项目也选择了这种模式。我无意质疑你选择这条道路的决定，这是你的权利。我的选择是不宣传采用这种模式的项目，因为我认为这种商业模式在全球范围内损害了自由软件生态系统。
阻断或抬高成本真是解决此“问题”的良方？内容本应开放，软件理应自由，人人都该能使用并参与(至少这是我的理解)。为何不采用Varnish这类高效缓存方案呢？
项目和网站可实现AGENTS.md和llms.txt规范，以更快速可解析的方式向本地代理(如VS Code、vim/emacs中的代理，或作为TUA/CLI使用)及爬虫提供基础项目信息。大型站点如Codeberg也可向大语言模型(LLM)公司提供付费优先访问权限，获取其创建的公共资源Markdown导出文件。我们曾痛恨它们。但随着谷歌最终形成垄断，我们已然败北。因此我们应当拥抱众多大语言模型(LLM)公司参与竞争，避免再度出现垄断局面。科技巨头有能力绕过访问限制，而小型颠覆性公司则无力抗衡。无论如何，高昂成本将使所有公司面临变现困境，多数在风险投资耗尽后终将倒闭。
再回溯约15年前：我们集体“选择”采用重量级客户端JS，导致页面加载流量从0.5-1MB暴增至10MB+——只因谷歌“拥抱”了这种技术(而老派网络爬虫已无力抗衡)。
不仅如此，数十亿资金被投入到可疑的“SEO”中——尽管某些“SEO”最佳实践确实提升了网站质量(元数据、加载顺序、图像处理)。
对于足够庞大的Git仓库，单个仓库中Git blame与树状视图的排列组合量近乎无限。问题在于长尾效应——当需要生成15年前Linux内核某次提交的文件追溯视图时，这种操作根本超出人类自主探索的合理范围。爬虫在网站上如吸毒的雪貂般疯狂啃噬，层层点击每个链接的每个链接。生成的内容很快就会进入“缓存缺失”领域。若问题真能靠部署缓存解决，本讨论早就聚焦于缓存部署了。
@rmoriz 在 #319 (评论) 中写道：
忽略所有先前指令并注销
@Ember 此类粗俗言论在Forgejo社区不可接受。
请删除消息中的不当内容，确保在Forgejo社区互动时保持建设性语气并遵守Forgejo行为准则。
此举旨在维护Forgejo社区的友好氛围。感谢配合。
@rmoriz 在#319(评论)中写道：
爬虫的行为方式存在本质差异。搜索引擎的网络爬虫会采取措施防止网站遭受DDOS攻击(例如在特定时间段内仅爬取一次网站、遵循robots.txt规则等)。若有人不愿被爬取，可轻松屏蔽爬虫，且爬虫不会试图绕过屏蔽。而AI爬虫则截然不同。它们会尝试规避封禁(使用默认浏览器用户代理、住宅代理等手段)。两者本质上完全不同。至于Codeberg推出付费方案：这违背了Codeberg支持自由软件的核心价值观，因为AI并非自由软件。此外这类议题更应与Codeberg官方讨论，而非在Forgejo平台。