爬虫的 User-Agent 可以随意伪造。本文讲解网站如何核实一个自称 Googlebot 的爬虫是否真实：反向 DNS、IP 段、签名与运营方注册表。
User-Agent 请求头就是一段纯文本，任何脚本都可以把它设为 Googlebot/2.1 (+http://www.google.com/bot.html)，没有任何机制能阻止这么做。爬虫伪装者经常这么干，为的就是绕过那些只看这一个字段的简单机器人过滤器。与此同时，真正的 Googlebot、Bingbot 以及其他几十个正规爬虫，也确实是用同一个字段来自报家门的。一个想要对“Googlebot”另眼相待的网站，首先要回答一个问题：这个请求究竟是不是真的来自 Google，还是只是有人打对了那几个字？
核心要点
- User-Agent 中声明的身份本身不能证明任何事——它是纯文本，复制一个真实爬虫的字符串对任何想冒充它的人来说都只是一行代码的事。
- 正反双向确认的反向 DNS（forward-confirmed reverse DNS） 是最经典的检测方式：先查出源 IP 由谁控制，再用运营方自己发布的 DNS 记录反过来确认这个答案。
- 运营方公开发布的 IP 段列表 是一种更快、更省成本的替代方案（对维护这类列表的运营方而言），代价是更新之间存在陈旧窗口。
- 密码学签名（RFC 9421 / Web Bot Auth） 用证明取代推断：一次通过验证的签名，展示的是“哪把密钥签署了这个请求”，而不只是“这个请求来自哪个网络”。
- 运营方注册表是最新出现的选项——Cloudflare 的 BotBase 让运营方自行注册一个身份供网站直接查询，而注册表本身会替网站把 DNS、IP 段与签名这几道检测重新跑一遍。
- 这四种方法核实的对象各不相同，失效的方式也各不相同，因此弄清楚一个网站到底依赖哪一种检测，和弄清楚它是否存在检测本身同样重要。
声明是免费的，证明却不是
以下每一种检测手段存在的原因都指向同一个缺口：User-Agent 只是客户端对自己身份的一句声明，而客户端可以声明任何内容。普通浏览器同样如此——我们关于检测 User-Agent 伪造的文章讲的就是这个问题在浏览器一侧的表现——但一个自称身份的爬虫风险更高，因为信任“Googlebot”的网站往往会给它一些绝不会给匿名访客的待遇：不限速访问、绕过付费墙，或直接跳过挑战页面。核实这个声明，而不只是读取它，正是本文要讲的全部内容。
方法一：正反双向确认的反向 DNS
这是最古老、至今仍被广泛使用的检测方式，分两步进行——省略第二步，正是让第一步变得毫无意义的常见错误。
第一步——反向查询。 取出请求的源 IP 地址，查询它的 PTR 记录，PTR 记录会把一个 IP 映射回一个主机名。如果这确实是 Google 的爬虫，这个主机名应该以 googlebot.com、google.com 或 googleusercontent.com 结尾——这三个域名正是 Google 官方核实文档告诉站长可以认可的。
第二步——正向确认。 光有第一步得到的主机名还什么都证明不了，因为 PTR 记录是由掌管该 IP 地址所属反向 DNS 区域的人来控制的——而不是由你希望是谁在运营这个地址来决定。RFC 1912 正是记录了这类 DNS 配置错误与滥用风险，而 RFC 8499 里的 DNS 术语定义也在结构上说明了同一点：所谓反向 DNS，不过是由 IN-ADDR.ARPA 和 IP6.ARPA 这两个区域提供的“从地址到名字”这个方向，内容由持有该地址段委派权的一方自行填写，而不是由可信第三方签发的证书。所以检测还没结束。网站要把第一步得到的主机名拿去做正向解析——一次普通的 A/AAAA 查询——并检查结果是否落回最初的那个源 IP。只有当两个方向的结果彼此吻合，这个身份才站得住脚：一个不掌控 googlebot.com 的 DNS 的攻击者，无法让任意一个 IP 的 PTR 记录，恰好解析出一个又能正向解析回同一个 IP 的主机名。
这也是为什么这套两步流程被称为“正反双向确认”的反向 DNS，也是为什么单独一次反向查询算不上一种核实方法——它查到的只是一个由别人掌控的值。
方法二：运营方公开发布的 IP 段
有些爬虫运营方干脆跳过 DNS，直接发布自己抓取所使用的 IP 段列表。网站下载这份列表，检查请求的源 IP 是否落在其中，命中即视为通过核实。这只是一次集合归属判断——比两次 DNS 往返查询便宜得多——这在主流爬虫产生的请求量级下非常重要。
Google 发布的正是这样的列表：一组由 CIDR 地址块组成的 JSON 文件，按爬虫类别拆开——common-crawlers.json 对应搜索爬虫，special-crawlers.json 对应 AdsBot 这类产品，用户触发的抓取器另有单独文件。Google 官方文档把“比对这些文件”列为手动 DNS 往返之外的自动方案——同一个问题，更便宜的答法。
代价在于新鲜度。一份发布出来的地址段列表只是一张快照；如果运营方新增了地址段，而网站缓存的副本还没跟上，一个真实的爬虫短期内就可能过不了这道检测。而且这种方法只存在于那些有纪律去发布并维护列表的运营方身上——很多规模较小或较新的爬虫根本不这么做。
方法三：密码学签名
DNS 和 IP 段核实的都是某个网络——即持有该地址段的一方，或宣称拥有该地址段的一方。签名核实的是另一件事：持有某把特定私钥的一方。运营方使用 HTTP 消息签名（RFC 9421） 为每个外发请求签名，Web Bot Auth 架构草案（一份仍在改版、连名字都还在变的 IETF 互联网草案，而非已定稿的标准）正是基于这一标准，运营方同时会公开对应的公钥。网站用这把公钥验证签名，完全不需要过问请求来自哪个 IP 地址。
我们的机器人检测技术指南在“密码学机器人身份：Web Bot Auth”一节完整讲解了这套机制——如果你想了解底层的密码学原理，值得一读；这里更要紧的一点比较窄：签名检测回答的是“哪把密钥签了这个请求”，这和“这个请求来自哪个网络”是两个不同的问题，二者的答案有时会不一致，这一点值得留意。
方法四：运营方注册表
2026 年为同一个问题添加了第四种答案。与其让每个网站各自从网络地址或密钥中推断身份，运营方现在可以在一个注册表里注册一次，由注册表替所有网站去做这件推断的事。Cloudflare 面向运营方的 BotBase（2026 年 8 月 28 日上线）让机器人运营方提交并维护自己的注册条目——声明自己是谁、做什么、可以如何被核实——并跟踪这份提交在待审核、通过、驳回等状态之间的流转，通过之后才拿到“已验证”标记。
关键在于审核过程中发生了什么。Cloudflare 不会照单全收这份声明：它会检查运营方声称的核实方式是否真的成立，逐项验证对方的 IP 段列表、反向 DNS 配置以及 Web Bot Auth 签名。换句话说，注册表并不是要取代前三种方法——它只是把这三道检测集中跑一次，让每个网站可以直接取用一个结论，而不必各自把同样的三道检测再造一遍。
与之对应的网站一侧则是 Bot Preference Sync，方向正好反过来：站长在控制台里一次性设定自己对搜索类、智能体类、训练类爬虫的策略，Cloudflare 会自动把对应规则写进这个站点的 robots.txt。那是一套策略机制，而不是核实机制——但两者只有配合起来才有意义，因为一条写给“Googlebot”的偏好设置，其价值完全取决于这个网站有没有能力判断来读它的东西真的是 Googlebot。
为什么这个顺序不是随意排的
这四种检测并不是同一件事被逐级做得更好。前三种核实的是三个截然不同的对象，第四种则是替你把前三种跑一遍，而它们各有各的失效方式：
- 正反双向确认的反向 DNS 与公开的 IP 段核实的是网络。 它们会因 DNS 配置错误或地址段列表过期而失效——两者都是把真实爬虫挡在门外的漏判；概率低得多的另一种情况，是攻击者不知怎地同时掌控了他所获取的某个地址的正向和反向区域（罕见，但对一个资源充足的攻击者来说并非不可能）。
- 签名核实的是密钥持有者。 只有在私钥泄露时才会失效——这是密码学与运维安全层面的问题，和 DNS 或网络拓扑毫无关系。
- 注册条目核实的是注册表替你查过的那些东西。 它的强度完全等于背后那几道检测的强度，同时额外带来两种失效方式：注册机构自身审核不严，以及一个合法运营方还没来得及注册。
一个网站如果只依赖其中一种检测，实际上就是在不自知的情况下只信任了这一种失效方式。把它们组合起来——用注册表查询打头，对注册表里没有的运营方再回落到自己的 DNS 检测——意味着攻击者要攻破的不只是最薄弱的那一环，同时也不会因为一份过期列表就把真实爬虫挡在门外。
这对你自己的浏览器意味着什么
以上四种方法，没有一种是普通浏览器能够提供的。它们的存在是为了那些一开始就自报身份的自动化爬虫；一个普通上网的人从来不会主动发送一个需要被核实的身份声明。这正是为什么网站要为普通访客准备一整套完全不同的工具——浏览器与网络指纹识别——从没有人主动声明过的信号中拼出一幅会话画像。如果你想从另一个角度看看这是什么样子，BrowserInsight 的机器人检测工具会展示检测系统在一个没有任何身份声明可核实的会话上，能观察到的那些相同的客户端信号。
本文的范围是刻意收窄的。这篇指南只讲一件事——核实一个已经自称是某个特定身份的爬虫。它不讲如何仅凭客户端信号，把不受欢迎、未声明身份的自动化和真实访客区分开来（参见我们的机器人检测技术指南）；它不讲一个 AI 智能体如何用真人自己的凭证驾驭这个人真实的浏览器（参见 AI 智能体流量检测）；它也不讲一个真人如何在不被追踪的前提下证明自己是人（参见网络匿名凭证）。这些都是不同的问题，答案也各不相同；本文只专注于把“这个请求自称是 Googlebot”，从一句被信任的字符串，变成一个经过核实的事实。
常见问题
只要 User-Agent 写着 Googlebot，我就能直接信任它吗？
不能。User-Agent 是客户端自行设置的纯文本，没有任何机制能阻止某个脚本原样复制一个真实爬虫的字符串。应该把 User-Agent 声明当作一个待核实的断言，而不是既成事实——用上文的某种方法去核实，而不是直接相信这串文字本身。
反向 DNS 和“正反双向确认”的反向 DNS 有什么区别？
单纯的反向（PTR）查询只能告诉你这个 IP 的管理者选择公开了哪个主机名——如果你本来就不信任这个管理者，这什么都证明不了。正反双向确认的反向 DNS 多加了一步：把这个主机名再做一次正向解析，检查它是否落回最初的那个 IP。省略这一步正向确认，是这项检测中最常见的一个错误。
密码学签名是不是绝对优于基于 DNS 的核实？
它们核实的是不同的东西，所以“更好”取决于你需要什么。签名证明的是哪把私钥签署了一个请求，与网络位置无关，因此在抵御 IP 伪造方面更强。但它只对已经采用签名机制的运营方生效，而正反双向确认的反向 DNS 只要 DNS 配置正确就能用，无论对方是否采用了签名机制。
我还需要检查请求的 TLS 或 TCP 指纹吗？
这是一个独立的、起补充作用的信号，而不是替代品——我们的TCP/IP 指纹识别指南讲解了网络层特征如何暴露“声明的客户端”与“实际协议栈”之间的不匹配，这在身份核实之外很有用，但它本身并不能确认这究竟是谁的爬虫。
Googlebot 核实能防住所有伪造的爬虫吗？
它只针对一种特定的威胁：伪装成某个已知的、可核实身份的运营方的请求。对于那些从一开始就没有自称是 Googlebot 的未声明抓取流量，它无能为力——那类流量需要的是我们机器人检测技术指南里覆盖的更广泛的机器人检测信号，而不是身份核实。
