Anubis 介绍与选型指南

Anubis（TecharoHQ/anubis）反 AI 爬虫质询代理的定位、Proof-of-Work 质询原理、规则体系与部署形态认知，含与 Cloudflare Bot Management/go-away/fail2ban 路径的量化选型对比，基于 v1.28.2 联网溯源（2026-10-28）。

Anubis安全爬虫WAFGolang2026/10/28

Anubis 介绍与选型指南

目标：面向正在遭受 AI 爬虫流量冲击的自托管站长与运维工程师，讲清 Anubis（TecharoHQ/anubis）这一反 AI 爬虫质询代理的定位、Proof-of-Work 质询原理、规则体系与部署形态，并在与 Cloudflare Bot Management、go-away、fail2ban/限流等同类防护路径的量化对比中给出选型建议。本篇为认知选型篇，全部信息均来自官方仓库与官方文档的联网溯源（查询日期 2026-10-28），不含本地实测数据；部署与实测结论见本专栏后续部署与运维篇目。

一、环境信息

本篇是纯联网溯源的认知篇，不依赖本地实验环境。写作时引用的全部事实均取自下列官方来源，逐一标注查询日期：

  • 软件仓库：GitHub TecharoHQ/anubis（README 与仓库徽章，查询日期 2026-10-28）；
  • 官方文档站：anubis.techaro.lol（文档源码位于仓库 docs/docs/ 目录，本篇按源文件核对，查询日期 2026-10-28）；
  • 版本与发布节奏：GitHub Releases 页 github.com/TecharoHQ/anubis/releases（查询日期 2026-10-28）；
  • 社区活跃度：shields.io 实时徽章（查询日期 2026-10-28，星数 24k）；
  • 打包状态：repology.org 项目页 anubis-anti-crawler（查询日期 2026-10-28）。

截至查询日，官方最新稳定版本为 v1.28.2（GitHub Releases 重定向确认，2026-10-28）。

二、软件概述

Anubis 是一个用 Go 语言编写的「Web AI Firewall Utility」（官方自我定位），通过一个或多个质询（challenge）来「称量你连接的灵魂」（weighs the soul of your connection），把自动化爬虫挡在上游资源之外。名字取自埃及神话中的亡灵审判之神阿努比斯——它以天平称量死者心脏与真理羽毛的重量来决定其去留，Anubis 软件正是借用这一意象：每一个进站连接都要被「称量」，重的（可疑的）被拒绝或加重质询，轻的（正常的）被放行。

这个项目诞生的背景非常具体：2025 年前后，各 AI 公司的训练爬虫以远超传统搜索引擎蜘蛛的请求量轰炸中小型网站，导致大量自托管服务（GitLab、Gitea、论坛、维基）不堪重负。作者 Xe Iaso 在 README 中写道，Anubis 的设计目标是「帮助小型互联网（the small internet）抵御来自 AI 公司的无尽请求风暴」，并且刻意保持轻量，让每个人都能负担起保护身边社区的成本。它最著名的采用者包括 GNOME 基金会——GNOME 在其 GitLab 实例上部署 Anubis 以抵御 AI 爬虫（来源：作者博客与项目公开报道，查询日期 2026-10-28），此后该项目迅速成为自托管社区的反爬标配。

💡 说明：Anubis 官方明确称之为「a bit of a nuclear response」（一种近乎核弹级的应对）——它会连较小的善意爬虫一起挡住，也可能误伤 Internet Archive 这类「好机器人」。官方建议：绝大多数场景用 Cloudflare 保护源站即可；只有在「不能或不愿使用 Cloudflare」时（自托管、隐私顾虑、成本、网络封锁），Anubis 才是给独立站点的答案。

三、核心架构

Anubis 在部署链路中的位置是一个过滤型反向代理：它夹在「TLS 终结/负载均衡层」与「被保护业务」之间，所有入站请求先经它裁决，通过质询的流量才被转发到上游（官方文档 installation.mdx 的部署图示：LB → Anubis → App，查询日期 2026-10-28）。

核心裁决流程可以概括为四步：

  1. 规则匹配（Bot Policies）：每条入站请求依次与策略文件（YAML/JSON）中的规则比对，匹配维度包括请求路径（path_regex）、User-Agent（user_agent_regex）、任意 HTTP 请求头（headers_regex）、来源 IP 段（remote_addresses，如按搜索引擎公布的网段校验真伪）、GeoIP 国家/ASN（需另配 MaxMind 数据库）；
  2. 裁决动作：四类动作 ALLOW（直通后端）/ DENY（拒绝并返回让爬虫误以为成功的错误页）/ CHALLENGE（下发质询页或校验已通过的质询凭证）/ WEIGH（增减该请求的「灵魂重量」权重）；
  3. 权重阈值裁决（Weight Thresholds）：被 WEIGH 累积出的请求权重与阈值表（CEL 表达式）比对，按可疑程度下发不同强度的质询——官方默认阈值把 weight <= 0 直接放行、weight >= 30 下发难度 6 的重质询，实现「疑罪从轻、阶梯惩罚」；
  4. 质询通过 → 签发凭证 → 反向代理转发：客户端完成质询后，Anubis 签发签名 Cookie（Ed25519 或 HS512 签名的 JWT），后续请求凭 Cookie 直通，默认有效期 168 小时（COOKIE_EXPIRATION_TIME）。

质询本身有三种算法（官方文档 configuration/challenges，查询日期 2026-10-28）：

  • Proof-of-Work（fast/slow）：默认主路径。客户端浏览器执行一段 JavaScript，暴力计算 SHA-256 哈希直到找出满足「前导零数量 ≥ difficulty」的随机数，把结果回传换取出站凭证。fast 是多线程高度优化实现，slow 是单线程朴素实现（为兼容保留）；
  • Meta Refresh（metarefresh）：无 JavaScript 质询。仅要求浏览器在数秒后自动刷新页面，适合纯文本浏览器与禁 JS 环境，但对现代无头浏览器（headless Chrome）拦截力弱，官方注明误放率高、默认未启用；
  • Preact（preact）：基于 Preact 前端框架渲染的质询页，用于自定义质询界面场景。

💡 技术拓展：「用计算代价换取访问资格」的思想在业界通称 Proof-of-Work（工作量证明），它并非 Anubis 首创。常见同类机制对比——

机制原理典型使用者
Hashcash邮件头中附带满足前导零的哈希印戳，用于提高发垃圾邮件的成本反垃圾邮件系统（1997，Adam Back）
PoW 质询页浏览器 JS 计算哈希谜题，通过后签发 CookieAnubis、Cloudflare 早期质询
CAPTCHA人机交互式挑战（识图/点选），验证「是人」而非「愿付算力」reCAPTCHA、hCaptcha
TLS/HTTP 指纹不让客户端算题，改为校验握手特征是否像真浏览器go-away、Cloudflare Bot Management

Anubis 采用 PoW 的核心取舍是：验证方（服务器）几乎零成本、请求方（浏览器）一次性付出约几十毫秒到数秒的计算——对每天数亿次请求的恶意爬虫农场，这个代价乘上规模就是经济威慑；而对真实用户只是一闪而过的「Making sure you're not a bot」页面。代价同样明确：纯 JavaScript 禁用环境、部分无障碍阅读器与低功耗设备会被拖慢或拦死，这正是官方保留 metarefresh 无 JS 质询的原因。

四、功能特性

以下特性清单逐条核对自官方 README 与 docs/docs/admin/ 文档（查询日期 2026-10-28）：

  • 声明式爬虫规则引擎：YAML/JSON 策略文件，支持路径、UA、请求头、来源网段四类匹配与四种动作；规则支持 import 片段复用（(data)/ 前缀引用内置规则集）；
  • 内置 AI 爬虫黑名单：默认策略通过 data/meta/ai-block-aggressive.yaml 等内置片段激进拦截已知的 AI/LLM 爬虫（CFCrawl、Amazonbot、x.ai 采集器等），并区分 aggressive/moderate/permissive 三档可选；
  • 搜索引擎白名单：默认放行 Google、Apple、Bing、DuckDuckGo、Qwant、Kagi、Internet Archive 等「好爬虫」，部分条目结合 remote_addresses 网段校验防止 UA 伪造；
  • 权重与阈值体系：WEIGH 动作 + CEL 表达式阈值，可按 UA、GeoIP 国家、ASN、系统负载（load_1m 等表达式）动态调整质询强度，实现渐进而非一刀切；
  • 蜜罐（Honeypot）：内置蜜罐路由，命中蜜罐 URL 的客户端 IP 被记录并可封禁（默认 implementation: naive）；
  • DNSBL 支持：可对来源 IP 做实时黑名单查询（默认关闭）；
  • Open Graph 透传：质询页可透传上游页面的 og:title/og:description 元数据，保护社交平台分享卡片不被质询页污染；
  • Prometheus 指标服务器：独立端口输出质询通过/拒绝等指标，支持 TLS、mTLS、Basic Auth 与 pprof 调试端点；
  • 多种存储后端：质询临时数据可选 memory（单实例默认）/ bbolt（单机大流量）/ s3api（多实例共享，兼容 AWS S3、R2、MinIO 等）/ valkey（RESP 协议远程缓存）；
  • 无障碍与本地化：质询页多语言（跟随 Accept-Language 或 FORCED_LANGUAGE 强制）、可自定义文案与 CSS/模板（部分属 BotStopper 企业特性）；
  • 极低资源占用：官方文档与 README 均注明单实例常驻内存通常低于 32 MiB，128 MiB 内存足以服务大量并发客户端（来源：installation.mdx，查询日期 2026-10-28）。

五、快速开始（最小可用示例）

本节为官方安装文档的溯源摘要（来源：anubis.techaro.lol docs/admin/installation、docs/admin/native-install，查询日期 2026-10-28），给出非容器部署的最小路径，帮助读者建立直观认知；逐命令实测的完整安装与联调见本专栏部署篇。

Anubis 的安装形态有三类：官方原生包（Debian 系 .deb/apt、Red Hat 系 .rpm/dnf、通用 tarball，均从 GitHub Releases 下载）、Docker/OCI 镜像（ghcr.io/techarohq/anubis，tag 约定 latest/pre/v<版本>/main）、源码构建（Go 工具链）。原生包安装后由 systemd 托管，配置默认落 /etc/anubis/。

最小可用示例的三要素如下：

  1. 生成签名密钥（多实例共享域时必须固定，避免重启后凭证失效）：
openssl rand -hex 32
  1. 最小策略文件（官方 policies.mdx 原例，动作语义见第三章）：
bots:
  - name: cloudflare-workers
    headers_regex:
      CF-Worker: .*
    action: DENY
  - name: well-known
    path_regex: ^/.well-known/.*$
    action: ALLOW
  - name: favicon
    path_regex: ^/favicon.ico$
    action: ALLOW
  - name: robots-txt
    path_regex: ^/robots.txt$
    action: ALLOW
  - name: generic-browser
    user_agent_regex: Mozilla
    action: CHALLENGE
  1. 以环境变量声明监听与上游并启动：核心变量 BIND（默认 :8923，Anubis 监听地址）、TARGET（默认 http://localhost:3923，质询通过后转发到的上游服务）、POLICY_FNAME（策略文件路径）、DIFFICULTY（默认 4，PoW 前导零个数）、METRICS_BIND（默认 :9090，Prometheus 指标端口）。

最后在前置的 Nginx/Caddy 反向代理中把原指向业务的 proxy_pass 改指向 Anubis 监听地址，并保持 X-Real-IP 等 header 透传，即完成接入。官方特别提醒：Anubis 的静态资源与接口路径固定在 /.within.website/x/xess/ 与 /.within.website/x/cmd/anubis/ 下，反代配置必须放行这两个前缀，否则质询页无法加载。

六、适用场景与限制

适合上 Anubis 的场景（依据官方文档与项目定位归纳）：

  • 自托管 Git 服务（GitLab/Gitea/Forgejo）、论坛、维基、博客被 AI 训练爬虫冲击，且不愿或不能把 DNS 托给 Cloudflare；
  • 需要「按 UA/路径/网段精细裁决」而非单纯限速的站点：想把 RSS 阅读器、/.well-known/、/robots.txt 放行，把 CF-Worker、AI 爬虫 UA 直接拒掉；
  • 希望防护层本身近乎零成本、零外部依赖（不引第三方 JS、不出站回调）的隐私敏感站点。

明确的限制与代价（官方 README「Overview」与 policies 文档明示，查询日期 2026-10-28）：

  • 核弹级副作用：小爬虫全挡，Internet Archive 等「好机器人」默认被质询，需自行加白；官方正在筹备「known good bots」策划名单作为折中；
  • 浏览器兼容代价：默认 PoW 质询要求客户端执行 JavaScript——禁 JS 用户、多数无障碍工具、低功耗设备与纯文本浏览器会被拖慢或拦死；metarefresh 可免 JS 但拦截力显著下降（官方注明对现代 headless Chrome 误放率高）；
  • 不适合长连接型应用：官方注明对依赖 WebSocket 维持长连接的应用适配性存疑；
  • 每服务一实例：一个 Anubis 实例保护一个上游服务（多站点需多实例或两级路由架构，单实例内存开销小，架构上可行但需逐个配置）；
  • 质询可被高成本绕过：PoW 只提高批量抓取的边际成本，决心足够的爬虫（如专为此定制的浏览器内核农场）仍可执行质询——它防的是「无差别资源消耗」，不是定向渗透；
  • DENY 静默返回 HTTP 200：默认策略对被质询/被拒请求回 200 状态码（官方注释：最激进的爬虫「非常想要 200」，拿到 200 才会停手），这会让基于状态码的监控误判，需配合指标服务器观测。

七、同类选型对比

下表在与同类防护路径的横向对比中量化 Anubis 的位置。Anubis 的星数取自 shields.io 实时徽章（24k，查询日期 2026-10-28），版本节奏取自 GitHub Releases（2026-10-28 当日最新稳定版 v1.28.2，pre 版本持续滚动发布）；其余方案以定性维度为主并标注信息来源。

维度AnubisCloudflare Bot Managementgo-awayfail2ban + Nginx 限流路径
形态自托管过滤型反向代理商业 SaaS 边缘网络自托管过滤型反向代理主机层日志分析 + 防火墙/限速
拦截机制规则引擎 + 权重阈值 + JS PoW 质询企业级行为分析、机器学习、IP 信誉库（闭源）TLS/HTTP 指纹 + PoW 质询（来源：go-away 项目文档，查询日期 2026-10-28）日志正则匹配失败计数 → iptables 封禁 / 请求速率限制
识别「像人」的手段客户端愿付计算成本 + Cookie 凭证全站流量画像（无感）客户端指纹无感校验为主不识别，仅按速率与规则
浏览器兼容代价需 JS（可选 metarefresh 免 JS 但强度弱）无感部分质询需 JS无感
部署位置与改动反代链插入一跳，每服务一实例DNS 切换至 Cloudflare 托管反代链插入一跳改 Nginx 配置 + 装 fail2ban
成本开源免费（MIT）商业订阅（企业级产品线）开源免费开源免费
数据出站无（质询本地验证）全站流量过第三方无无
可观测性Prometheus 指标、pprofCloudflare 控制台有限日志 + fail2ban 状态

选型解读：数据主权与成本敏感、且需要「可审计的规则」时选 Anubis——它的规则引擎、权重阈值与默认 AI 黑名单是同类自托管方案中最成体系的；已有 Cloudflare 且预算允许时，Bot Management 的无感体验优于一切质询方案，Anubis 官方也承认多数场景 Cloudflare 足矣；go-away 走「指纹优先」路线，对 JS 依赖更低但社区规模较小，适合愿意跟进小众项目的用户；fail2ban/限流路径改动最小、无浏览器代价，但只能拦「量」不能辨「质」，对分布式低频爬取几乎无效。四者并非互斥：常见生产形态是「Cloudflare/限流挡量 + Anubis 挡 AI 爬虫」的组合分层。

💡 技术拓展：质询代理（challenge proxy）之外，应用层防爬还有三条主流技术路线——WAF 规则引擎（如 SafeLine、Coraza，按 HTTP 特征库拦截）、客户端指纹（FingerprintJS 类，采信浏览器环境特征）、速率限制（nginx limit_req、API 网关限流）。Anubis 的差异化在于专攻「AI 爬虫质询」这一垂直场景：默认策略开箱即拦已知 AI 爬虫、质询成本由客户端承担、且不要求接入第三方服务。

八、参考链接