User-Agent 白名单是 Web 上最早的模式之一。你维护一份自己信任的爬虫和客户端名称列表。当请求带着匹配的 User-Agent 头部到达时，你放行它，跳过挑战，或者给它返回更轻量的页面。配置只需要几分钟，团队里的每个人都能理解。
在早期，自动化访问者主要只是少数搜索爬虫和一些监控工具，这种模式更有意义。如今，AI 代理、助手和自动化客户端以越来越多的数量访问应用，而且其中很多都会声明自己的名称。有些名称是真的，有些是复制来的。这个头部无法告诉你哪一种。
Proof of Actor 采取了不同的方式。它把 User-Agent 字符串当作它本来的样子, 即一个声明，并在存在更强证据时将其一并报告。本文说明按名称白名单的局限，网络层检查在哪些地方有帮助，以及已验证签名和明确的 Unknown 类如何改变整个判断方式。
简短版本
| User-Agent 白名单 | Proof of Actor | |
|---|---|---|
| 主要证据 | User-Agent 头部中的一个名称 | 签名、声明和信号，并分别标注其依据 |
| 客户端能伪造吗？ | 能，只要发送相同的字符串 | declared basis 可以被声称；verified basis 需要签名密钥 |
| 输出 | 在列表中或不在列表中 | Human, Human + AI, Agent 或 Unknown，外加依据 |
| 不明确的流量 | 视为不在白名单中，或默认允许 | Unknown，并由你为每条 route 选择回退策略 |
| 使用 AI 协助的人 | 看不见；他们使用普通浏览器 | 当被声明或被观察到时，作为单独类别 Human + AI |
| 维护方式 | 名称变化时手工更新列表 | 代理运营方发布密钥；策略写在你的代码里 |
| 安装后的默认行为 | 由列表允许什么就做什么 | observation；在你添加策略之前不会改变任何行为 |
| 最擅长的场景 | 对行为良好、已知客户端进行低成本路由 | 为产品和策略决策提供基于证据的 actor 上下文 |
下面逐行解释。
为什么按 User-Agent 白名单会被伪造
User-Agent 头部由客户端设置。浏览器会设置它，脚本会设置它，代理框架也会设置它。HTTP 中没有任何机制去检查这个值是否真实。如果你的白名单信任一个字符串，那么任何复制了这个字符串的人都会得到相同待遇。
这就是所谓的 user agent spoofing，而且很常见，原因很简单: 代价几乎为零。想绕过挑战的爬虫只需要借用一个你信任的爬虫名称。行为不当的客户端可以声称自己是某个流行助手。合法工具甚至可能发送一个通用浏览器字符串，因为库的默认值就是这样。
结果是，User-Agent 白名单有两种失败模式:
- 误信: 不受信任的客户端冒充受信任名称并通过。
- 误疑: 合法客户端发送了意外或通用字符串并失败。
仅凭头部本身，这两种失败都不可见。这就是核心限制，而任何列表维护都无法消除它。
这个头部仍然有用的地方
这并不意味着你应该忽略 User-Agent 字符串。行为良好的爬虫和代理会诚实地声明自己，名称对于路由、分析和调试很有价值。它告诉你客户端自称是什么。
正确的做法是把这条信息作为 声明，与其他证据一起衡量，而不是把它当成单独就能解锁访问的钥匙。Proof of Actor 正是这样记录它的。
反向 DNS 和 IP 列表: 部分措施
很多团队会通过网络检查来强化白名单。这些措施有帮助，也值得准确理解。
反向 DNS 验证
一些爬虫运营方会说明验证流程: 查找请求 IP 地址对应的主机名，确认它属于该运营方的域名，然后再查询这个主机名，确认它解析回相同的 IP。当这次往返都成功时，你就有了真实证据，证明请求来自该运营方的基础设施。
它的限制很现实。它只对那些有文档并支持该流程的运营方有效。它会增加 DNS 查询，你需要缓存它们。而且它告诉你的是网络信息，不是这个网络上的哪一个产品或代理发出的请求。
已发布的 IP 段
其他运营方会公布其自动化客户端使用的 IP 段。把请求与这些网段匹配起来很快，能提供与反向 DNS 类似的证据。IETF 目前仍在讨论发布这些网段的标准格式，但截至 2026 年 11 月，还没有定论，而且覆盖范围取决于每个运营方是否愿意发布。
随着更多代理运行在共享云基础设施上、代理后面，或者直接从用户自己的设备上运行，IP 证据的效力也会减弱。一个云地址可能承载多个互不相关的客户端，而从人的浏览器里运行的代理，看起来就像那个人自己的网络。
网络检查合起来能说明什么
反向 DNS 和 IP 列表能把某些声明转化成对一部分知名运营方更强的证据。它们覆盖不了代理和工具的长尾，也完全帮不上和 AI 协作的人。它们是部分措施: 值得使用，但单靠它们不够。
签名与声明
更强的证据形式是密码学签名。通过 HTTP Message Signatures，它由 RFC 9421 定义，客户端会用私钥对每个请求的选定部分进行签名。验证方获取运营方公开发布的公钥并检查签名。如果验证通过，就说明该请求是由持有该密钥的一方签署的，而且签名覆盖的部分在传输途中没有被改动。
IETF 的 Web Bot Auth 工作组正在标准化自动化客户端如何使用这些签名，以及如何发布它们的密钥。我们在 Web Bot Auth for product teams 中对当前状态做了说明。
Proof of Actor 会把有效签名作为 Verified 证据。User-Agent 字符串、客户端提示，或请求正文中的自述，都算作 Declared。行为和上下文信号算作 Inferred，并会按该方式标注。每个结果都会说明它依赖的 basis，因此你的团队不会把声明误认为检查。完整定义见 evidence basis 条目。
即使是已验证证据，也有一个限制。有效签名只能证明是哪个密钥签署了请求。它不能证明这个代理被允许执行它正在请求的动作。那是 agent authorization 的问题，并且仍然由你的应用来处理。
处理 Unknown，而不是猜测
白名单会把每个请求强行分到两个桶里: 在列表中，或者不在列表中。实际情况通常意味着，不明确的流量会被套用你的默认值，而这个默认值往往是针对整个站点一次性设定的。
Proof of Actor 会把 Unknown 当作一类一级结果。当前面的证据无法支持可靠判断时，它会明确说明，而不是去猜。然后由你的策略决定 Unknown 在每条 route 上意味着什么:
- 对公开文档或营销页面，允许它。
- 对搜索或列表 endpoint，按正常限流允许它。
- 对账户变更，保留你现有的检查。
- 对高影响操作，送去 review，或者要求更强的信号。
处理 Unknown 流量 指南和 unknown classification 条目会逐步说明这些模式。跟踪 Unknown 比率随时间的变化，也能告诉你有多少流量仍然依赖薄弱证据。
那么，使用 AI 协助的人怎么办？
User-Agent 白名单无法说明一个人在普通浏览器里使用 AI 助手的情况。他们的 User-Agent 只是普通浏览器字符串。可很多产品都希望识别这种交互，例如给 AI 起草的提交加标签，或者理解使用 AI 协助的用户如何完成 onboarding。
当这种协助通过支持的集成被声明或被观察到时，Proof of Actor 会将这些交互报告为 Human + AI。它不会仅凭写作风格去猜。更多内容见 AI-assisted interaction。
从白名单迁移到基于证据的策略
你不必在第一天就移除白名单。一个安全的路径如下:
- 以 observation mode 安装。 Proof of Actor 不改变任何行为。你的白名单继续工作。
- 进行对比。 针对每条 route，查看哪些已白名单请求带有 verified evidence，哪些只带有声明，哪些最终是 Unknown。
- 预览策略。 草拟一个对 verified agents、declared agents 和 Unknown 采用不同处理方式的策略，并在真实流量上预览其效果。
- 按 route 逐步 enforce。 从那些伪造名称后果最严重的 route 开始。
- 把白名单保留为提示。 名称仍然对路由和分析有用，同时它们的 basis 也可见了。
安全推出 actor-aware 策略 指南会覆盖每一步，而 verified automated requests 解释了已签名客户端如何接入。
什么时候白名单已经足够
对于低风险路由，例如在公开内容上给已知爬虫提供一个更轻量的页面，User-Agent 白名单通常就够了。伪造名称的代价很小。
当决策会产生后果时，例如跳过挑战、暴露更丰富的数据，或者允许写操作，你就需要可以核验的证据。这正是 Proof of Actor 的用武之地，它与您已经运行的网络检查和边缘控制协同工作。
开始使用
Proof of Actor 目前处于私有 beta。被选中的 founding developer 团队在约定的使用限制内可获得最长 12 个月的免费访问，且不会自动计费。申请 early access，告诉我们你现在对白名单了哪些客户端，以及你希望用更好的证据保护哪些 route。