AI 爬虫的请求开始带加密签名，放行名单能不能不只看 UA

AI 爬虫的请求开始带加密签名，放行名单能不能不只看 UA？可以不停在 UA 上。签名机制解决的是「这个请求能不能被证明来自它所声称的那一方」，UA 解决的是「请求自己怎么描述身份」。前者可核验，后者可随手改，把它们写进同一列判断，放行名单就会失真。

签名验证解决的是哪一步

按 Cloudflare 关于 Web Bot Auth 的公开文档，这套机制的用途是以密码学 HTTP 消息签名验证机器人身份，并作为已验证机器人与智能体的验证方式之一。请求侧要附带三个首部：一个说明签名由哪个主体的密钥产生，一个说明签名覆盖了请求的哪些部分，一个承载签名本身。服务端用自己的方式去验算这三段是否自洽。

关键差别在于「谁来断言」。UA 由请求方断言，服务端只能选择信或不信；签名由密钥体系断言，验算结果是可以复现的。文档里还专门列了一条「忘掉 IP，用密码学验证机器人与智能体流量」的入口，说明这一层要替代的正是过去靠地址段和字符串匹配的做法。

三个首部分别承担什么角色

三项要一起看，缺一项就只能退回旧判断。工程上还有一处容易被忽略：签名覆盖的是请求的某几个字段，不覆盖响应内容，也不代表抓取行为符合站点的授权意图。它能证明「来自谁」，不能证明「拿来做什么」。

UA 仍然有用，但不能只靠它

UA 的合理用途是分类和统计：判断是搜索类还是模型类抓取、估算抓取节奏、给日志分组。它不适合做放行依据，因为改动成本为零。同类问题也出现在地址段上——网段可以被借用，也可能因为服务方调整而失效。

一个可用的组合判断顺序是：先按签名验算结果确定身份，再用 UA 与地址段做二次核对，两者不一致时按更保守的一侧处理。只写 UA 白名单的放行名单，等于把决定权交给请求方。

放行名单该写在哪一层

写在离入口最近的一层最省事，但要看清代价：

• 网关或加速层：规则集中、执行早，抓到的内容不会进程序，但站内的访问统计会看不到这一段流量，需要靠上游日志对账；
• 程序侧：能结合登录态、内容状态与业务规则做判断，但要先承担解析请求的成本；
• 文件与标记层：Robots.txt 与排除规则属于「表达授权意图」，不具备强制力，抓取方可以不遵守。

站内这块有明确分工：Robots.txt 是后台可配置的一项，用来表达允许与排除；llms.txt 由系统自动生成，给大模型一份站点说明；防采集干扰码则作用在内容层，保护正文不被批量拿走。这三件事都不等于「按签名放行」，签名判断应当落在网关或程序层的访问控制里，别指望由排除文件承担。

排除规则、模型说明文件与防采集的分工

表达意图、提供清单、限制滥用，是三件事。Robots 类规则负责表达；模型说明文件负责把内容结构化地交出去，减少对方靠猜测抓取；干扰码负责让批量搬运的成本高于价值。签名验证补在前面那一格：决定「谁有资格读到」。

如果站点的目标是既被搜索收录又不被无差别搬运，比较稳的排布是：允许清单按可核验身份放行，其余按授权意图处理，正文对已放行的抓取方也不再叠加干扰码——同一份内容对合法抓取方加噪，会让统计与排障都难以对齐。

常见问题

问：接入签名以后是不是可以删掉 UA 判断？ 答：不建议。UA 与地址段作为辅助核对仍有价值，只是不能单独作为放行依据。

问：抓取方没带签名，是不是就该拦？ 答：按业务决定。签名缺失只意味着无法核验身份，不等于恶意；把它当作降级到保守策略的条件，比当作拦截条件更实际。

问：这套机制能防止内容被抓去训练吗？ 答：不能。它证明请求来自谁，不约束对方拿到内容之后的用途，用途仍要靠授权表达与商务条款解决。