近些来，一些 AI 公司为了获取大量的数据用于大模型的训练，疯狂地利用各种爬虫，不顾 robots.txt 或者其他爬虫协议，对站点发起大量请求，对于个人站点来说，这种请求量可能使得网站崩溃

而且这些公司大量使用各种住宅 IP，修改 user-agent，导致我们根本没有办法从 ASN 和请求头下手对请求进行拦截

Cloudflare 其实提供了一些解决方案，比如说 AI 迷宫：Bot Management · Cloudflare bot solutions docs，但是对于一些没办法使用 Cloudflare 或者不愿意使用 Cloudflare 的场景，我们又该怎么办呢？

Anubis 为你提供了这样的一种解决方案：Docs | Anubis，帮助保护小型互联网免受人工智能公司无休止的请求风暴的影响

设计原理

Anubis 通过设置和 Cloudflare 一样的 JavaScript 挑战，来校验访问的客户端是否为浏览器，但客户端请求满足这些条件时，Anubis 将自动发起质询：

• 用户代理包含 "Mozilla"
• 请求路径不在 /.well-known 、 /robots.txt 或 /favicon.ico 中
• 请求路径显然不是 RSS 订阅（以 .rss 、.xml 或 .atom 结尾）

这样的设计能够保证诸如 git 或者 RSS 定义客户端不受到影响，而对于一些浏览器或者 AI 爬虫这些高风险客户端则能进行质询

通过挑战后，会签发一个 "within.website-x-cmd-anubis-auth" 的 HTTP Cookie，这样的话就算通过了挑战

如何设置

Anubis 的运行方式其实是在反向代理和后端服务之间创建一个中间代理，后端服务的流量在经由 Nginx 或者 Caddy 处理之后，到达 Anubis，最后经由 Anubis 再到达后端服务：Setting up Anubis｜Anubis

Anubis 提供了多种部署方式，在这里我就直接使用包管理器的方法进行安装：Installing Anubis with a native package｜Anubis

首先从 GitHub 上下载对应的安装包：Releases · TecharoHQ/anubis

wget https://github.com/TecharoHQ/anubis/releases/download/v1.17.0/anubis_1.17.0_amd64.deb

之后安装

sudo apt install ./anubis_1.17.0_amd64.deb

这里比如说我们想保护一个 Gitea 应用，我们 Gitea 后端的端口为 3000，先来配置 Anubis 的配置文件：

sudo cp /etc/anubis/default.env /etc/anubis/gitea.env

之后开始编辑：

nano /etc/anubis/gitea.env

默认的内容如下：

BIND=:8923
DIFFICULTY=4
METRICS_BIND=:9090
SERVE_ROBOTS_TXT=0
TARGET=http://localhost:3000

具体的各种参数可以查看：Environment variables｜Anubis

我们这里只填几个必须的，可以参考我的：

BIND=:8923
DIFFICULTY=4
METRICS_BIND=:9090
SERVE_ROBOTS_TXT=0
POLICY_FNAME=/etc/anubis/gitea.botPolicies.json
TARGET=http://127.0.0.1:3011
WEBMASTER_EMAIL=admin@example.com
REDIRECT_DOMAINS=git.juniortree.com
USE_REMOTE_ADDRESS=true
ED25519_PRIVATE_KEY_HEX=cdfd076f987d91d165821cac23efcd4a2ab9e09e9642a8ec474ea02b9ef4e8ae

• BIND：Anubis 代理后端转发的端口，对于 Caddy 和 Nginx，这里就是代理的端口
• DIFFICULTY：挑战的难度，或成功回答中必须包含的前导零的个数
• METRICS_BIND：给普罗米修斯探针做监控的
• SERVE_ROBOTS_TXT：Anubis 会默认提供一个 robots.txt，来控制爬虫
• POLICY_FNAME：设置 Anubis 规则文件的位置
• TARGET：设置要保护的后端服务
• WEBMASTER_EMAIL：在质询页面会留下一个管理员邮件，如果质询出现问题，访客可以通过这个联系到你
• REDIRECT_DOMAINS：这里需要添加为你要保护的域名，比如说我后端原来服务的域名为 git.juniortree.com，那这里就填这个
• USE_REMOTE_ADDRESS：传递真实 IP 的头部
• ED25519_PRIVATE_KEY_HEX：用于签署 Anubis 响应的十六进制编码 ed25519 私钥，如果未设置，Anubis 将自动生成一个，长度应正好为 64 个字符，可以使用 openssl rand -hex 32 自己生成一个（不要直接使用我上面的）

之后把对应的规则复制到相应的目录里面：

sudo cp /usr/share/doc/anubis/botPolicies.json /etc/anubis/gitea.botPolicies.json

启动服务：

sudo systemctl enable --now anubis@gitea.service

然后设置反向代理（Nginx、Caddy 等），指向 Anubis 端口。然后，Anubis 会将所有符合 /etc/anubis/gitea.BotPolicies.json 中策略的请求反向代理到目标服务

我这里使用的是 Caddy，我的配置文件就为：

git.juniortree.com {
    reverse_proxy 127.0.0.1:8923 {
        header_up X-Real-Ip {remote_host}
    }
}

Nginx 我自己没有实践过，可以参考官方的：

location /myapp/ {
    proxy_pass http://anubis:8923/myapp;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

这个是质询中的页面

这个是质询失败的页面：

质询通过后自动跳转到对应的业务

一些讨论

Anubis 能不能用来当防火墙用？

这个显然是不可以的，因为前面说了，只会对包含 "Mozilla" 的进行质询，而假如攻击者使用修改的谷歌爬虫请求头，那就可以直接绕过了，这时就应该搭配谷歌的 ASN 进行认证

如果一定要作为防火墙使用，使用 Cloudflare 的 WAF 或许是更好的选择

会不会影响 SEO

尚不清楚，我自己只对不希望被爬取的 Git 仓库进行了配置，官方给出的建议也并不明确，我没有对其进行测试，对此保持旁观态度