如何按 IP 验证 AI 爬虫与代理：反向 DNS、CIDR 段与 Web Bot Auth

您在日志中看到 GPTBot、ClaudeBot 或 PerplexityBot，就得做出决定：放行、限流还是封锁。但在此之前，您必须先回答一个更基本的问题：它真的是那个 bot 吗？ 因为 User-Agent 头只是声明，而不是证明。任何人都可以运行 curl -A "GPTBot/1.3" https://your-site.com，您的日志就会忠实地记下“GPTBot”。

这并非纯属理论。HUMAN Security 的 Satori 团队发现，在声称是知名 AI 爬虫的全部流量中，有 5.7% 是伪造的，某些日子甚至高达 7.7%（约每天 200 万个请求），其中 ChatGPT-User 代理被冒充的比例约为每六个请求中就有一个。本指南介绍在 IP 层和密码学层验证爬虫的三种真正可行的方法（正向确认的反向 DNS、运营方公布的 CIDR 允许列表，以及 Web Bot Auth），并说明几乎所有其他指南都会踩到的失效模式。

为什么 User-Agent 写着“GPTBot”什么也证明不了

User-Agent 是自行申报的元数据。其中没有认证，没有签名，源站没有任何可以检查的东西。验证爬虫，意味着把请求与运营方真正掌控的基础设施或密钥联系起来。能做到这一点的机制恰好有三种：

1. 正向确认的反向 DNS（FCrDNS）： 证明该 IP 与运营方的域名之间可以双向解析。
2. 已公布的 CIDR 允许列表： 将 IP 与运营方公布的 IP 段比对。
3. Web Bot Auth（RFC 9421）： 验证请求本身携带的密码学签名。

下文都是关于如何正确地做这些事，以及了解每一种能证明什么、不能证明什么。

2026 年的利害：bot 已占网络的大多数

当自动化流量成为互联网的主体时，爬虫验证就不再是 SEO 领域的小众话题。Imperva 的2026 年恶意 Bot 报告发现，自动化流量占其 2025 年观测到的网络流量的 53%，仅恶意 bot 就占 40%。当大多数请求都是自动化的、AI 爬虫的流量又在持续增长时，“这个 bot 是真的吗？”就成了登录、注册和结账端点上的问题，而不仅仅是 robots.txt 的问题。在结账环节，这现在也是欺诈问题：参见如何在不误拦真实代理交易的前提下阻止 AI 购物代理欺诈。至于哪种 IP 信号能回答哪类 bot 问题（从爬虫 IP 段到扫描器标记），请参阅我们的按 IP 检测 bot总览。

方法 1：正确实施正向确认的反向 DNS

FCrDNS 是 Google 为验证 Googlebot 而记录的标准方法。共四步：

为什么正向这一步至关重要： 攻击者可以控制自己 IP 的反向（PTR）记录，因此可以让 1.2.3.4 指向 crawl-fake.googlebot.com。但他们无法伪造 googlebot.com 权威的正向 DNS，使该主机名解析回 1.2.3.4。只对 PTR 记录做“googlebot.com”字符串匹配的检查（数量惊人的教程都这么建议）本身就可以被伪造。正向确认才是关键所在。关于 Google 的情况，包括它的三种爬虫类型及各自独立的 IP 段文件，请参阅我们的按 IP 验证 Googlebot 并识别伪造 Googlebot指南。

需要指出的精度上限：PTR 记录是可选的，经常缺失，对较新的 AI 厂商尤其如此。没有 PTR 时，FCrDNS 返回的是“无法验证”，既不是通过也不是失败。 这时就需要方法 2。

方法 2：按 bot 区分的已公布 CIDR 允许列表

大多数 AI 厂商跳过 PTR 记录，转而以 JSON 形式公布其爬虫 IP 段。这是操作上最实用的检查。请拉取每个运营方的一手数据源：

• OpenAI： 按 bot 区分的文件：openai.com/gptbot.json、openai.com/searchbot.json、openai.com/chatgpt-user.json（OpenAI 爬虫文档）。
• Google： developers.google.com/static/crawling/ipranges/ 下的五个 CIDR 文件。
• Anthropic： 为其 bot 公布一个文件，claude.com/crawling/bots.json，链接自其爬虫帮助页面。其平台文档中的地址列表是供 API 使用的，不是爬虫的。
• Perplexity： perplexitybot.json 和 perplexity-user.json。
• Apple iCloud Private Relay： 位于 mask-api.icloud.com/egress-ip-ranges.csv 的出口 CSV（Apple 文档）。注意：这些是使用隐私中继的真人，而不是 bot。请将它们加入允许列表，不要封锁。

我们加载了来自 10 个运营方的 19 个爬虫 IP 段文件；经过验证的爬虫 IP 列表逐一列出了它们，注明了日期，并说明了如何构建允许列表。

区分正确实现与错误实现的三条规则：

• 将每个 bot 匹配到其运营方的文件，并且只有在运营方为每个 bot 单独发布文件时才匹配到它自己的文件。 GPTBot 对应的是 gptbot.json，而不是“某个 OpenAI IP 段”，匹配错误的 OpenAI 文件会把训练爬虫与用户发起的抓取器混为一谈。Anthropic 为其三个 bot 发布一个共用文件，DuckDuckGo 的两个文件也完全相同，所以在这些情况下，运营方就是最精确的匹配。我们对 GPTBot、OAI-SearchBot 与 ChatGPT-User 的对比，说明了每个 OpenAI bot 的作用、封锁它的代价，以及对每个文件的真实查询。
• 匹配已公布的精确前缀，绝不要匹配托管 ASN。 因为某个 bot 恰好运行在 AWS 或 Google Cloud 上，就把“整个 AWS”或“整个 Google Cloud”加入允许列表，会放过同一朵云上的所有攻击者。
• 按计划刷新。 这些 IP 段会变化；请把它们当作数据源，而不是常量。

厂商差异：究竟有哪些方法可用

大多数指南把各厂商混为一谈。它们的差别既体现在存在哪种验证方法上，也体现在各自发布的爬虫标识上，这些标识带来不同的策略含义：

会让简单流水线失效的细节是：由用户发起的抓取器表现得像真实访问者，合法地来自已公布 bot IP 段之外也是可能的。 当用户让助手打开某个特定 URL 时，该抓取可能来自通用云基础设施，并带有普通浏览器的 User-Agent。因此，封锁“不在 GPTBot IP 段内”的请求，可能会封锁真实用户的代理操作。限流和封锁策略必须按标识区分，而不是按厂商区分。

验证 SEO 与分析爬虫：AhrefsBot 及同类

同样的两种 IP 层方法，也适用于验证人们在日志中最常想确认的 SEO 与分析爬虫：AhrefsBot，以及 SemrushBot、DataForSeoBot 等同类。它们不是 AI 爬虫，但验证方式完全相同：

• AhrefsBot 可通过正向确认的反向 DNS 验证（其地址会解析到 Ahrefs 自己域名下的主机名），并且 Ahrefs 公布了其爬虫 IP 段以供加入允许列表。请运行方法 1 中的同一 FCrDNS 检查，或按方法 2 与已公布的列表比对。
• 陷阱与 AI 爬虫面临的相同：不要按 ASN 加入允许列表。 来自某个您从未验证过的随机托管 IP 段的“AhrefsBot”，恰恰就是伪造的模式，因为任何人都可以发送 User-Agent: AhrefsBot/7.0。请确认 IP，而不是字符串。

如果您搜索“AhrefsBot IP 地址”是为了构建防火墙规则，那么可持久的做法是：正向确认的反向 DNS 检查，加上运营方公布的 IP 段，并按计划刷新，而不是硬编码的 IP 列表，因为爬虫一旦扩容它就过时了。

方法 3：Web Bot Auth 与密码学验证

解决伪造的结构性办法，是不再信任网络位置，转而验证签名。Web Bot Auth 让代理使用 RFC 9421 HTTP 消息签名（2024 年 2 月的拟议标准），以 Ed25519 密钥对每个请求签名。请求携带：

• Signature：签名值
• Signature-Input：被覆盖的组件、created/expires、keyid 以及 tag="web-bot-auth"
• Signature-Agent：可选，指明签名的代理

密钥以 JWKS 的形式在 /.well-known/http-message-signatures-directory 被发现（基于 RFC 8615 的 well-known URI 机制）。验证过程：获取目录，匹配 keyid 指纹，验证签名以及 created/expires 时间窗口。相比 IP 方法，它的优势是决定性的：它在共享、轮换和 CGNAT 地址上依然有效，因为身份附着在请求上，而不是路由上。

现实检验：它是实验性的，不是标准

在架构上请对此保持诚实。Web Bot Auth 由 IETF 互联网草案规定（draft-meunier-web-bot-auth-architecture，2026 年 3 月 2 日，作者来自 Cloudflare 和 Google），这些草案带有“未获 IETF 认可，没有正式地位”的声明，并将于 2026 年 9 月 3 日到期。Google 自己的支持也明确是实验性的。它“尚未对每个请求签名”，并告诉运营方继续使用 IP、反向 DNS 和 User-Agent 验证。在基础设施层面它已走得更远：Cloudflare 将消息签名纳入其已验证 Bot 计划（2025 年 7 月），AWS WAF 也增加了支持（2025 年 11 月）。结论：有签名时优先采用，但暂时不要依赖它。

分层决策流水线（可直接照搬）

把三种方法组合成一个优先级顺序，然后补充信息并分类。一旦 bot 通过验证，请按该指南中的三层策略决定如何处理每个经过验证的 AI 爬虫：

第 5 步正是 GeoIPHub 的用武之地：当自称是 bot 的 IP 不在已公布的 IP 段内且没有 PTR 时，ASN 所有者、数据中心/托管标记、VPN、代理和 Tor 标记，以及风险评分，能让您在登录、注册和结账时对无法判定的情形评分，而不是靠猜。如果您对“已声明但未验证”这一档限流，请对 IPv6 来源按前缀而不是按地址设键；我们关于按 /64 前缀对 IPv6 限流和封锁的指南解释了原因。

同一个 Google ASN，一个是经过验证的 Googlebot，一个不是

同一个 Google 网络中的两个地址得到了相反的爬虫结论，因为检查依据的是已公布的前缀，而不是 ASN。我们在 2026-10-05 查询了两个 Google IP（结果会随 IP 段变动而变化）：192.178.4.0，即 Google 已公布的 Googlebot IP 段文件中第一个 IPv4 前缀的首个地址；以及 8.8.8.8，即 Google Public DNS。

两者都位于 AS15169，也都是托管，所以按 ASN 的允许列表会把它们同等对待。只有第一个在 Googlebot 文件之内，而 threat.crawler.verification_method: "ip_range_list" 表明结论来自方法 2。verified_crawler 信号把它的 fraud_score 拉到 0，而 8.8.8.8 保持普通的数据中心分数 15。no_ptr_datacenter 方法对两者都触发，因为我们的记录里没有它们的 PTR，但实时执行 dig -x 192.178.4.0 会返回 crawl-192-178-4-0.googlebot.com。这是一个微小而真实的例子，说明了为什么应当把 IP 段检查自动化：它不依赖 PTR 查询成功。

失效模式与误报

这是那些排名靠前的文章讲错的地方：

• 不在段内 ≠ 伪造。 Perplexity 案例（Cloudflare，2025 年 8 月）显示，一个爬虫使用通用的 Chrome UA、在其已公布 IP 段之外的 IP，并轮换 ASN，每天发出 300 万到 600 万个请求。在段内是真阳性；不在段内则是无法判定，不能证明是伪造。
• CGNAT 的地域偏见。 Cloudflare 在 2025 年底的研究（经 The Register 报道）发现，尽管 bot 信号更低，CGNAT IP 被限流的频率仍高出约 3 倍。成百上千名用户共享一个 IPv4，且集中在非洲和亚洲。简单的 IP 封锁是一个公平性问题。
• iCloud Private Relay。 共享、轮换的出口 IP 承载着真实的人；请通过 Apple 的 CSV 将其加入允许列表。
• 住宅代理。 它们完全击败了 ASN 允许列表（Imperva 的 2025 年报告发现 21% 的 bot 攻击使用了它们），这恰恰是为什么检测匿名化流量而不误拦真实客户是行为问题，而不是列表查询。

规则是：硬性封锁应留给行为加来源，绝不能仅因为不在列表中就封锁。

经过验证的 bot 属于 GIVT，伪造的属于 SIVT

在媒体评级委员会（MRC）的分类中，已声明身份的爬虫和已知的数据中心 IP 属于一般无效流量（GIVT），可以通过列表过滤；而“伪装成合法用户”的 bot 属于复杂无效流量（SIVT），需要分析和审核。按 IP 验证爬虫，正是把请求从第二类转入第一类的方式。完整的类别列表、Google 自己的九个类别，以及其中哪些可以被 IP 查询看到，见 GIVT 与 SIVT：Google 的无效流量类别。

使用 GeoIPHub 验证 AI 爬虫与代理

GeoIPHub 提供第 5 步的补充信息，这是传统 geo-IP 厂商的操作指南所缺少的：ASN 与连接类型、托管/数据中心检测、VPN / 代理 / Tor 标记、来自 19 个官方 IP 段数据源的已验证爬虫标记（包括 GPTBot、ClaudeBot、PerplexityBot 和 AhrefsBot），以及 IP 欺诈风险评分。我们不检测住宅代理；那需要行为信号。这样您就可以确认自称是 bot 的请求确实来自厂商的基础设施，并对无法判定的情形评分，而不是粗暴封锁。请将它与上述验证方法，以及关于账户接管与撞库检测和IP 地理定位究竟有多准确的相关指南结合使用。

常见问题

如何验证某个请求确实来自 GPTBot 而不是伪造的？

不要相信 User-Agent 头，它极易伪造。请将来源 IP 与 OpenAI 公布的按 bot 区分的 IP 段文件（openai.com/gptbot.json）比对，把检查明确限定为 GPTBot，而不是通用的 OpenAI IP 段。如果存在有效的 Web Bot Auth 签名，请先对照 OpenAI 的密钥目录验证，因为这与 IP 无关。对于不在已公布 IP 段内的 IP，应视为无法判定，而不是已证实为伪造，因为由用户发起的代理流量可能来自其他基础设施。我们的 GPTBot、OAI-SearchBot 与 ChatGPT-User 对比展示了对每个 OpenAI IP 段文件的真实查询。

什么是正向确认的反向 DNS（FCrDNS）？

FCrDNS 是一个四步检查：把来源 IP 反向解析为主机名，确认该主机名以运营方的域名结尾，再对该主机名做正向 DNS 解析，最后确认它解析回原始 IP。正向这一步才能挫败伪造：攻击者可以在自己的 IP 上设置伪造的 PTR 记录，却无法伪造运营方权威的正向 DNS。只检查 PTR 字符串的检查是可以被伪造的。

为什么不能仅凭 User-Agent 字符串封锁 AI 爬虫？

因为 User-Agent 是任何人都能发送的声明。HUMAN Security 发现，被标记为知名 AI 爬虫的流量中有 5.7% 是伪造的，ChatGPT-User 代理的伪造比例在峰值时接近每六个请求中就有一个。仅凭请求头封锁，会放过伪造的 bot，却对不再声明身份的运营方毫无办法。

什么是 Web Bot Auth？它是已完成的标准吗？

Web Bot Auth 是一种新兴方法：bot 使用 RFC 9421 HTTP 消息签名，以 Ed25519 密钥对每个 HTTP 请求进行加密签名，源站则对照发布在 /.well-known/http-message-signatures-directory 的密钥进行验证。RFC 9421 本身是拟议标准（2024 年 2 月），但 Web Bot Auth 仍是 IETF 互联网草案，截至 2026 年年中没有正式地位。请将其视为实验性方案：有签名时就验证，但仍以 IP 和反向 DNS 验证作为基线。

AI 厂商在哪里公布其爬虫 IP 段？

OpenAI 在 openai.com/gptbot.json、searchbot.json 和 chatgpt-user.json 公布按 bot 区分的 JSON；Google 在 developers.google.com/static/crawling/ipranges/ 下公布 CIDR JSON；Anthropic 在 claude.com/crawling/bots.json 为其 bot 公布一个文件；Perplexity 公布 perplexitybot.json 和 perplexity-user.json。请把每项检查限定到具体 bot 的文件，匹配已公布的精确前缀而不是托管 ASN，并按计划刷新这些文件。关于三个 OpenAI 文件及其当前前缀数量，请参阅 GPTBot、OAI-SearchBot 和 ChatGPT-User 的 IP 段。

如果某个 IP 不在厂商公布的 IP 段内，是否意味着请求是伪造的？

不是。IP 在段内、FCrDNS 通过或签名有效，都是高置信度的真阳性，但 IP 不在段内只是无法判定。它可能是来自其他基础设施的合法的、由用户发起的代理流量，也可能是 CGNAT 共享地址、iCloud Private Relay 出口、未发布 PTR 记录的厂商，或者是您这边过期的 IP 段文件。硬性封锁应留给行为和来源信号，而不能仅因为不在某个列表中就封锁。

封锁爬虫 IP 段会不会影响共享地址上的真实用户？

会，所以不应因为 IP 不在列表中就触发硬性封锁。Cloudflare 在 2025 年底的研究发现，尽管 bot 迹象更低，CGNAT 地址被限流的频率仍约为非 CGNAT 地址的三倍，原因是成百上千名用户共享同一个 IPv4 地址，而 CGNAT 集中在非洲和亚洲的部分地区，由此造成地域偏见。iCloud Private Relay 的出口 IP 同样承载着真实的人，应使用 Apple 公布的 CSV 加入允许列表。