Git Forge AI爬虫防护：基于行为分析与指纹识别的工程实践

在 2025 年的今天，自托管 Git Forge 面临着一个前所未有的挑战：AI 爬虫的大规模代码抓取。这些爬虫不仅无视robots.txt，而且使用数以万计的代理 IP 进行分布式攻击，传统防护手段几乎失效。本文基于 VulpineCitrus 的实战经验，深入探讨如何构建基于行为分析、速率限制和指纹识别的 AI 爬虫检测系统，保护 Git 仓库免遭大规模代码抓取。

一、AI 爬虫对 Git 仓库的威胁规模

Git 仓库的页面数量呈指数级增长。以一个 Linux 仓库为例，仅 master 分支到 v6.17 标签的 1,383,738 个提交，就能生成约 3240 亿个可抓取页面。这个数字的计算公式为：

(Ncommits × Nfiles) × 2 + (Ncommits × Nfilesandfolders) × 2 + Ncommits × 3

其中每个文件在每个提交中都可以被原始下载、git-blame 查看，每个文件或文件夹页面都可以被访问，每个提交的差异页面都可以被查看。

这种规模的数据量对 AI 训练具有巨大价值，导致爬虫不惜成本地进行抓取。根据 VulpineCitrus 的实测数据，未受保护的 Git Forge 服务器：

CPU 使用率高达 99% 以上（4 核全满）
内存使用从 1.5GiB 激增至 2.5GiB 以上
网络出口带宽持续在 32Mbps（4MBps）
服务器功耗从 150W 增加至 200W，年电费增加约 60 欧元
影响整个局域网的网络性能

二、传统防护措施的局限性

1. 反向代理缓存：完全失效

Nginx 缓存配置看似合理，但对 Git 仓库防护完全无效：

proxy_cache_path /var/cache/nginx/forge/ levels=1:2 keys_zone=forgecache:100m;

location / {
    proxy_cache forgecache;
    proxy_buffering on;
    proxy_cache_valid any 1h;
    add_header X-Cached $upstream_cache_status;
    expires 1h;
    proxy_ignore_headers "Set-Cookie";
    proxy_hide_header "Set-Cookie";
}

问题在于 AI 爬虫很少重复访问同一资源，它们协调地遍历所有可能的页面组合。缓存命中率极低，反而增加了认证页面的显示问题。

2. IP 级速率限制：阻碍合法用户

基于 IP 的速率限制配置：

limit_req_zone wholeforge zone=wholeforge:10m rate=3r/s;

location ^~ (/alopexlemoni/GenderDysphoria.fyi|/oror/necro|/Lymkwi/linux|/vc-archival/youtube-dl-original|/reibooru/reibooru) {
    limit_req zone=wholeforge nodelay;
    proxy_pass http://<upstream>/;
}

这种方法有两个致命缺陷：

爬虫使用大量住宅代理 IP，单个 IP 请求量不大但总量巨大
3r/s 的限制严重阻碍了合法用户的正常访问

3. 手动 IP/ASN 封锁：治标不治本

虽然可以手动封锁已知恶意 ASN（如华为云 AS136907、阿里云 AS45102），但：

爬虫会迅速切换到其他 ASN
住宅 ISP 的 IP 难以区分（如 VNPT Corp AS45899）
维护成本极高，需要持续更新黑名单

三、行为分析与指纹识别的技术原理

1. 用户代理一致性检查

Nam-Shub-of-Enki 分类器的核心创新在于用户代理的一致性验证。它检测用户代理字符串中的技术矛盾，例如：

时代错位：Windows NT 4 声称支持 Chrome 和 TLS 1.3
技术冲突：报告支持 HTTP/2 的客户端声称使用不支持 HTTP/2 的浏览器版本
未来声明：声称使用尚未发布的软件版本

这些矛盾表明用户代理是程序生成的 "伪造浏览器"，而非真实的人类用户。

2. AI 用户代理识别

分类器内置了完整的 AI 爬虫用户代理数据库，包括：

anthropic-ai、claude-web、claudebot（Anthropic）
chatgpt-user、gptbot、oai-searchbot（OpenAI）
google-extended、petalbot（Google）
amazonbot、facebookbot等商业爬虫

3. 请求模式分析

AI 爬虫的请求模式具有明显特征：

规律性攻击波：每 3 小时出现一次，持续 1.5 小时的攻击波
指数级增长：攻击开始时请求量呈指数增长
阈值触发停止：当服务器响应延迟达到阈值或开始返回错误时停止
IP 轮换策略：单个 IP 贡献 1-60 个请求，然后切换到下一个 IP

四、Iocaine 3 与 Nam-Shub-of-Enki 的工程实现

1. 系统架构

用户请求 → Nginx反向代理 → Iocaine 3中间件 → 分类决策
                                    ↓
                        合法请求 → 421重定向 → Git Forge
                        恶意请求 → 200 OK + 垃圾内容

2. Docker 部署配置

services:
  iocaine:
    image: algernon/iocaine:3
    volumes:
      - ./config:/etc/iocaine/config.d
      - ./data:/data
    environment:
      - RUST_LOG=iocaine=info
    logging:
      driver: "json-file"
      options:
        max-size: "50m"

3. Nam-Shub-of-Enki 分类器配置

checks {
    disable cgi-bin-trap
    
    asn {
        database-path "/data/ipinfo_lite.mmdb"
        asns "45102" "136907"
    }
    ai-robots-txt {
        path "/data/ai.robots.txt-robots.json"
    }
    generated-urls {
        identifiers "deflagration"
    }
    big-tech {
        enable #true
    }
    commercial_scrapers {
        enable #true
    }
}

logging {
    enable #true
    classification {
        enable #true
    }
}

4. Nginx 集成配置

关键配置：仅将 GET 和 HEAD 请求路由到 Iocaine，避免大文件上传被阻塞：

map $request_method $upstream_location {
    GET    <iocaine upstream>;
    HEAD   <iocaine upstream>;
    default <your actual upstream>;
}

map $request_method $upstream_log {
    GET    bot_access;
    HEAD   bot_access;
    default access;
}

location / {
    proxy_cache off;
    access_log /var/log/nginx/$upstream_log.log combined;
    proxy_intercept_errors on;
    error_page 421 = @fallback;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://$upstream_location;
}

location @fallback {
    proxy_pass http://<git forge upstream>;
}

五、监控指标与可落地参数

1. 核心监控指标

分类比例：目标 > 96% 请求被分类为机器人
垃圾数据量：每小时 150MB，每天 3.4GB，每周 22GB
请求速率：AI 爬虫维持 15 QPS（900 请求 / 分钟）
伪造浏览器：背景噪音 2-3 QPS，攻击波期间激增
资源使用：CPU 使用率从 99% 降至 4%，功耗降低 25%

2. 性能参数阈值

Iocaine CPU 时间：<25 毫秒 / 秒
垃圾生成延迟：<100 毫秒
分类决策时间：<10 毫秒
内存占用：<100MB（不含日志）

3. 攻击特征识别参数

攻击波周期：3 小时 ±15 分钟
攻击持续时间：1.5 小时 ±10 分钟
IP 贡献范围：1-60 请求 / IP
ASN 分布：重点关注 Datacamp Limited、GTT Communications、M247 Europe 等

4. 日志管理配置

分类日志大小限制：50MB
访问日志分离：机器人访问与正常访问分开记录
日志保留策略：分类日志保留 7 天，访问日志保留 30 天

六、防护效果与工程实践建议

1. 实测效果数据

实施 Iocaine 3 后：

服务器 CPU 使用率从 99%+ 降至 4%
内存使用稳定在 1.5-2GiB 范围
网络出口带宽恢复正常水平
服务器功耗从 200W 降至 150W
96.7% 的请求被正确分类为机器人

2. 工程实践建议

部署阶段：

先部署不带分类器的 Iocaine 2 进行测试
逐步添加 Nam-Shub-of-Enki 分类器
监控分类准确率和误判率
调整分类器参数优化性能

配置优化：

根据实际流量调整垃圾生成参数
定期更新 AI 用户代理数据库
监控攻击模式调整检测阈值
建立 ASN 信誉数据库

运维监控：

实现 Prometheus + Grafana 监控栈
设置分类比例告警（<95%）
监控攻击波模式变化
定期分析日志优化规则

3. 技术局限性认知

需要明确的是，Iocaine 不是让爬虫消失的魔法，而是：

资源转移：将服务器负载转移到爬虫端
成本增加：增加爬虫的数据处理成本
长期威慑：通过提供无价值数据降低抓取动机
误判风险：可能存在对特殊客户端的误判

七、未来展望与防御演进

1. 技术发展趋势

AI 爬虫进化：更智能的用户代理伪造和请求模式模仿
住宅代理滥用：更多来自家庭 ISP 的代理 IP 参与攻击
协议级攻击：可能出现的 Git 协议直接攻击
分布式协调：更复杂的爬虫网络协调机制

2. 防御技术演进方向

机器学习分类：基于请求序列的机器学习分类
行为指纹库：建立爬虫行为特征数据库
动态挑战：基于客户端能力的动态挑战生成
信誉系统：IP、ASN、用户代理的多维信誉评分

3. 社区协作建议

共享攻击特征：建立开源爬虫特征数据库
标准化防护接口：定义统一的爬虫防护 API
联合防御网络：建立自托管服务联合防御机制
法律与技术结合：推动技术防护与法律手段的结合

结语

保护 Git Forge 免受 AI 爬虫攻击是一场持续的技术攻防战。基于行为分析和指纹识别的防护系统，通过 Iocaine 3 和 Nam-Shub-of-Enki 分类器的组合，提供了有效的工程解决方案。然而，这仅仅是防御的开始，随着 AI 爬虫技术的不断进化，防御系统也需要持续迭代。

关键的成功因素在于：

深度理解攻击模式：不仅仅是技术实现，更是对攻击者行为模式的理解
多层防御策略：没有银弹，需要缓存、速率限制、分类器的组合
持续监控优化：防御是动态过程，需要基于数据的持续优化
社区协作：单个站点的防御有限，需要社区共享情报和工具

在 AI 时代，保护开源代码不仅是技术挑战，更是对开源精神的捍卫。通过技术手段，我们能够确保 Git 仓库继续为开发者服务，而不是成为 AI 训练的无偿数据源。

资料来源：

VulpineCitrus, "Guarding My Git Forge Against AI Scrapers", 2025-12-02
Iocaine 3 Documentation, "Nam-Shub-of-Enki Classifier", 2025
Jackson Chen, "I upgraded to iocaine v3 and rediscovered The Horrors of Generative AI scraping", 2025-11-23

ai-security

内容声明：本文无广告投放、无付费植入。

如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。