2026年9月1日，CrowdSec 1.8 发布了——在通过一个 helm install 安装到服务器的开源 WAF 中，带来了两项新功能：浏览器指纹识别和工作量证明（proof-of-work）。到目前为止，PoW 防护墙在野外主要出现在 GitForge 和邮件列表的存档中。现在，这种防护层可能出现在任何每天有五百名访客的网站上。
我们来看看究竟发生了什么变化，为什么检测转向了“用处理器支付”，以及——最重要的是——为什么在这个结构中哈希是最小的问题。
发生了什么：PoW 从 GitForge 降落到普通网站
CrowdSec 是一个自托管系统：代理读取日志，WAF 位于应用程序前面，“反弹器”进行阻止。在 1.8 版本中，团队在 WAF 中添加了一个机制，它不是回答“这个 IP 是坏的吗？”而是回答“这到底是一个人用的浏览器，还是一个假装成人的机器人？”答案是通过指纹（浏览器特征和 TLS 签名）和工作量证明——客户必须在后端看到请求之前解决的计算任务。
作者毫不客气地阐述了动机：2026 年的平均机器人使用真正的 Chrome，具有一致的 TLS 指纹，居住 IP——而且它的耐心比值班工程师更强。这一检测的承认比任何分析都更有价值：居住地址和整洁的 TLS 不再是区分标志。既然根据 IP 声誉和握手，机器人与人类没有区别，保护措施寻找的是一种对浏览器便宜而对机器群体昂贵的标志。
与此同时，在 Hacker News 的同一天，POWBlock——“适用于任何服务器的工作量证明微服务”也浮出水面。一个版本可以归结为巧合，但一周内出现两个独立信号——这已经是一个方向。
以 Anubis 为例的 PoW 防护墙是如何构建的
该领域的典范是 Anubis：一个基于 Go 的 MIT 许可反向代理，由 Xe Iaso 于 2025 年 1 月以 Techaro 品牌编写。这个想法直接来自于亚当·贝克 1997 年的哈希现金：客户端不断尝试值，直到 SHA-256 生成所需数量的前导零的哈希。解决了——就获得了签名的 JWT Cookie (techaro.lol-anubis-auth) 和临时访问权限。没有解决——后端就不会知道你。
难度由管理员设定。默认情况下，Anubis 挑战所有看起来像浏览器的请求——也就是说，所有 User-Agent 中包含 Mozilla 字符串的请求。每个级别的难度如下：
- 难度 1——少于 100 毫秒。
- 难度 4（默认）——在 Intel Core Ultra 7 165H 上大约 1.35 秒，这大约是每秒 87,600 次哈希。
- 难度 8——大约 11 秒。
- 难度 10——大约 114 秒。
第四级和第十级之间的差异大约是 84 倍。实施这些的名单令人印象深刻：Linux 内核邮件列表的存档、内核的 git 服务器、sourcehut、FFmpeg、GNOME 项目的 GitLab、Wine、sourceware.org、FreeCAD、ScummVM、Enlightenment、联合国教科文组织。杜克大学在 2025 年 6 月的试点项目每天阻止了超过 400 万个不必要的 HTTP 请求——约 90% 的垃圾流量——一周内只有 12 人抱怨出现问题。
这些防护墙的出现并非出于恶意。在 Read the Docs，一个爬虫在一个月内下载了 73 TB；在封锁后，日流量从 800 GB 降至 200 GB，节省了约 1500 美元。德鲁·德沃特描述说，与爬虫的斗争消耗了他 20% 到 100% 的个别周。随着 2025 年自动化流量增长 23.51% 和 AI 流量在一年内几乎增长三倍，管理员们开始采取快速有效的措施。
转折：针对工业爬虫，PoW 几乎无效
现在是一个不太方便的部分，通常在新闻稿中很少提及。工作量证明依赖于“便宜验证，昂贵解决”的不对称性。在网络中，这种不对称性并没有朝着正确的方向展开。
诚实的访客认为哈希是浏览器中慢速 JavaScript 的结果。而那些来获取数据的人则认为它是本地代码。塔维斯·奥曼迪用 25 行 C 语言编写了一个求解器：难度为 5 的任务大约在 0.017 秒内解决——这大约是浏览器 SubtleCrypto 的 200 倍速度。在 GPU 上，差距更大，约为一百倍或更高。算术的结果很简单：对于大型供应商来说，绕过所有 Anubis 网站的成本几乎为零。
这不是理论。Codeberg 在 2025 年 8 月就报告说，许多爬虫机器人已经学会了解决 Anubis 的挑战。尽管如此，防护墙并没有变得无用——几个月内它阻止了大部分流量——但对于那些愿意花一个晚上时间在本地求解器上的人来说，它并没有起到屏障作用。
付账的仍然是活生生的用户。难度 5——在新的 MacBook 上大约需要 2 秒，在旧笔记本上需要几十秒，而在手机上可能需要两分钟。在 GitLab GNOME，曾记录到 Firefox 中出现半小时的卡顿——虽然是个例，但很有代表性。此外，还有严格的例外：默认情况下，Anubis 需要 JavaScript，因此 RSS 阅读器、curl、wget 和 Lynx 都无法使用。该项目正在修复这一问题——在 1.20.0 版本中出现了无 JS 的路径通过 meta-refresh，但在 1.22.0 版本中引入了 Proof of React，反而提高了对浏览器的要求。
还需要了解项目本身的可持续性：大约一半的代码由一个人提交，在 80 多名贡献者中，只有一位其他开发者的提交次数超过十次。此外，Anubis 集成了付费服务 Thoth，用于 GeoIP 和 BGP 过滤——这意味着这个开源项目有一个商业邻居。
PoW 真正有效的地方：商业版本的构造不同
这里隐藏着主要的概念替换。Kasada、hCaptcha 和 Cloudflare Turnstile 也使用工作量证明——但与 Anubis 完全不同。
在 Anubis 中，拼图 就是 墙：执行 JS，计算哈希——就通过了。一个信号，一个障碍。在商业系统中，PoW 作为 认证 工作。对于 Kasada，任务只需几毫秒——如此之少，以至于作为障碍毫无意义。其意义在于：为了完成它，客户必须运行一个混淆的虚拟机，真正的检测就在其中。如果你计算了哈希，但没有完成其他所有步骤——你将一无所获。hCaptcha 在图像判定之上叠加 PoW，提高了对可疑客户的计算成本，Turnstile 将 PoW 视为众多环境信号中的一个。
这种差异是根本性的。开放的防护墙可以被便宜的本地求解器攻破。商业防护墙则不是通过哈希，而是通过诚实执行他人的混淆代码并不暴露在环境中来攻破——而这很昂贵，因为混淆代码会定期更换。CrowdSec 1.8 的吸引力在于它将这种逻辑的混合（指纹与 PoW 并存）带入了自托管的世界，在这里，之前的最大限制是基于 IP 的速率限制。
这在实践中意味着什么
如果您合法收集数据——监控价格、跟踪品牌、进行研究——得出的结论非常具体。
- 问题不在于哈希，而在于浏览器层。 哈希在毫秒级别本地计算。指纹、混淆的虚拟机和正确的环境则没有被计算。实际的转变是：在以前只需要 HTTP 客户端的地方，现在需要真正的浏览器引擎。这在 CPU 和内存上更昂贵，因此需要提前进行规划。
- 经济学从流量转向时间和处理器。 以前的成本是以 IP 和 GB 计算的。现在，它还增加了每页的秒数和核心的负载。需要测量的不是每 GB 的价格，而是 每个成功记录的成本——在 PoW 防护墙下，这两个指标的差异尤其明显。
- 会话成为资产。 Anubis 在一段时间内发放 JWT Cookie。如果在每个请求后更改 IP，您将在每个页面上重新支付 PoW 税。粘性会话在 住宅代理 上的优势不在于“匿名性”，而在于计算：一个任务的解决可以在多个页面上摊销。在 PoW 的世界中，激进的轮换从好习惯变成了过度消耗。
- 求解器不能替代行为。 正是这种逻辑使得 验证码求解器不再解决问题：您解决的是可见任务，而判定是基于其周围的不可见信号。
- 降低频率——这比任何防护墙都便宜。 PoW 浪潮源于像一个爬虫一个月下载 73 TB 的故事。缓存、条件请求、合理的间隔和对 robots.txt 的尊重会在挑战启动之前将您从雷达上移除。便宜的 数据中心地址 加上最大频率的无头浏览器——正是为了这种配置而设置的防护墙。
结论
CrowdSec 1.8 并不是“抓取的终结”，Anubis 也没有成为这种情况：本地求解器在 0.017 秒内解决难度 5 的任务，而一个活生生的人在旧手机上可能需要等待两分钟。真正的新闻在于其他方面。首先，检测明确承认，居住 IP 和干净的 TLS 不再证明任何事情。其次，“证明你是浏览器”的层次不再是拥有 Kasada 预算的大型平台的特权，而是转移到了可以安装在普通网站上的开源项目中。
准备的重点不是与哈希作斗争，而是便宜的“多个 IP 加快速 HTTP 客户端”方案将会在越来越小的目标上失效。相反的配置会获胜：更少的请求、真正的浏览器、较长的会话和高质量的地址，在需要一个可靠的通道而不是一千次便宜尝试的地方。