Google Web Bot Auth 实验性验证指南

💡 核心摘要：Web Bot Auth 是一种仍在实验阶段的机器人身份验证协议。它让自动化客户端用私钥签名 HTTP 请求，网站再用公开密钥验证请求是否来自声明的主体。Google 当前只在部分托管于 Google 基础设施上的 AI agent 中测试该机制，因此站点仍应继续使用 IP 地址、反向 DNS 和 user-agent 等现有验证方式。

一、Web Bot Auth 解决什么问题

传统机器人识别主要依赖 user-agent、IP 地址和反向 DNS。它们能解决很多 Googlebot 验证场景，但也有明显短板：user-agent 很容易伪造，IP 段需要维护，DNS 验证在高流量日志场景下会增加工程复杂度。

Web Bot Auth 的目标是给自动化请求增加一层加密证明。请求方不只是“声称自己是谁”，还要用私钥对请求签名；接收方通过公开密钥验证签名，从而判断请求是否真的来自对应的代理服务。

💡 可以把 Web Bot Auth 理解成“机器人请求的签名身份证”，但当前它还不是所有 Google 抓取请求的默认身份机制。

二、它不是 Googlebot 验证的替代品

Google 文档把 Web Bot Auth 标为实验性能力。这个状态有两个直接含义：第一，不是所有 Google user-agent 都在使用 Web Bot Auth；第二，即使某些代理支持该协议，也不代表它的每一次请求都会被签名。

因此，站点不能因为某个请求没有 Web Bot Auth 签名，就直接判定它不是 Google；也不能因为看到签名相关请求头，就跳过现有验证。当前更稳妥的策略是把 Web Bot Auth 当作额外信号，而不是唯一判断依据。

推荐判断模型

基础验证：user-agent + IP 地址 + 反向 DNS
增强验证：Web Bot Auth 签名
最终策略：结合请求来源、路径、频率、状态码和业务风险

⚠️ 对 Googlebot 搜索抓取流量，仍应优先使用官方 IP 段、反向 DNS 和 user-agent 验证流程。

三、协议核心：用 HTTP Message Signatures 签名

Web Bot Auth 建立在 HTTP Message Signatures（RFC 9421）之上。自动化客户端会持有一个私钥，并把对应的公开密钥发布到可发现的位置。当它访问网站时，会在请求中附带签名相关 HTTP 标头。

网站收到请求后，可以根据请求头找到密钥目录，获取公开密钥，并验证该请求是否由对应私钥签名。只要私钥没有泄露，攻击者即使伪造 user-agent，也无法伪造有效签名。

简化流程

代理服务生成密钥对
公开密钥发布到可信域名
代理请求网站时使用私钥签名
请求携带签名相关 HTTP 标头
网站获取公开密钥并验证签名
验证通过后再进入放行、限速或分类逻辑

💡 Web Bot Auth 的价值在于把“自我声明”变成“可验证证明”。

四、Google 当前测试的身份

Google 当前在部分托管于 Google 基础设施上的 AI agent 中测试 Web Bot Auth。签名请求会指向 Google 提供的代理身份，站点可以围绕这个身份获取公开密钥并验证请求。

从工程视角看，你需要关注三个信息：请求是否包含 Signature-Agent，它指向的身份是否为 Google 认可的身份，Signature 与 Signature-Input 是否能用对应公开密钥验证通过。

请求头关注点

Signature-Agent: g="https://agent.bot.goog"
Signature-Input: ...
Signature: ...

⚠️ 这些请求头只说明请求声称可被签名验证。真正可信的判断来自签名校验结果，而不是单独看到某个 header。

五、网站应该如何接入验证

如果你的 CDN、WAF 或边缘网关已经支持 Web Bot Auth，优先让基础设施层完成验证，并把结果写入请求上下文或日志字段。这样应用层可以直接根据可信字段做限速、放行、统计和审计。

如果需要自己实现，应选择成熟的 HTTP Message Signatures 验证库，而不是手写加密校验。自研实现最容易出错的地方包括签名输入规范化、header 解析、时间窗口、密钥缓存、密钥轮换和失败回退。

推荐日志字段

timestamp
ip
user_agent
request_path
has_signature_agent
signature_agent
web_bot_auth_verified
verification_error
fallback_google_verified
status_code
response_time_ms

💡 先把验证结果写进日志，比一开始就做强拦截更稳。观察一段时间后，再决定是否接入安全策略。

六、验证失败时不要直接误伤正常抓取

由于 Web Bot Auth 仍在逐步测试，站点应设计清晰的回退逻辑。签名缺失、签名验证失败、密钥目录暂时不可用、网络请求超时，都不应自动等同于“恶意流量”。

更可靠的做法是把 Web Bot Auth 验证失败分级处理：如果传统 Google 验证也失败，可以按普通未知机器人策略处理；如果传统验证通过但 Web Bot Auth 缺失，则继续视为已通过基础验证；如果签名存在但校验失败，可以提高风险评分并记录样本。

回退策略示例

Web Bot Auth 通过：标记为 signed_google_agent
Web Bot Auth 缺失 + 传统验证通过：标记为 verified_google_fallback
Web Bot Auth 失败 + 传统验证失败：标记为 unverified_bot
Web Bot Auth 失败 + 传统验证通过：标记为 verify_conflict 并进入审计

⚠️ 不建议在实验阶段用“没有签名”作为拒绝 Google 相关请求的唯一条件。

七、适合优先关注的团队

普通内容站短期内不需要为 Web Bot Auth 做大规模改造。你可以先保持现有 Googlebot 验证和日志分析流程，等 CDN、WAF 或托管平台提供成熟支持后再接入。

更应该提前关注的是高流量站点、电商、SaaS、内容版权站、需要区分 AI agent 与恶意抓取的站点，以及已经在边缘层做机器人管理的团队。对这些团队来说，Web Bot Auth 未来可能成为更稳定的机器人身份信号。

💡 当前阶段最务实的投入不是强制拦截，而是让日志系统能记录签名验证信号，为后续策略升级留出空间。

八、与现有 Google 请求验证一起使用

前一篇教程已经讲过 Google 请求验证的基础方法：DNS 反查、DNS 正查和官方 IP 段 JSON 比对。Web Bot Auth 应叠加在这套体系上，而不是替换它。

一个成熟的验证管道可以分成三层：第一层用 user-agent 初筛请求类型；第二层用 IP、DNS 或官方 IP 段确认 Google 来源；第三层在支持的请求上验证 Web Bot Auth 签名。这样既不会误伤未签名的正常流量，也能利用签名机制识别更可信的 AI agent 请求。

三层验证管道

Layer 1：识别 user-agent 和访问路径
Layer 2：验证 IP、反向 DNS、官方 IP 段
Layer 3：验证 Web Bot Auth 签名

⚠️ 安全策略应按风险递进。日志归类、限速、白名单、强拦截不应该共用同一套粗糙判断条件。

📌 核心收获

• ✓ Web Bot Auth 是实验性机制：它正在测试中，不覆盖所有 Google user-agent 或每一次请求。
• ✓ 签名比 user-agent 更强：请求方需要私钥签名，网站用公开密钥验证身份。
• ✓ 不能替代传统验证：IP、反向 DNS 和 user-agent 仍是当前基础验证方式。
• ✓ 先记录再拦截：建议先把签名验证结果进入日志，再逐步接入风控或 WAF 策略。
• ✓ 失败需要回退逻辑：缺少签名不等于伪造请求，验证失败也要结合传统验证和业务风险判断。

🚀 立刻行动

1. 检查 CDN、WAF 或边缘网关文档，确认是否已经支持 Web Bot Auth 或 HTTP Message Signatures 验证。
2. 在日志模型中预留 signature_agent、web_bot_auth_verified 和 verification_error 字段。
3. 继续保留 Google 请求的 IP 段、反向 DNS 和 user-agent 验证流程，不要只依赖签名。
4. 对包含 Signature-Agent 的请求建立样本集，观察来源 IP、路径、频率和传统验证结果是否一致。
5. 如果要自研验证，优先使用成熟 RFC 9421 库，并设计密钥缓存、轮换和失败回退策略。

来源：Web Bot Auth | 本文为知识提炼与重新表达