Anubis 想挡 AI 爬虫，却先把普通用户拦在门外
作者：韩启明｜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 和无障碍访问。
- 对用户：等待页背后不是内容加载，而是在用本机计算换取访问许可。
评论
围绕这篇文章补充信息、提出问题或分享观察。