如何验证 AI 爬虫是否名副其实

您的服务器日志显示来自 GPTBot 的请求。应该信任它吗？

诚实的回答是：不能仅凭这个字符串。 用户代理标头是客户端对自身的声明，任何客户端都可以声明任何内容。 curl -A "GPTBot" 只需要大约四秒就能输入。如果您的 robots.txt 策略、分析或付费墙逻辑基于用户代理字符串进行分支，那么它实际上是在基于未经验证的输入进行分支。

好消息是，大多数主要的 AI 爬虫都提供了一种验证方式。坏消息是，有相当一部分爬虫根本不提供任何验证方式，而有一整类爬虫从设计上就是无法验证的。本文将介绍每种验证方法的工作原理、哪些爬虫支持哪些方法，以及在哪些情况下诚实的回答仍然是“你无法判断”。

用户代理字符串是一种声明，而不是身份

有三件事值得区分：

• 识别 — 爬虫告诉你它是谁（用户代理字符串）。
• 验证 — 你根据运营商控制的某种方式独立确认该声明。
• 授权 — 你决定该已验证身份允许执行哪些操作。

robots.txt 工作在第三层，但无法访问第二层。它是一种建议性协议：RFC 9309 标准化了语法和合规期望，但没有提供强制执行的机制。忽略你的 Disallow 的爬虫并没有破坏技术控制；它只是在拒绝一个请求。而一个 冒充 行为良好的爬虫则会继承你授予原爬虫的任何特权。

这在 2026 年比在 2020 年更重要，因为这些特权现在是真实的。网站允许 AI 爬虫出现在模型答案中、按每次爬取付费计量，或者免除机器人挑战。所有这些都构成了有人穿上这身“戏服”的理由。

三种验证方法，从最强到最弱

反向 DNS 配合正向确认

这是经典方法，对于支持它的运营商而言，仍然是最稳健的。你获取请求的 IP，将其解析为主机名（PTR 记录），检查该主机名是否以运营商控制的域名结尾，然后将该主机名 再次 解析回 IP，并确认其与原始 IP 匹配。

正向确认步骤不是可选的。PTR 记录是由控制该 IP 块反向区域的人设置的，因此如果不再次进行正向解析，你就是在信任攻击者控制的记录。

记录了反向 DNS 后缀的运营商包括 Google（.googlebot.com / .google.com）、Microsoft（.search.msn.com）、Amazon（.crawl.amazonbot.amazon）、Apple（.applebot.apple.com）和 Common Crawl（.crawl.commoncrawl.org）。

已发布的 IP 范围

运营商发布一个包含其爬虫使用的 CIDR 块的 JSON 文件；你检查 IP 是否在其中。OpenAI 在 openai.com/gptbot.json 提供了此文件，这是实际中最常用的方法——在我们的注册表中，41 个爬虫中有 20 个记录了 IP 范围验证，使其成为支持最广泛的单一检查方式。

有两个操作注意事项。列表会变化，因此应按计划获取并缓存它，而不是硬编码；并且范围的可信度仅与运营商自身基础设施的卫生情况相当——共享云范围的可信度低于专用范围。

Web Bot Auth 签名

这是未来的方向，也是唯一通过密码学而非网络拓扑证明身份的方法。机器人使用 HTTP 消息签名用私钥对其 HTTP 请求进行签名，在可发现的 JWKS 目录中发布公钥，你的服务器验证签名。它正在 IETF 中推进，Cloudflare、Akamai 和 AWS 已在验证方实现了支持。

以下是来自运营商方的诚实现状，这部分大多数文章都跳过了：通过检查我们注册表中所有 41 个爬虫的主要文档，我们无法确认有任何一个今天发布了可以验证的签名代理域名和 JWKS URL。 基础设施存在；但运营商方的部署尚未以站点所有者可以实际操作的方式记录。将 Web Bot Auth 视为需要构建的目标，而不是本季度可以依赖的功能。

41 个爬虫实际支持哪些验证方式

统计注册表中支持的验证方法数量（一个爬虫可以支持多种）：

一个爬虫可以记录多种方法，因此前三行存在重叠：41 个爬虫中有 25 个至少支持一种网络级检查，剩余 16 个不支持任何检查。 对于这 16 个，用户代理字符串是运营商发布的唯一标识符，没有任何东西可以用来验证。你可以允许它们，也可以阻止它们，但你无法验证它们。（这 16 个中的一个，Google-Extended，甚至没有用户代理字符串——见下文。）

按用途划分，同样的 41 个爬虫可分为：13 个用户触发的获取器（代理因为人类刚刚提问而获取页面）、10 个搜索引擎索引爬虫、9 个训练爬虫、4 个代理浏览器、3 个数据提供商，以及 2 个纯退出令牌——Google-Extended 和 Applebot-Extended 根本不是爬虫，而是控制已获取页面如何使用的 robots.txt 令牌。

在编写任何 Disallow 之前，理解这一区别是值得的。阻止一个训练爬虫不会损失任何引荐流量。阻止一个用户触发的获取器则意味着人类询问其助手关于你页面的信息时，助手可能无法读取它。

完全无法验证的类别

代理浏览器是一个真正不同的问题。它们是由 AI 代理代表用户驱动的真实浏览器引擎。它们不携带稳定的机器人令牌，因为从网络的角度看，它们 就是 一个浏览器：真实的 Chrome 用户代理、真实的 TLS 指纹、真实的 JavaScript 执行。

该注册表跟踪了四个这样的浏览器，而列表本身的变动也具有启发性：ChatGPT Atlas（OpenAI）和 Comet（Perplexity）是当前的，而 OpenAI 的 Operator 和 Google 的 Project Mariner 已被记录为已弃用——在十八个月内被取代。无论你在这里构建什么，都要构建成可替换的。

没有用户代理字符串可以匹配，没有已发布的 IP 范围，没有反向 DNS 后缀。剩下的只有行为信号，而在无头但真实的浏览器上，行为信号是微弱的。

这是当前工具集的诚实边界，也是 Web Bot Auth 重要的原因：它是唯一能让代理浏览器 自愿 提供可验证身份，而不是要求你推断身份的提案。

实施检查

在 Node 中实现反向 DNS 配合正向确认，无需依赖：

import { promises as dns } from "node:dns";

// 运营商为其爬虫发布的后缀。切勿推断这些——
// 使用运营商记录的域名，否则你将验证一个冒名顶替者。
const SUFFIXES = {
  googlebot: [".googlebot.com", ".google.com"],
  bingbot:   [".search.msn.com"],
  applebot:  [".applebot.apple.com"],
  amazonbot: [".crawl.amazonbot.amazon"],
  ccbot:     [".crawl.commoncrawl.org"],
};

export async function verifyByReverseDns(ip, operator) {
  const suffixes = SUFFIXES[operator];
  if (!suffixes) return { verified: false, reason: "no published suffix" };

  let hostnames;
  try {
    hostnames = await dns.reverse(ip);            // PTR lookup
  } catch {
    return { verified: false, reason: "no PTR record" };
  }

  const host = hostnames.find((h) => suffixes.some((s) => h.endsWith(s)));
  if (!host) return { verified: false, reason: "PTR outside published domain" };

  // Forward-confirm: the PTR record alone is controlled by whoever owns the
  // reverse zone, so resolve the hostname back and require the IP to match.
  const forward = await dns.resolve(host).catch(() => []);
  return forward.includes(ip)
    ? { verified: true, host }
    : { verified: false, reason: "forward lookup did not match" };
}

Enter fullscreen mode Exit fullscreen mode

在生产环境中需要做对的两件事。 带外 执行此操作——请求路径中的 DNS 往返会带来延迟和拒绝服务风险，因此异步验证并按 IP 缓存结果。以及 在策略上关闭失败，而不是在请求上关闭失败：未验证的请求不一定是恶意的，它只是未经证实，因此降低其特权，而不是向可能真实的用户返回 403。

为什么“未知”比自信的猜测是更好的答案

大多数已发布的 AI 爬虫列表都为每个机器人提供 robots.txt 合规性的明确是/否。在编译这些数据时，这种整洁性被证明是最站不住脚的部分。

对于相当数量的爬虫，运营商根本从未发布过关于该确切名称代理的明确声明。可用的选项包括从同级机器人推断、复制其他列表的断言，或记录“未知”并引用运营商实际说过的话。只有第三种选项在有人核实时才能存活。

因此，本文背后的注册表采用三态——是、否、未知——每个单独的声明都附有主要来源 URL 和 last_verified 日期，以及在无法获取来源的字段上的显式空值，而不是看起来合理的猜测。它不那么整洁。这是唯一能在运营商悄无声息地更改其文档时保持真实的版本。

如果你想要每个爬虫的数据——用户代理令牌、robots.txt 令牌、验证方法、已发布的 IP 范围 URL、退出机制以及每个字段背后的来源 URL——它位于 agentswelcome.dev/crawlers，并且有一个 JSON 端点在 /api/crawlers，如果你更喜欢 diff 而不是阅读。

常见问题

在 robots.txt 中阻止 AI 爬虫真的能阻止它们吗？
技术上不能。robots.txt 是建议性的：RFC 9309 定义了语法和期望，而不是强制执行机制。OpenAI、Anthropic 和 Perplexity 各自发布了文档，声明其爬虫会遵守它，并且有证据表明主要运营商确实遵守了。如果需要强制执行，那是 WAF 规则或边缘的已验证机器人策略——而不是一个文本文件。

Google-Extended 是我应该阻止的爬虫吗？
Google-Extended 不是爬虫，也没有用户代理字符串。它是一个 robots.txt 令牌，用于控制 Google 已经获取的内容是否可用于 Gemini 训练。禁止它不会减少爬取流量，也不会影响搜索索引。Applebot-Extended 对 Apple 的工作方式相同。

我应该阻止训练爬虫但允许搜索爬虫吗？
这是常见的策略，推理也成立：训练爬虫消耗你的内容而没有引荐路径返回，而搜索索引或用户触发的获取器可以在人类正在阅读的答案中展示你。按机器人类型而不是按公司决定——几个运营商在不同的令牌下同时运行这两种类型。

这些数据多久变化一次？
频繁到足以产生影响。运营商会添加令牌、重命名代理并更新 IP 范围而不事先通知。任何没有每个声明的来源 URL 和验证日期的爬虫列表，都是某个人某个下午的快照，包括这个——这就是为什么上面的数字带有它们被检查的日期：2026-07-30。

数据来自 AGENTS WELCOME 爬虫注册表 —— 41 个爬虫，每个字段都带有其主要来源和验证日期。检查日期：2026-07-30。