OpenWrt One：开源硬件路由器与反爬虫新防线——从Anubis验证机制看AI时代网站保护的困境

本文介绍了OpenWrt One开源硬件路由器，并深入探讨了其网站部署的Anubis反爬虫系统——一种基于工作量证明的验证机制，旨在抵御AI公司的大规模数据抓取，同时分析其对用户体验和技术生态的影响。

一、OpenWrt One：开源硬件路由器的定位与意义

OpenWrt One 是一款由 OpenWrt 社区推出的开源硬件路由器，旨在为开发者、网络爱好者和隐私倡导者提供一个完全可控、可定制的网络设备。与传统消费级路由器不同，OpenWrt One 的设计哲学强调透明性、安全性和长期维护：

• 硬件开源：其电路设计、固件源代码完全公开，允许用户审计、修改甚至重新设计。
• 系统开放性：默认运行 OpenWrt 操作系统（基于 Linux），支持丰富的软件包管理（如 VPN、防火墙、流量整形、网络监控等）。
• 社区驱动：由 OpenWrt 社区维护，不受单一厂商商业策略影响，确保长期安全更新和功能迭代。

然而，在尝试访问 OpenWrt One 的官方文档页面时，用户会遇到一个特殊的挑战——Anubis 验证系统。这并非路由器的功能，而是 OpenWrt 网站为了保护服务器资源而部署的反爬虫机制。

二、Anubis 验证系统：对抗AI爬虫的“工作量证明”方案

2.1 背景：AI公司如何改变网站托管的社会契约

文章开篇即指出，用户看到的“Testing to determine if you are a bot!”页面并非传统验证码，而是由 Anubis 系统生成。其核心背景是：近两年，AI 公司（如 OpenAI、Google、Anthropic 等）的爬虫程序大规模、无节制地抓取互联网内容，用于训练大语言模型（LLM）。这种行为导致：

• 服务器负载激增：大量并发请求占用带宽和计算资源，造成正常用户访问延迟甚至宕机。
• 资源消耗不公：网站运营者承担了 AI 公司的数据采集成本，但未获得任何补偿——这被描述为“改变了网站托管的社会契约”。
• 传统反爬措施失效：基于 IP 封禁、User-Agent 过滤、简单验证码（如 reCAPTCHA）等方法，对使用 headless 浏览器（如 Puppeteer、Playwright）的爬虫效果有限，因为爬虫可以模拟人类行为。

2.2 工作原理：基于 Hashcash 的工作量证明（Proof-of-Work, PoW）

Anubis 采用了类似 Hashcash 的 PoW 机制。Hashcash 最初由 Adam Back 在 1997 年提出，用于对抗电子邮件垃圾——发送者需要计算一个哈希值（如 SHA-1），使其前若干位为 0，从而消耗发送者一定计算时间。

在 Anubis 系统中：

• 挑战生成：服务器向客户端发送一个随机挑战（如一个字符串和难度参数）。
• 客户端计算：客户端（浏览器）必须找到一个 nonce（随机数），使得该 nonce 与挑战拼接后的哈希值满足特定条件（例如，哈希值的前 20 位为 0）。
• 验证：服务器收到 nonce 后，验证哈希条件是否满足。若通过，则允许访问。

关键特性：

• 对单个用户几乎无感：个人浏览器通常在几毫秒到几百毫秒内完成计算，延迟可忽略。
• 对大规模爬虫成本高昂：若爬虫需要抓取数百万页面，每页都需要一次 PoW 计算，总计算时间和电力成本将指数级上升，从而使得大规模抓取在经济上不可行。

2.3 为何需要 JavaScript 和现代浏览器特性？

Anubis 要求启用 JavaScript，原因在于：

• PoW 计算在浏览器端执行：通过 WebAssembly 或 JavaScript 高效完成哈希计算。
• 对抗插件干扰：某些隐私插件（如 JShelter）会禁用或修改 JavaScript 的随机数生成、WebAssembly 等功能，导致 PoW 无法正常执行。
• 未来方向：文章提到，长期解决方案是改进“headless 浏览器指纹识别”（例如通过字体渲染方式的差异来区分真实浏览器和自动化工具），从而让合法用户无需经历 PoW 挑战。但当前阶段，PoW 是“placeholder solution”（占位方案）。

2.4 无JavaScript方案的困境

文章承认，一个完全无 JS 的 PoW 方案仍在开发中。这反映了当前网络安全的一个矛盾：

• 反爬需求：需要客户端执行计算，这通常依赖 JavaScript。
• 无障碍性：某些用户（如使用屏幕阅读器的视障人士、禁用 JS 的隐私倡导者）可能被排除在外。
• AI 爬虫的进化：许多 AI 爬虫已经能执行 JavaScript 并模拟浏览器环境，因此纯 JS 方案并非万能。

三、技术细节与数据支撑

3.1 工作量证明的数学本质

以 Hashcash 为例，假设挑战字符串为 "challenge123"，难度要求哈希值前 20 位（bit）为 0。客户端需要遍历 nonce（如从 0 开始递增），计算 SHA-1("challenge123" + nonce)，直到结果满足条件。

• 概率：每尝试一次，成功概率为 2^(-20) ≈ 1/1,048,576。
• 平均尝试次数：约 100 万次。
• 时间消耗：现代浏览器（使用 WebAssembly）可在 100-500 毫秒内完成。
• 对爬虫：若需抓取 100 万个页面，则总计需要 10^12 次哈希计算，按每瓦时 1000 次哈希的能耗计算，成本显著。

3.2 与 reCAPTCHA 的对比

特性	reCAPTCHA v3	Anubis PoW
用户交互	无（后台分析行为）	无（后台计算）
隐私影响	需要 Google 分析用户行为（隐私争议）	无第三方服务，仅与服务器交互
对爬虫效果	基于行为模型，可被模拟	基于计算成本，难以绕过
无障碍性	支持盲人（音频验证）	依赖 JS，可能影响无障碍
部署成本	需调用外部 API	自托管，无外部依赖

3.3 实际影响与案例

文章提到，AI 公司的大规模抓取已导致多个网站（如 Stack Overflow、Reddit）采取极端措施（如收费 API、限制访问）。OpenWrt 作为社区驱动的项目，资源有限，无法承受爬虫带来的负载。Anubis 提供了一种低成本、自托管的解决方案：

• 服务器负载降低：PoW 挑战将计算压力转移至客户端，服务器仅需验证哈希。
• 公平性：每个访问者都需贡献少量计算，而非由网站独自承担。

四、深度思考：AI 时代网站保护的新范式

4.1 “社会契约”的重构

原文强调“AI companies have changed the social contract around how website hosting works”。传统上，网站内容通过搜索引擎（如 Google）被索引，搜索引擎为网站带来流量，形成互利。但 AI 公司抓取内容用于训练模型后，既不返回流量，也不提供补偿，反而消耗服务器资源。这种单向价值提取打破了原有平衡。

4.2 技术方案的演进路径

从 Anubis 的设计可以看出，反爬技术正在从“基于识别”（如 IP 封禁、行为分析）转向“基于成本”（如 PoW）。未来可能的发展方向包括：

• 混合方案：结合 PoW 和浏览器指纹识别，对低风险用户（如已知 IP 段）免除挑战。
• 客户端证明：使用更高效的算法（如 Argon2）增加计算不对称性。
• 区块链集成：将 PoW 结果作为“凭证”存储在链上，实现跨站点共享。

4.3 对开源社区的影响

OpenWrt 项目选择部署 Anubis，反映了开源社区在资源有限情况下的务实选择。然而，这也带来了潜在问题：

• 贡献者门槛：若 PoW 挑战导致部分用户（如低性能设备用户）无法访问文档，可能减少社区贡献。
• 去中心化矛盾：开源倡导自由访问，但反爬措施本质上是一种限制。

五、总结与展望

OpenWrt One 作为开源硬件路由器，代表了网络设备的未来方向——用户拥有完全控制权。而其配套网站采用的 Anubis 反爬系统，则揭示了 AI 时代网站运营的新挑战：如何在开放性与资源保护之间取得平衡。

对于普通用户：

• 若遇到 Anubis 挑战，只需等待几秒即可自动通过（需启用 JavaScript）。
• 若使用隐私插件（如 JShelter），需临时为此域名禁用该插件。

对于开发者：

• Anubis 的代码已开源（可在 GitHub 上找到），可作为自建反爬系统的参考。
• 关注 headless 浏览器指纹识别技术的进展，未来可能替代 PoW。

原文链接：https://openwrt.org/toh/openwrt/one