Anubis AI Scraper Firewall: 停止机器人，保护您的网站，降低托管成本

为什么较小的公共网站现在关注 Anubis

如果你运营公共文档网站、博客、论坛或小型网络应用，问题并不总是以明显的停机形式出现。更常见的是，它表现为源源不断的类浏览器自动化流量。这些请求不断拉取内容，迫使你的源站为并非真正访客的访问者做功。网站可能保持在线，但 CPU 时间被消耗，缓存效率下降，源站请求增加，而这些请求来自错误的受众。随着时间推移，运营者的耐心也随之消耗。

这种压力对不同的读者有不同的影响。

• 开发者感受到的是浪费的后端工作。
• 自托管者感受到的是对公共前门的控制权丧失。
• 业务和网站运营者感受到的是更高的托管成本、更不稳定的性能，以及当背景噪音增加时真正访客的体验恶化。

关键转变很简单：抓取压力不再只是超大规模公司的问题。较小的公共网站也能感受到它。

这就是为什么 Anubis 变得有趣。它是一个专注的前门层，适合那些想让滥用访问变得更昂贵的人，而不是假装他们在购买完整的安全平台。本文是一份基础解释。它涵盖了 Anubis 是什么、它如何工作、它提供什么价值，以及何时适用。

开始前的快速关键词

您不需要太多词汇来阅读本文的其余部分，但几个术语有助于保持解释清晰。这里的目的不是建立一个庞大的安全词汇表。这是为了确保后面的章节不会比需要的更难理解。

Anubis 实际上是什么——以及它不是什么

Anubis 是一个开源 AI 爬虫防火墙。更准确地说，它是一个反爬虫反向代理，位于网站或网络应用程序的前面。它决定传入流量是否应该通过、受到挑战或被拒绝，然后再由源站执行昂贵的工作。在堆栈术语中，位置很简单：

visitor -> Anubis -> origin site/app

这个位置就是关键所在。Anubis 通过在前门放置一个决策层来保护上游资源。

保持其角色清晰的最简单方法是将其与人们最常混淆的层进行比较。下表是 Anubis vs WAF 问题的实际版本。

这就是为什么它对控制自己堆栈的运营商特别相关。如果您在 VPS 或专用服务器上运行公共工作负载，并在自己的反向代理后面，Anubis 很容易在心理上定位：

• 它成为源站前面的又一个运营商控制的检查点。
• 它自然适合想要对路由行为和类浏览器流量有更多发言权的人。
• 它也适合想要自己管理受信任异常而不是将整个问题交给托管边缘产品的运营商。

📝 注意：Anubis 不是经典 WAF，不是 CDN，也不是完整的 DDoS 服务。它是一个专注的反向代理检查点，旨在保护上游资源免受爬虫压力。

同样重要的是，许多网站根本不需要它。这句话应该保持直言不讳，因为它是真的。当爬虫压力真实存在且运营商想要一个专注的前门层时，Anubis 是有用的。它不是每个公共网站仅因为名称包含”防火墙”一词就应该安装的东西。

Anubis 如何工作，逐步说明

最简单的层面上，Anubis 就像一个带收费亭的前门。请求到达，Anubis 首先发言，源站在其后等待。如果请求在活跃策略下看起来没问题，它可以继续进行。如果它匹配更严格的路径，它可能在真实站点或应用进行更多工作之前受到质询。

请求流程如下：

visitor request
    ↓
Anubis
    ├─ allow straight through
    ├─ deny
    └─ challenge when policy says so
            ↓
   client solves proof of work
            ↓
   Anubis verifies cheaply
            ↓
temporary signed badge cookie
            ↓
     origin site/app

重要的细节是 Anubis 是由策略驱动的。传入请求会根据可以 ALLOW、DENY、CHALLENGE 或 WEIGH 它们的规则进行检查。用简单的英语说，这意味着门可以让某些东西通过、拒绝它、要求额外的努力，或在做出最终决定之前增加其可疑度分数。这也是为什么将 Anubis 描绘为”永远质询每个请求”是误导性的。未匹配的流量可以被允许通过，而类似浏览器或更高可疑度的流量可以被更积极地处理。

📝 注意：Anubis 不是一个巨大的硬编码质询页面。它遵循策略规则，并非每个请求都必须被质询才能让该工具发挥作用。

当使用质询时，主要思想是工作量证明。可以把它看作一个小费用。客户端必须在通过之前进行适度的计算，而 Anubis 只需要廉价地验证结果。对于一个普通访问者来说，那额外的工作通常最多只是一个小小的不便。对于试图在大量流量中重复该过程的爬虫来说，经济学开始改变。目标不是让爬取在数学上不可能。目标是停止让它便宜和无摩擦。

一旦访问者通过，Anubis 可以发放一个签名的通行证 cookie。最简单的理解该 cookie 的方式是作为一个临时访问者徽章。访问者已经通过了门，所以他们不需要在每次页面加载时再支付费用。这减少了合法浏览的重复摩擦，同时仍然在源站前保持检查点。徽章是临时的是有原因的：它帮助系统记住客户端最近通过了，而不会将一次成功变成永久信任。

现代 Anubis 策略也可以比平面通过或质询分割更细致。请求加权让规则添加或移除可疑度，以便不同的阈值可以触发更轻或更强的处理。受信任的例外、安全路径和已知的自动化可以与通用类浏览器流量区别对待。一些部署也会不时地重新检查流量，而不是假设早期的通过应该永远持续。该调整层很重要，但核心心智模型仍然是相同的前门加收费亭。

最后一个细节值得关注：通过质询不能证明访问者是人类。它证明客户端通过了配置的门。一些部署也可以使用非 JavaScript 质询模式，但主要的 Anubis 故事仍然是工作量证明加临时通行证。一旦你这样看待它，实际价值就变得更容易判断。

Anubis 在实践中能为您做什么

Anubis 的实际价值不在于神奇的机器人分类。它在于成本转移。如果大规模抓取必须在网关处做更多工作，您的源站就能减少不必要的工作。这可能意味着更少的浪费源请求和更少的无意义后端处理。当滥用流量开始冲击网站时，它还可以为真实访客留出更多空间。

这对内容公开且容易被重复针对的网站和应用最为重要。

• 文档门户
• 博客、论坛
• 仪表板
• 自托管网络工具
• 小型 SaaS 前端
• 代码或网络界面

动态页面和后端资源特别受益，因为它们的服务成本通常比静态资产高。即使网站没有”宕机”，减少前门处的不必要工作也能保护用户实际感受到的响应速度。

另一种理解这种优势的方式是喘息空间。这种喘息空间以具体的方式体现：更少的不必要应用唤醒、更少的缓存变动，以及更少的合法用户感到减速的时刻，即使技术上没有任何问题。Anubis 本身不会让服务器更快；它减少了低价值流量获得完整后端处理的频率。

还有一个控制优势。使用 Anubis，运营者可以塑造行为，而不是平等对待每个请求。

• 某些路由可以容易访问。
• 某些受信任的机器人或自动化路径可以被列入白名单。
• 某些类浏览器流量可以受到更激进的挑战。

这才是真正的运营优势：不是一种神秘的识别好坏的能力，而是一套可用的流量处理决策，与网站应该如何使用的方式相匹配。

对于已经从托管角度考虑这个问题的读者，部署方式很直接。如果您在 AlexHost VPS 或专用服务器上的 Nginx 或 Caddy 后面运行公共服务，这通常意味着在您已经管理的应用路径前面放置 Anubis，以便在通用网络流量唤醒后端之前进行过滤。堆栈的其余部分保持不变；区别在于您的源站不再平等处理每个请求。

您应该了解的限制和权衡

误解 Anubis 的最快方式是读到”firewall”就假设有完全保护。该工具的工作范围更窄。它不修补易受攻击的代码或关闭暴露的服务。它不吸收饱和的上行链路，也不能替代 WAF、CDN 或 DDoS 服务。如果您的主要问题存在于这些层之一，Anubis 不是解决它的工具。

它也不会让有针对性的自动化消失。高级无头浏览器可以运行 JavaScript。它们也可以存储 cookie、重试请求和解决任务。成功条件只是不同：爬取变得更昂贵、更不方便，对攻击者一方的影响也更小。

⚠️ 警告：无 JS 访问是一个权衡区域。当前 Anubis 文档包括无 JS metarefresh 选项，但它不是默认路径，且区分度较低，因此应将其视为兼容性权衡而非主要保护方案。

这个权衡很重要，因为一些合法访问者使用强化隐私设置或有意限制的浏览器。基于 JavaScript 的挑战路径即使在他们没有做任何滥用行为时也可能会让他们感到沮丧。无 JS 选项在某些情况下有帮助。但它也削弱了区分故事，因为现代爬虫已经可以像真实浏览器一样行动。换句话说，可访问性和摩擦力需要诚实地判断，而不是被挥之即去。

发现和自动化带来第二个权衡：

• 搜索引擎和存档机器人可能需要白名单。
• 源、监控和其他合法自动化可能需要更仔细的策略处理。

如果您不小心，可能会使您的网站更难被索引或存档。您也可能使其更难与实际有用的工具集成。这并不意味着 Anubis 是一个坏工具。这意味着操作员必须决定哪些流量应该获得简单路径，哪些流量应该获得更难的路径。

有时最干净的答案是跳过它。低曝光的爱好网站或仅限内部的服务可能从添加 Anubis 获得的摩擦比价值更多。对于已经对托管边缘平台感到满意的团队也是如此。当真正的问题是不安全的应用代码或饱和的上游带宽时也适用。如果问题存在于其他地方，添加爬虫门只会在错误的瓶颈周围增加额外的复杂性。

Anubis 何时有意义——何时过度

当以下三件事同时成立时，Anubis 最有意义：

1. 🌍🔓 该服务是公开的
2. 🤖⚠️ 爬虫压力足够大，足以造成操作上的困扰
3. 🔄🖥️ 运营者希望控制前门的反向代理层

公开文档、论坛、博客、自托管应用和小型 SaaS 表面是强有力的例子。它们公开暴露内容，但仍然依赖于值得保护的源资源。

当你将其简化为几种常见情况时，决策变得更容易：

最佳适配还假设运营者的意愿。Anubis 在概念上很简单，但它仍然在代理层增加了策略所有权。必须有人决定什么应该轻松通过，什么应该受到挑战。他们还必须决定哪些机器人或源应该获得例外，以及受众能容忍多少摩擦。如果团队中没有人想做出这些决定，一个技术上相关的层仍然可能成为操作上的混乱。

中间类别很重要，因为许多真实环境本质上是分层的。如果爬虫压力只是图景的一部分，Anubis 仍然可以占据一席之地，但它只需要一个工作：在昂贵的类浏览器流量到达应用之前对其进行筛选。其他控制仍然处理各自的工作——安全编码、应用感知过滤、流量分配和网络规模保护。

💡 提示：更简单的测试是这样的：如果爬虫流量没有造成可测量的操作拖累，Anubis 可能不是改变结果的层。如果你真正的痛点来自易受攻击的代码或上游饱和，情况也是如此。如果爬虫成本确实出现在你的日志和主机行为中，那么它就成为一个合理的、有针对性的工具来考虑。

Anubis 是一个专注的层，可以解决真实问题

如果你回到开场情景，Anubis 的真正吸引力就变得清晰了。它适用于那些不会以壮观方式崩溃，但每天都在悄悄承受爬虫成本的公共网站。在这种情况下，Anubis 值得理解，因为它提供了一个反向代理层，可以在源站继续为此付费之前减缓滥用访问。

持久的收获很简单：Anubis 提高了大规模爬取的成本，有助于保护源站资源，但它仍然属于更广泛、基于现实的保护堆栈的一部分。如果你控制自己的 VPS、专用服务器或反向代理路径，通常在爬虫压力成为迫使你提出这个问题的因素之前，学习这样一个层适合的位置会更容易。