Git.kernel.org为何吸引爬虫？源码仓库的访问识别与防护策略

最近在翻看内核社区讨论时看到一句很有意思的话Git.kernel.org is interesting to crawlers。这句话来自 Linux 内核基础设施维护者的观察意思是 Git.kernel.org 正在被越来越多的网络爬虫盯上。以前我们提到爬虫更多想到的是电商网站、新闻门户、社交媒体。现在源码托管仓库也成了爬虫的重点目标。站在爬虫的角度Git.kernel.org 确实“很有趣”它是 Linux 内核官方源码的发布入口之一包含大量历史版本、分支、标签和补丁任何一次 commit 都有可能在后续版本中被回溯、对比、分析。对安全研究、代码审计、AI 训练语料收集、学术分析、漏洞挖掘来说这里的数据价值非常高。但对 Git.kernel.org 的运维者来说爬虫带来的不只是流量还有带宽压力、资源占用、日志噪音甚至可能被误判为恶意攻击。本文将围绕“Git.kernel.org 为什么会对爬虫有趣”这条线索展开从内核源码仓库的架构、Git 对象存储特性、常见爬取方式、访问日志识别、防护策略到工程最佳实践完整拆解一遍。无论你是运维人员、爬虫开发者还是对 Git 协议感兴趣的读者都能从中学到一套可落地的思路。1. 背景与核心概念1.1 Git.kernel.org 是什么Git.kernel.org 是 Linux 内核社区官方使用的 Git 托管服务器承载着 Linux 内核、Linux 工具链以及大量内核相关子项目的 Git 仓库。它和 kernel.org 主站、lkml.org 邮件列表等共同组成了 Linux 内核开发的公共基础设施。日常开发中国内开发者更熟悉通过国内镜像或者 GitHub 上的镜像仓库获取内核源码但 Git.kernel.org 仍然是许多自动化构建工具、CI 系统、研究机构直接从上游拉取源码的首选地址。它的仓库结构非常庞大。以 torvalds/linux.git 为例这个仓库不仅包含当前主干代码还包含整个 Linux 内核从诞生到现在的完整提交历史、数万个分支、数十万个标签。单是.git目录内的对象文件体积就可能达到数 GB 甚至更大。对爬虫开发者来说这样一个庞大的目标意味着数据量大单次完整抓取耗时很长。数据更新频率高内核社区每天都有大量新补丁合入。数据结构复杂不是简单的 HTML 页面而是 Git 对象数据库。访问价值高一次抓取往往对应大量高密度代码文本。正因为这些特点Git.kernel.org 才会被爬虫“特别关注”。1.2 爬虫为什么会关注 Git 仓库爬虫的核心目标是“采集有价值的数据”。传统爬虫从 HTML 页面中提取信息而 Git 仓库本身就是一个结构化的数据源里面每个文件的完整历史、每次提交的 diff、每个 commit message、每个 tag 都是结构化数据。从数据消费端的角度来看Git 仓库爬取有几个常见动机代码搜索索引建立全量代码搜索引擎需要定期抓取所有 commit。漏洞挖掘通过 diff 分析安全补丁定位修复点。开源 License 合规分析扫描每个文件的开源许可声明。AI 模型训练收集高质量代码语料。学术研究分析软件演化、代码质量、贡献者行为。这些动机本身是正当的但如果爬取方式不当比如用传统的 HTTP 请求逐个抓取目录页面或者在短时间内发起大量并发请求就会给仓库服务器造成很大的负担。这里要区分两个概念源码浏览和源码拉取。Git.kernel.org 提供了多种方式供用户获取源码方式常见工具特点HTTP 源码浏览curl、wget、浏览器逐个文件下载适合小范围获取Git 克隆git clone完整复制仓库适合全量获取浅克隆git clone --depth只获取最近 N 次提交归档下载cgit 提供的 tar.gz获取某个版本快照增量拉取git fetch在已有克隆基础上更新爬虫如果选错了方式比如用 HTTP 请求去爬 .git 目录下的裸对象文件不仅效率极低还会对服务器造成大量随机的磁盘 I/O。这就是 Git 仓库类网站“防爬”的难点所在。1.3 Git 仓库与普通网站的区别要理解为什么 Git.kernel.org 对爬虫来说“有趣”先要理解 Git 仓库和普通网站的本质区别。普通网站页面 HTML 是服务端动态生成或静态返回的爬虫只需要发 HTTP 请求解析页面即可。服务器看到的是一连串常规 URL。Git 仓库底层是一套对象数据库对象类型包括 blob文件内容、tree目录树、commit提交记录、tag标签。git clone 本质上是在执行一次对象枚举 内容传输的过程。服务器端Git 提供两种传输协议哑协议dumb protocol直接通过 HTTP 暴露.git目录内的文件。这种方式简单但是效率低已经被现代 Git 服务器废弃。智能协议smart protocol客户端先请求/info/refs?servicegit-upload-pack服务器返回引用列表再由客户端发起git-upload-pack请求获取对象数据。现在 Git 服务器使用的都是智能协议。爬虫如果只懂普通 HTTP 抓取不理解智能协议很可能直接请求.git/objects/xx/xxxx...这样的路径。而智能协议下这些路径并不会直接一一对应到可访问的文件得到的结果要么是 404要么是服务端发起的额外计算响应。正确的爬取姿势应该直接使用git clone或git archive这样的高层工具而不是自定义 HTTP 客户端逐文件抓取。2. 环境准备与前置了解本文核心是分析 Git 服务器日志、识别爬虫特征、配置访问控制和优化源码获取方式。下面以常见的 Linux 服务器环境为例介绍需要准备的工具和版本情况。2.1 软件环境软件用途版本说明Linux 发行版运行 Git 服务器或日志分析环境本文以 Ubuntu/Debian 系列为例git源码克隆、仓库分析建议 2.30curl/wgetHTTP 请求测试系统自带nginx/apache反向代理或静态托管服务版本不影响核心方案cgitGit 仓库的 Web 浏览前端如果需要网页访问仓库时使用jqJSON 日志解析可选便于处理结构化日志版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你是本地实验不需要完全复刻 Git.kernel.org 的硬件环境只需要一个安装了 Git 的 Linux 虚拟机或开发机即可。2.2 观察目标先克隆一个小仓库做实验为了不把 Git.kernel.org 当作实验对象建议先在自己本地创建一个测试仓库模拟爬虫行为观察 Git 服务器的日志变化。下面我会使用本地测试仓库做演示方便理解原理。mkdir /tmp/git-lab cd /tmp/git-lab git init --bare test-repo.git这个命令创建了一个裸仓库模拟服务器端仓库结构。后续我们会在另一目录克隆它模拟客户端和爬虫行为。2.3 需要理解的关键路径在 Git HTTP 智能协议中有几个核心 URL 值得特别注意它们也是日志分析和访问控制最常用的路径路径作用正常的请求频率/repo.git/info/refs?servicegit-upload-pack获取仓库引用列表每次 clone/fetch 一次/repo.git/git-upload-pack传输对象数据每次 clone/fetch 一次/repo.git/objects/xx/xxxx哑协议下的对象读取已废弃正常很少见/repo.git/log/cgit 页面浏览手动浏览时产生/repo.git/commit/xxxcgit 单次提交页面手动浏览时产生理解这些路径后看日志时就能快速判断哪些请求是正常的 Git 操作哪些是爬虫在乱抓。3. 爬虫视角下的 Git 仓库为什么“有趣”下面换个角度站在爬虫开发者的视角分析 Git.kernel.org。理解了对方的思路才能更好地防护。3.1 从 robots.txt 开始的侦察爬虫分析一个网站时第一步通常是查看robots.txt文件了解哪些路径允许抓取。Git.kernel.org 的 cgit 前端一般也会提供这个文件。用 curl 模拟一下curl -s https://git.kernel.org/robots.txt正常输出可能包含类似规则User-agent: * Disallow: /pub/scm/linux/kernel/git/这个文件告诉合规爬虫不要抓取/pub/scm/路径下的内容。其中/pub/scm/是 Git 仓库实际存储和服务的路径前缀。合规爬虫看到后会停止抓取但不少爬虫会忽略 robots.txt或者把它当作一个“发现目录结构”的入口继续深入。注意robots.txt 更多是一种友好约定对恶意爬虫没有强制约束力真正的防护还需要结合访问控制。3.2 HTTP 直接抓取 vs Git 协议如果一个爬虫没有用过 Git它可能会尝试直接下载目录中看到的文件。比如看到 URL 中包含.git就尝试访问curl -I https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/objects/这种请求在 cgit 下可能返回 404 或目录列表。原因是智能协议下对象路径不是静态文件路径。即便服务器开启了 dumb protocol单个对象文件的访问也需要先知道对象的 SHA-1 值而 SHA-1 值本身又是散落在大量 pack 文件中的。这种抓取方式效率极低却会给服务器带来大量无意义的文件系统查询请求。从日志中看这类爬虫的请求会频繁命中/objects/、/info/、/logs/路径且 User-Agent 各不相同。3.3 浅克隆爬虫最常用的最小化策略对爬虫来说全量克隆 torvalds/linux.git 成本很高仓库体积可能几十 GB。为了节省存储和带宽很多爬虫会使用浅克隆shallow clone比如git clone --depth 1 --branch v6.6 \ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-snapshot这个命令只拉取最新一个 commit 对应的文件快照不包含历史对象。对只是想获取某一版本内核源码的爬虫来说浅克隆非常高效。但大量浅克隆请求会带来一个问题服务器必须响应git-upload-pack的多次对象枚举请求。如果同一时间并发过高即使--depth 1也会消耗较多 CPU 和带宽。3.4 获取某个版本归档Git.kernel.org 通过 cgit 提供 tar.gz 归档下载例如curl -L -o linux-6.6.tar.gz \ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-6.6.tar.gz这类请求一旦触发服务器需要动态打包整个 tree非常消耗 CPU。对爬虫来说这相当于“一键下载完整快照”比逐文件抓取高效。因此归档接口也是运维防护的重点。3.5 爬虫为何被服务器“关注”综合来看Git 仓库类网站的爬虫有四个特征特征说明风险等级高频率 IP 访问大量请求集中在同一 IP 或 IP 段中高带宽占用克隆大数据量仓库单次下载可达数 GB高并发连接多同时建立数十上百个连接高使用非主流 UA自定义 User-Agent 或直接留空中服务器日志中一旦出现这类模式运维人员就会发出类似“is interesting to crawlers”的感叹。这不是褒义而是提醒大家爬虫流量正在干扰正常服务。理解这一点后下面进入实战如何从日志中识别爬虫并配置有效的防护策略。4. 实战一从访问日志中识别爬虫特征爬虫识别是防护的第一步。如果日志分析不出来防护策略就是盲目的。4.1 Git 服务器日志格式无论使用 Apache 还是 Nginx 托管 Git 服务日志一般都会记录客户端 IP请求时间请求方法GET/POST请求路径HTTP 状态码User-Agent传输字节数以 Nginx 默认格式为例log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent;在nginx.conf中配置后来自 Git 客户端的请求会像下面这样记录203.0.113.10 - - [12/Jan/2025:10:15:32 0800] GET /pub/scm/linux/kernel/git/torvalds/linux.git/info/refs?servicegit-upload-pack HTTP/1.1 200 12345 - git/2.39.2 203.0.113.10 - - [12/Jan/2025:10:15:33 0800] POST /pub/scm/linux/kernel/git/torvalds/linux.git/git-upload-pack HTTP/1.1 200 5678901 - git/2.39.2这两条日志代表一次完整的git clone请求先 GET 拿引用再 POST 获取对象。这是正常 Git 客户端的标准行为。4.2 用命令行统计可疑访问现在假设我们拿到一份 access.log用 Linux 命令快速分析。第一步按 IP 统计请求次数awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20输出示例54210 203.0.113.10 3051 198.51.100.23 932 192.0.2.55看到某个 IP 请求次数高达 5 万次而其他 IP 只有几千次说明该 IP 存在明显的集中访问行为。第二步查看该 IP 具体请求了哪些路径grep 203.0.113.10 /var/log/nginx/access.log | awk {print $7} | sort | uniq -c | sort -rn | head -30如果结果集中在/info/refs?servicegit-upload-pack/git-upload-pack/objects//snapshot/说明该 IP 正在反复执行 clone 或 fetch可能是爬虫脚本也可能是一个频繁更新的 CI 系统。第三步查看 User-Agent 分布awk -F {print $6} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20正常输出中常见 UA 有git/2.39.2git/2.40.0curl/8.0.1Go-http-client/1.1浏览器 UA如果看到大量留空 UA、Python requests UA、或者某些自定义 UA就要重点排查。4.3 使用 Python 脚本做多维度分析命令行适合快速排查但如果要做周期性监控建议写一个简单脚本。下面的示例脚本统计每个 IP 在 5 分钟内请求 Git 协议接口的次数超过阈值则输出告警。#!/usr/bin/env python3 # 文件路径analyze_git_access.py import re import sys from collections import defaultdict from datetime import datetime LOG_PATTERN re.compile( r(?Pip\d\.\d\.\d\.\d) .* \[(?Ptime[^\]])\] r(?Pmethod\S) (?Ppath\S) [^]* r(?Pstatus\d) (?Pbytes\d) ) GIT_API_PATHS ( /info/refs, /git-upload-pack, /git-receive-pack, ) def parse_log(filepath): ip_count defaultdict(int) ip_time defaultdict(list) with open(filepath, r, encodingutf-8, errorsignore) as f: for line in f: m LOG_PATTERN.search(line) if not m: continue ip m.group(ip) path m.group(path) if any(key in path for key in GIT_API_PATHS): ip_count[ip] 1 return ip_count if __name__ __main__: log_file sys.argv[1] if len(sys.argv) 1 else /var/log/nginx/access.log threshold int(sys.argv[2]) if len(sys.argv) 2 else 100 result parse_log(log_file) print(fGit 协议请求次数统计阈值{threshold}) for ip, count in sorted(result.items(), keylambda x: x[1], reverseTrue): if count threshold: print(f{ip}\t{count})运行方式python3 analyze_git_access.py /var/log/nginx/access.log 100这个脚本的作用是把大量日志浓缩成一张可疑 IP 列表。实际生产环境中可以接入 cron 定时执行并将结果推送到告警群。4.4 识别语义异常请求除了请求频率还要关注请求路径的语义。正常 Git 客户端的请求路径一定是标准协议路径。而爬虫请求经常出现/pub/scm/linux/kernel/git/torvalds/linux.git/根路径被反复请求。.git目录下的config、HEAD、index等文件名被直接下载。?formatjson、?formattxt之类的参数被附加在任意页面后面。请求同时带有curl和wgetUA说明是手工批量操作。这些语义异常配合高频请求基本可以判定为爬虫行为。5. 实战二构建防护与限流策略识别出爬虫后需要采取防护措施。防护的原则是不影响正常用户和正常 Git 客户端尽可能降低误杀。5.1 robots.txt 规范声明在 Git 服务的 Web 根目录放置 robots.txt是成本最低、最基础的策略。# 文件路径/var/www/html/robots.txt User-agent: * Disallow: /pub/scm/这个文件告诉合规爬虫/pub/scm/下的仓库内容不在允许抓取范围内。对普通搜索引擎爬虫有一定约束力对自定义爬虫则取决于其是否遵守协议。5.2 Nginx 层限流Nginx 的limit_req模块可以对 Git HTTP 接口进行访问频率限制。下面是一个配置示例# 文件路径/etc/nginx/conf.d/git.kernel.org.conf limit_req_zone $binary_remote_addr zonegit_req:10m rate10r/s; server { listen 443 ssl; server_name git.kernel.org; location ~ ^/pub/scm/.*\.git/ { # Git 智能协议中的 POST 请求用于传输对象不能简单限制 if ($request_method POST) { limit_req zonegit_req burst5 nodelay; } proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }注意这里对 GET 请求不做限制因为 GET 可能是浏览器查看页面或 Git 客户端获取引用。对 POST 请求做限流是因为git-upload-pack通常以 POST 方式传输大量 POST 请求意味着大量数据拉取。更精细的做法是直接限制单个 IP 的下载速度防止某个爬虫占满带宽location ~ ^/pub/scm/.*\.git/ { # 单 IP 限速 1MB/s limit_rate 1m; proxy_pass http://127.0.0.1:8080; }5.3 基于 User-Agent 的拦截对于明显异常的 User-Agent可以在 Nginx 层直接返回 403。location /pub/scm/ { if ($http_user_agent ~* (python-requests|scrapy|curl/7\.68|wget)) { return 403; } proxy_pass http://127.0.0.1:8080; }这里需要非常谨慎。很多正常运维脚本也使用 curl 和 wget如果直接拦截可能误伤自己的自动化任务。更推荐的做法是只拦截确定异常的 UA比如自定义的爬虫 UA。5.4 使用防火墙或云安全组封禁 IP如果日志分析确认某个 IP 是恶意爬虫并持续攻击可以在防火墙层面封禁。# 封禁单个 IP sudo iptables -A INPUT -s 203.0.113.10 -j DROP # 封禁一个 IP 段 sudo iptables -A INPUT -s 203.0.113.0/24 -j DROP不过直接封禁 IP 的缺点也很明显爬虫可以随时换 IP而真实用户如果恰好共用该 IP 段也会被误伤。因此IP 封禁更适合作为临时措施而不是长期方案。5.5 限制 Git 服务端并发Git 服务端本身也有并发控制。对于 GitLab、Gitea、cgit 等不同的服务端软件控制方式不同。以 Git 自带的 HTTP 后端为例可以通过GIT_HTTP_MAX_REQUEST_BUFFER限制单个请求体大小避免超大请求拖垮服务# 环境变量方式 export GIT_HTTP_MAX_REQUEST_BUFFER100M如果使用 GitLab可以在配置中调整gitlab_rails[git_max_size]等参数。核心思路是限制单次上传/下载的数据量降低爬虫对带宽的占用。5.6 提供更友好的数据获取方式防爬不只是“堵”更好的是“疏”。很多爬虫之所以直接抓页面是因为不知道正确的源码获取方式。作为服务提供方可以在首页显著位置提供 Git 克隆命令示例git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git同时提供镜像下载地址、发行版源码包说明让数据需求方用最标准的方式获取数据。这样既能降低服务器压力也能减少爬虫进入“硬抓”模式的情况。6. 常见问题与排查思路在实际运维 Git 仓库服务器时会遇到各种和爬虫相关的问题。下表整理了几类高频问题。问题现象常见原因解决思路大量请求集中在/objects/路径爬虫尝试使用哑协议直接下载对象文件关闭 dumb protocol仅启用 smart protocol在 Nginx 层拒绝/objects/直接访问某个 IP 带宽占用异常高正在 clone 超大仓库或反复下载 tar 包限制单 IP 下载速度检查访问日志确认 UA必要时封禁该 IProbots.txt 被请求频率异常高有爬虫在扫描路径寻找隐藏入口正常现象但需要关注后续是否伴随大量/pub/scm/请求Git 克隆正常但网页浏览很慢爬虫并发请求 cgit 页面消耗数据库和进程对网页路径单独限速启用 cgit 缓存日志中出现大量git-upload-pack请求爬虫或 CI 工具频繁 fetch统计来源 IP如果是 CI可申请专属镜像仓库如果是爬虫限流或封禁正常用户 clone 被 403User-Agent 过滤规则过于宽泛检查 Nginx 的 UA 匹配规则改为白名单方式日志中有大量 curl/wget 请求爬虫脚本直接下载合理设置 UA 拦截结合频率限制遇到爬虫问题时排查顺序建议按下面 5 步走先看请求频率最高的 10 个 IP。再按 IP 分析请求路径。统计 User-Agent 分布判断是否来自常见的爬虫框架。查看这些请求的响应状态码判断它们是成功获取数据还是被反复拒绝。根据分析结果决定采用限流、限速、封禁还是提供明确入口。7. 最佳实践与工程建议前面讲了具体操作这里再补充一些工程层面的思考。因为 Git 仓库服务器和普通 Web 站的爬虫防护有很多不同点如果照搬普通站点的经验很容易误伤正常用户。7.1 对爬虫开发者的建议如果你的目标是从 Git 仓库获取代码数据请务必使用标准工具而不是自己写 HTTP 爬虫去抓对象文件。推荐做法用git clone --depth 1获取快照避免全量克隆带来的资源浪费。用git fetch增量更新已有仓库避免重复全量拉取。限制并发数例如同时最多 4 个 clone 任务每个任务间隔 10 秒以上。设置合理的 User-Agent标明来源和联系方式方便仓库管理员在异常时联系你。如果只是需要一个版本的内核源码优先选择镜像站或发行版源码包而不是直接压向 Git.kernel.org。下面是一个更规范的抓取脚本片段#!/bin/bash # 文件路径fetch_linux_snapshot.sh REPO_URLhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git BRANCHv6.6 if [ ! -d linux-snapshot ]; then echo 开始浅克隆 $BRANCH ... git clone --depth 1 --branch $BRANCH $REPO_URL linux-snapshot else echo 仓库已存在执行增量更新... cd linux-snapshot git fetch --depth 1 origin $BRANCH git checkout $BRANCH fi这个脚本先检查本地是否有已经克隆的目录有则执行增量更新没有则浅克隆。和每次全量下载相比资源占用低很多。7.2 对 Git 仓库运维者的建议7.2.1 做好访问日志分析不要等服务器报警才去看日志。建议提前配置日志切割和归档例如每天切割一次 access.log保留最近 90 天。同时将关键 Git 协议请求单独输出到独立日志文件避免和普通页面请求混在一起。Nginx 中可以用如下配置location ~ ^/pub/scm/.*\.git/ { access_log /var/log/nginx/git-access.log git_main; proxy_pass http://127.0.0.1:8080; }这样分析 Git 协议请求时只需要读取一个文件不用在几十 GB 的混合日志里搜索。7.2.2 启用缓存和 CDNcgit 页面的动态生成很消耗资源。可以启用 cgit 的缓存功能减少每次页面请求的渲染开销。对于 tar.gz 快照下载尽量生成静态归档文件而不是每次请求时动态打包。如果条件允许可以放置一层 CDN。但注意Git 智能协议传输大对象时CDN 回源配置需要仔细调优否则反而会增加延迟。7.2.3 日志留痕与合规如果有人通过爬虫对服务器造成严重影响日志是追查的重要依据。生产环境务必保留足够长周期的访问日志并在隐私合规框架内处理日志数据。对外提供源码是开源社区的常规操作但通过日志留痕保护服务可用性、识别恶意行为同样是运维的必要环节。7.2.4 分级响应不要一开始就把所有可疑 IP 都封掉。建议按梯度处理级别条件处理方式L1请求频率略高但 UA 正常观察不做处理L2请求频率高UA 为常见爬虫框架限速limit_rateL3频繁访问非标准路径且携带危险参数拒绝403L4持续攻击影响正常服务临时封禁 IP并通知相关部门使用梯度策略可以让正常用户和正常爬虫都尽量不受影响。7.2.5 考虑镜像分流Git.kernel.org 本身承载了大量开发者的克隆需求但普通研究者和爬虫如果都涌向它压力自然很大。运维方可以搭建自己的官方镜像把流量分流到不同机房。对爬虫等做适当引导让它们通过镜像或者归档文件获取数据正本清源。8. 从内核仓库到通用 Git 服务一套可复用的方法论前面所有分析虽然以 Git.kernel.org 为例但方法论适用于任何基于 Git 的源码托管服务。GitHub、GitLab、Gitea、自建 Git 服务器都会遇到相似的爬虫困扰。你可以在自己的服务器上做一次演练# 模拟爬虫请求请求 info/refs 接口 curl -s http://your-server.test/repo.git/info/refs?servicegit-upload-pack然后查看日志观察这条请求记录。再模拟正常 clonegit clone http://your-server.test/repo.git /tmp/repo-test对比两条日志你会发现正常 Git 客户端只产生了两次请求而乱写的爬虫脚本可能会产生数十次无效请求。这就是 Git 仓库服务器日志分析的入门练习。理解了正常请求和异常请求的差异你就能针对不同场景写出更合理的防护规则。核心依然是那句话不要让爬虫用错误的方式拿到数据也不要让正常用户因为爬虫的干扰拿不到数据。Git.kernel.org 对爬虫来说是“有趣”的目标但对我们来说更值得关注的是如何让它持续稳定地服务全球内核开发者。