googlebot ip 怎么验：日志里那串 UA 是可以照抄的

找 googlebot ip 的人，八成是想要一份能贴进防火墙的名单。名单确实有，但它只是两条路里的一条，而且不是更准的那条。更准的做法是两次 DNS 查询：拿日志里的 IP 反查主机名，确认域名落在 googlebot.com、google.com 或 googleusercontent.com，再把那个主机名正查回来，看是不是同一个 IP。请求头里的 UA 不算证据。名字可以照抄。

先确认你有日志

这一章要用的东西只有一样：一份记录了客户端 IP 的日志。服务器访问日志、CDN 日志、边缘函数日志都行。Search Console 里的抓取统计不行 —— 它只显示 Google 已经认定是自己的那部分请求，你怀疑的那些请求从定义上就不在里面。托管平台完全不给日志的，这一章你做不了，先去问清楚 CDN 能不能开日志，比做别的都值。

UA 为什么不算证据

UA 是客户端自己填的一段文本。把 Googlebot 那串字符原样抄过去只要一行代码，采集程序天天这么干，就是为了绕过按名字放行的规则。所以只看名字的白名单，拦住的恰好是老实报名的那批，抄名字的那批照进不误。

抄不走的是连接本身。要收到你的响应，对方必须用一个自己真正控制的地址完成 TCP 握手，而这个地址要么在爬虫运营方的网段里，要么不在。下面两条路，问的都是这一个问题。

UA 是一句自称，IP 是这句自称必须兑现的那部分。

两次 DNS 查询：不用 googlebot ip 名单也能验

Google 文档给的是一个两步法，对 Googlebot、AdsBot、Google Site Verifier 都一样：反查地址读主机名，比对域名，再拿主机名正查回来。任何一步对不上，这个请求就不是 Google 发的。

1. 对日志里的地址执行 host <ip>，读它返回的主机名。
2. 看主机名的域名。Google 文档（2026-08-23 读）写死了只认三个：googlebot.com、google.com、googleusercontent.com。
3. 对第 1 步得到的主机名执行 host <主机名>，确认返回的地址和你手上那个一致。

# 这是 Google 文档里自带的例子，不是我们跑出来的
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

第 3 步是最容易被省掉的一步，省掉它整件事就白做了。反查记录由地址段的持有者自己设置，对方完全可以把自己的反查记录指向一个看起来很像 Google 的主机名。但他没法让 Google 的正向 DNS 把那个主机名解析回他的地址 —— 正查这一半不在他手里。

主机名的形态还顺带告诉你这是 Google 的哪一部分。常规爬虫解析成 crawl-*.googlebot.com 或 geo-crawl-*.geo.googlebot.com；特例抓取器是 rate-limited-proxy-*.google.com；用户触发的抓取是 *.gae.googleusercontent.com 或 google-proxy-*.google.com。这三类对 robots.txt 的态度并不一样，所以主机名值得读一眼，别只做模式匹配。

还有一件成本上的事要先说。别对每一条日志都做一次 DNS 查询 —— 一天几十万行日志按行查，DNS 那头先被你自己打挂。正确的顺序是先按 IP 去重，再对去重后的地址查，把结果缓存起来复用。一个爬虫在一天里反复用同几个地址，所以去重能省掉多少，取决于你的日志长什么样，自己数一遍就知道。缓存也别设成永久：地址段会变，隔一段时间重新验一次，周期照你的日志量定。

手上没有 host 命令怎么办

Linux 服务器上 host 通常在 bind-utils 或 dnsutils 包里，精简镜像和容器里经常没装。三个替代品的输出都能用来做同样的两步比对。

交付物：九份官方 IP 清单

不给反查规则的爬虫，只剩下比对官方 IP 清单这一条路。目前有五家发了机器可读的文件。下面每一行都是 2026-08-23 当天逐个拉下来解析的，时间列是文件里的 creationTime 字段，不是我们下载的日期。

九份文件结构完全一样：一个 creationTime 字符串加一个装 CIDR 段的 prefixes 数组。所以一个脚本能读全部。存下来，喂给它一个日志里的地址，它一行就答完。

#!/usr/bin/env bash
# 用法：./whois-bot.sh 66.249.66.1
IP="$1"
for URL in \
  https://developers.google.com/static/crawling/ipranges/common-crawlers.json \
  https://openai.com/gptbot.json \
  https://openai.com/searchbot.json \
  https://openai.com/chatgpt-user.json \
  https://claude.com/crawling/bots.json \
  https://www.bing.com/toolbox/bingbot.json \
  https://www.perplexity.ai/perplexitybot.json
do
  curl -s "$URL" | python3 -c '
import ipaddress, json, sys
ip = ipaddress.ip_address(sys.argv[1])
for p in json.load(sys.stdin)["prefixes"]:
    net = p.get("ipv4Prefix") or p.get("ipv6Prefix")
    if net and ip in ipaddress.ip_network(net):
        print("MATCH", sys.argv[2], net)
' "$IP" "$URL"
done

这张表里有两处要当回事。Bingbot 那份文件的时间戳是 2024-01-03，比其余八份都旧两年以上，所以一个地址没匹配上它，不代表就是假的。另一处是 Anthropic 自己的帮助页（页面标注 2026-04-07）写着，按 IP 屏蔽「may not work correctly or persistently guarantee an opt-out」—— 那份清单是给你认人用的，真要拒绝它得改 robots.txt。这些文件回答的是「刚才那个是谁」，不是拿来当防火墙策略的。

三种常见做法是错的

下面三种把这套检查做废的方式，问题都不在 DNS 那一步，而在于图省事。

• 验名字不验地址。规则读完 UA 就结束，等于只筛掉了老实报名的那一批。
• 反查完就下结论。反查记录归地址持有者设置，不做正查等于什么都没验。
• 匹配不上就直接封。没匹配上可能是运营方今天早上加了机器，也可能是那份文件从 2024 年就没再生成过。先记下来，看它干了什么，再决定。

在这上面搭任何规则之前，先想清楚你本来打算放行哪几个爬虫 —— 那是 该放行哪些 AI 爬虫 那一章的事，顺序在前。只想知道正经爬虫此刻能不能读到你的页面，走 AI 爬虫可达性检查 最快。

这套检查答不了的事

它只认人。它不告诉你对方拿页面干了什么，任何校验步骤都做不到这件事。而且同一家公司会跑好几个爬虫，职能不同、挡错了代价也不同，所以一个地址验过了也只答了一半 —— 写「按公司放行」的规则之前，先看 GPTBot 和 OAI-SearchBot 的区别。

还有一个从日志里补不上的缺口。只有 Google 文档了反查主机名的规则，其余几家给的只有 IP 清单；运营方加机器的速度要是快过重新生成文件，真请求也会验不过。这种情况多久发生一次，我们不知道 —— 没有一家公布再生成周期，而且验不过在日志里长得都一样。

常见问题

没有服务器日志能查 googlebot ip 吗

不能。所有方法都要客户端 IP，而它只存在于日志或边缘规则里。Search Console 的抓取统计替代不了：它显示的是 Google 已经确认过的自家流量，你怀疑的那些请求恰好不在里面。

比对 IP 清单和 DNS 两步法哪个准

Google 这边 DNS 更准，因为它是实时解析出来的，不依赖一份要人重新生成的文件。OpenAI、Anthropic、Bing、Perplexity 只给了清单，那就只能用清单。

验不过的请求该怎么处理

当成来路不明的流量看，别当成攻击。先看它请求了什么、多快。一个假 Googlebot 读三个页面是噪音；一分钟一千次是限流问题，正确的处理是限流，不是按名字封 —— 同一个客户端换个名字就绕过去了。

AI 爬虫有没有 Googlebot 那样的反查记录

它们的文档没承诺。OpenAI 的爬虫文档让你按它公布的 IP 段放行，Anthropic 的帮助页指向它自己那份清单。我们只核了这些页面怎么写，没有去逐个解析各家的实际地址。