作者：韩启明｜OC 政策与安全记者

开发者 Farid Zakaria 在访问 Linux 内核邮件列表时遇到 Anubis 工作量证明页面。他让 LLM 编写了 anubis-fetch，直接计算挑战或启动 Chromium 获取内容，由此提出一个问题：需要拦截的自动工具轻易适配，人类和非 JavaScript 客户端却持续承担访问成本。

一句话结论：Anubis 能提高低成本批量抓取的门槛，却不能识别访问者的真实目的；当专业爬虫缓存凭据、普通用户反复计算时，防护成本可能分配给了错误的人。

Anubis 是放在网站前的 HTTP 代理。访问者必须先完成哈希计算，服务器验证后才发放 Cookie。默认难度 4 需要平均约 65536 次哈希；作者测试原生 Go 求解约 1.3 毫秒，浏览器 JavaScript 约 130 毫秒，但加载和刷新让用户实际感受到 1 至 5 秒等待。

难度 5 的期望计算量上升到约 104 万次，作者测试浏览器约 2 秒，实际等待约 5 至 15 秒。以上是单台设备和特定实现的粗略测试，不是所有 Anubis 部署的统一性能。

对爬虫来说，开发一次求解器后可以自动执行，还能缓存 Cookie，把成本摊到大量页面；对偶尔访问的人，每个新会话都可能重新等待。文本浏览器、RSS 阅读器、部分屏幕阅读器和禁用 JavaScript 的用户甚至无法进入。

这不等于 Anubis 完全无效。它最初就是为了阻止不遵守 robots.txt、大量占用服务器资源的抓取器，工作量证明可以降低最粗糙的请求洪水。问题在于，它证明客户端花了计算，而不是证明对方是人、是否训练模型或会不会遵守内容许可。

韩启明认为，反爬应同时使用速率限制、缓存、身份验证、异常模式和明确访问政策。工作量证明可以是一层临时缓冲，但如果网站依赖它替代身份和用途判断，最终会伤害开放访问。

关键事实

• 来源：Farid Zakaria 实测、Anubis 开源项目
• 核心机制：客户端完成哈希工作量证明后获得访问 Cookie
• 测试结果：默认难度原生求解很快，浏览器与页面流程造成更明显等待
• 无障碍问题：无 JavaScript 客户端和部分辅助工具可能无法访问

OC 判断

Anubis 阻止的是低成本请求，不是 AI 本身。它适合保护被突发抓取压垮的小站，但必须评估对正常访问、移动设备和开放协议的副作用。

为什么重要

• 对开发者：反爬策略应按行为和速率设计，不能只按客户端计算能力收费。
• 对网站：工作量证明能争取资源，却可能减少搜索、RSS 和无障碍访问。
• 对用户：等待页背后不是内容加载，而是在用本机计算换取访问许可。

参考来源

• Farid Zakaria：Who does Anubis actually stop?
• GitHub：TecharoHQ/anubis