在浏览器本地通过 Web Crypto 生成 Ed25519 密钥对，输出 JWK/PEM 格式、密钥目录 JSON 和带签名的 curl 请求示例。
很多站点现在仍然通过 User-Agent 字符串或 IP 地址列表识别爬虫和 AI 代理，但这两个信号都很容易被伪造。Web Bot Auth 走的是另一条路线：机器人每次请求都使用自己持有的 Ed25519 私钥进行签名，站点从公开的密钥目录中取出对应公钥来验证。签名格式遵循 RFC 9421 HTTP Message Signatures，这为 HTTP 请求头提供了密码学完整性证明。需要强调，Web Bot Auth 目前仍是 IETF Internet-Draft，不是已经定稿的标准，不过其目录路径、签名组件和 web-bot-auth 标签已经足够明确，适合工程团队提前试验。Web Bot Auth 密钥生成器的目标，就是把草稿里的关键步骤变成一个浏览器内即可完成的起点：生成 Ed25519 密钥、输出公钥目录、给出签名示例。你不需要把私钥发到任何网站，也不需要有账号。
Web Bot Auth 密钥生成器一次会产出六类内容，分别对应部署时需要填写的不同位置。第一是 key ID，它按 RFC 8037 与 RFC 7638 的 JWK thumbprint 方法计算，由公钥 JSON 的固定字段做 SHA-256 摘要并 base64url 编码得到，后续每次签名都要用它作为 keyid。第二是密钥目录 JSON，只包含公钥，可以放进 /.well-known/http-message-signatures-directory；如果选择了有效期，里面还会带 nbf 或 exp。第三是目录响应头示例，包含一个 24小时 有效的样本签名，帮助理解目录本身也要被签名。第四是私钥，以 JWK 和 PKCS#8 PEM 两种格式给出。第五是公钥的 SPKI PEM。第六是签名后的示例请求，包含请求头和可直接复制运行的 curl 命令，并展示签名基的逐行文本。所有这些内容都在浏览器本地由 Web Crypto 生成，不会上传到远程服务器。
把生成器输出的密钥目录 JSON 发布到站点时，路径必须是 /.well-known/http-message-signatures-directory。这个路径来自 Web Bot Auth 草稿，站点验证方会固定到这里取公钥。响应需要带有草稿要求的媒体类型；目录响应本身也会带 Signature 和 Signature-Input 头，用来证明这个目录确实由私钥持有者发布。生成器给的目录响应头示例有 24小时 的有效期，但它只是参考。生产环境中你应该在每次请求到达时重新签名，避免复用已经过期的样本。如果生成密钥时选择了有效天数，目录 JSON 中会出现 nbf 或 exp 字段；可以选择不设过期，也可以按 30天、90天 或 365天 轮换。设有过期时间意味着你必须提前生成新密钥并更新目录，否则旧签名会开始被判定无效。密钥轮换时，新公钥发布前可以先短暂同时保留两个 key ID，减少验证中断。
一次 Web Bot Auth 请求的签名不是简单给某个字符串签名，而是对一段严格拼接出来的文本签名，这段文本叫 signature base。签名方会先选择要保护的 HTTP 组件，例如 @authority、请求路径、signature-agent 等。每个组件按照 RFC 9421 的规则写成一行，然后按固定顺序拼接。签名时使用的参数写进 Signature-Input 头，常见参数包括 created、expires、keyid、alg、nonce 和 tag。Web Bot Auth 草稿要求使用 tag=web-bot-auth，示例请求的 expires 设成 5分钟 后过期。生成器输出的精确签名基可以直接拿来对比你自己的签名实现，这是排查签名被拒问题最有效的方法。签名验证失败通常不是因为密钥错，而是签名基差了一个换行、一个引号或一个冒号。使用 curl 示例时，只需把私钥路径、key ID 和目标地址替换成你自己的值，不要修改签名基的拼接逻辑。
Web Bot Auth 密钥生成器最需要强调的安全特性是：私钥完全在浏览器里由 Web Crypto API 生成，页面不会把私钥发送到任何服务器。刷新页面后密钥即被丢弃，因为生成器不写入本地存储。这也意味着你需要主动下载私钥。生成结果中的 JWK 格式含 d 参数，它代表 Ed25519 私钥标量；PKCS#8 PEM 则适合直接挂到签名服务。无论选择哪种格式，都不能把 d 参数或 PEM 文件提交到公开仓库，也不要粘贴到服务端生成器。生产环境建议把私钥放进密钥管理服务，例如云厂商的 secret manager、CI 的加密变量或硬件安全模块；公钥目录可以公开，私钥只允许签名服务读取。另一个边界是浏览器兼容性：Ed25519 需要较新的 Chrome、Firefox 或 Safari。源站 origin 必须使用 https 并且不能带路径，否则生成器会拒绝。
签名告诉站点“你是谁”，但不会告诉你的机器人可以读什么。生产环境里，Web Bot Auth 密钥生成器产出的签名身份应当与访问规则配合使用。robots.txt 仍然是大多数通用爬虫首先检查的文件，你可以在其中声明哪些路径允许抓取、哪些路径禁止；面向 AI 代理的内容规则也可以单独维护。建议先使用 AI 爬虫 robots.txt 生成器 生成规则，再用 robots.txt 测试工具 验证某个路径是否会被允许。签名和 robots.txt 的关系可以理解为：签名为来源提供密码学身份，robots.txt 为抓取范围提供策略。不要用签名代替授权，也不要让 robots.txt 单独承担身份验证。一个站点可以同时要求合法机器人签名，并通过规则文件让它们只访问公开数据区。这样既能减少匿名滥用，又不会误伤愿意表明身份的爬虫和 AI 代理。
先用 Web Bot Auth 密钥生成器输入你的 HTTPS 源站和示例目标主机，生成 Ed25519 密钥对。然后把输出的密钥目录 JSON 发布到 /.well-known/http-message-signatures-directory，私钥保存在密钥管理器中。每次请求时用私钥签名，并带上 Signature 和 Signature-Input 头。生成器里的签名示例和 signature base 可以直接对照调试。
完全免费，无需注册。密钥在浏览器本地通过 Web Crypto 生成，不会上传任何内容。刷新页面后密钥会丢弃，所以生成后请立即下载 JWK 或 PEM。
key ID 是公钥的 JWK thumbprint，按 RFC 7638 对 JWK 的必需字段做 SHA-256 摘要，再 base64url 编码。它作为每个签名里的 keyid 参数，让服务器知道该用哪个公钥验签。
Web Bot Auth 草案以 Ed25519 作为示例算法，密钥小、签名快且结果是确定性的，适合机器请求。Web Crypto 在较新的 Chrome、Firefox 或 Safari 中可以生成 Ed25519 密钥对。
signature base 是实际参与签名的规范化文本，由被覆盖的组件按顺序逐行拼接而成。任何大小写、空格、参数顺序或换行不一致都会导致签名验证失败，因此它是排查签名被拒时最该先比对的参考。
不会。页面使用浏览器本地的 Web Crypto API 生成 Ed25519 密钥对，私钥只存在于当前页面内存中。工具不收集、不上传、不存储私钥；刷新或关闭页面后私钥即消失。下载的 JWK 或 PKCS#8 PEM 由你自己保存。
这是设计行为。工具不在 localStorage、IndexedDB 或服务器保存任何密钥，刷新页面就会丢弃。若还需要使用同一身份，请先下载私钥和密钥目录 JSON；重新生成后需重新发布 key directory JSON。
Ed25519 生成依赖较新的 Chrome、Firefox 或 Safari，请先升级浏览器。源站必须是带 HTTPS 的 origin，且不能包含路径、查询或片段，例如 https://example.com 可以，https://example.com/path 会被拒绝。
设有效期（如 30天、90天 或 365天）会强制你定期轮换，降低长期泄露风险；不设过期则省去维护，但一旦私钥泄露很难自然失效。对生产爬虫更推荐设置有效期并记录轮换时间。
User-Agent 和 IP 都很容易被伪造或不稳定，Web Bot Auth 通过私钥签名和公开密钥目录提供密码学身份证明。它不替代 robots.txt 等抓取规则；若要声明哪些路径可访问，可以配合 生成 robots.txt 规则，并用 测试 robots.txt 规则 验证。
