Web Bot Auth 部署实操：密码学验证爬虫身份的落地路径

Web Bot Auth 把爬虫身份从“自称是谁”升级为“密码学证明是谁”：厂商用私钥签署出站请求，站点按公钥目录验签。机制的完整概念、与 IP 反解的对照、验签缺失为何不是伪信号，已在Web Bot Auth术语卡与爬虫日志验证方法档案里立档，本卡只讲落地：标准走到哪一步了、谁在签谁能验、站点怎么部署、策略怎么定。

现势：从提案到专门工作组

标准化进程在 2026 年跨过了一个台阶：Web Bot Auth 从个人草案阶段进入了 IETF 的专门工作组（工作组代号为 webbotauth），协议、架构、注册表等草案系列在新工作组名下推进——草案命名空间随之切换，引用旧命名空间的文档与脚本应跟着更新。工作组的成立意味着这不是某家厂商的单方推动，而是进入共识流程的正式标准工作；同步的现实是它尚未成为 RFC，部署按“实验性但方向明确”定位。

落地侧三家各就各位。Google 以实验性方式签署其 AI agent 流量：身份标识为官方 agent 域，请求携带签名代理头，按 HTTP 消息签名规范验签，公钥集发布在标准发现路径下；官方同时明示并非所有请求都签名。OpenAI 的智能体类产品（ChatGPT Agent 与 Operator）的出站请求采用同一套签名体系，密钥算法为 ed25519。Cloudflare 是首发推动方，提供了开源验签实现包；DataDome、Fingerprint、Fastly 等风控与边缘厂商已支持验签。

三家现势的共同点必须放在部署决策的最前面：签名目前集中在 agent 类流量——经典爬虫的常规抓取大多还是未签名流量。这意味着“部署了 WBA”不改变站点的多数日志判定，它新开的是 agent 流量这一档的身份证据。对站长的时间含义是：这不是一项紧迫工程，而是一项提前工程——趁覆盖率还低把管道与策略搭好，等签名流量成为主流时你是现成的；反过来，指望它今天解决“日志里真伪爬虫难分”的主力问题，会失望，那个问题仍然靠三关流程兜底。

部署两条路：托管开关与自建验签

第一条路：风控厂商现成开关。如果你的边缘层在支持名单里（DataDome、Fingerprint、Fastly）或使用 Cloudflare，验签能力是产品开关——在控制台开启、把“验签通过的请求”纳入已验证流量分级，不必自建任何密码学逻辑。这是绝大多数站点的推荐路径，维护成本由厂商承担，密钥目录刷新也是厂商的事。

第二条路：自建验签。自建 CDN、裸网关或需要深度定制的站点，在反向代理层加验签中间件：拉取厂商发布的公钥目录（发现路径是约定俗成的点前缀路径，按 HTTP 消息签名规范验证签名），开源实现可引 Cloudflare 发布的程序包。自建要处理四件工程事：目录拉取要设缓存与刷新周期——目录会随密钥轮换更新，缓存过期太长会错杀新密钥、太短又白耗请求；一次请求可能携带多个签名（规范明文允许），验签逻辑要逐个尝试直到命中可信身份；算法按 ed25519 对齐，别自己扩展算法清单；验签结果要写进访问日志的标签字段，让后段策略与复盘有据可依。

两条路的共同前置是把身份判定的分层想清楚：验签通过是身份层的强信号，它回答“真出自该厂商”；授权层（放行、限速、收费）仍然按你自己的策略走——身份可信不等于默认放行。分清这两层还有一处实操价值：出问题时知道找谁。验签失败找实现（中间件、目录、时钟），策略不合意找自己（配置档位），把两层混在一个开关里排障，是自建路径最常见的低级错误。

策略矩阵：按签名状态分档

部署之后，站点面对的流量多了“签名”这个维度，处置矩阵按四档设计。签名有效且身份可信：按已验证流量处理，进入对应厂商的策略档——这是唯一可以放宽的档。签名无效或验不过：按伪装嫌疑处理，移交安全流程——能验签的站点对这一档可以比传统三关更果断。无签名：回到传统三关（UA、IP 清单、反解）处理，这是当前大多数爬虫流量的现实档位，覆盖率不足决定了三关回退必须长期保留。签名存在但对应身份不在你的信任清单：按新身份处理，先记录再决定——这档处理的是“新厂商开始签名”的未来常态。

矩阵的核心纪律一句话：验签通过可以放宽，验签缺失绝不能收紧到封锁——官方口径都明确签名不是全量，把缺失当伪造会误伤大量合法流量。这条纪律与 IP 反解时代的“反解不通过按未验证处理”是同一哲学的延续，两代方法的分工与对照见Web Bot Auth 与 IP 反解的区别；落到组织上，矩阵的每一档由谁处置（策略、安全、工程）最好在部署时就写进值班文档，别等第一起误伤发生再补。

运维项与观望清单

把 WBA 当成运维项而不是一次性配置，清单有五条：公钥目录的刷新周期进监控——目录拉取失败应当告警，而不是静默沿用旧钥；密钥轮换是厂商侧常态，站点侧的对应动作就是目录刷新，别写死任何一版密钥；日志里长期保留“签名状态”标签，观察签名流量占比的趋势——这个占比上升的速度，就是三关回退可以逐步退居二线的速度；工作组草案仍在演进，字段与流程可能微调，季度复核对一次工作组状态；付费抓取类机制（如边缘平台的按次付费通道）强制要求验签身份，想走那条路的站点把 WBA 部署当前置项，付费协议的机制细节见Pay Per Crawl术语卡与爬虫访问控制实战档案。

我们的口径：现在就部署、但不为它重构现有验证体系——托管风控站点开开关、自建站点加中间件，都控制在“新增一层身份证据”的工程量；策略上把验签当加分项而不是门槛项。等签名覆盖率成为主流、工作组产出定稿，再考虑把三关回退降级为兜底——方向明确、节奏渐进，是这项前沿实践正确的打开方式。届时回收的也不只是安全收益：签名流量占比的数据本身就是观测点，哪类用途的流量先进入“凭签说话”的时代，从这条趋势线上读得出来。