什么是 user-agent 伪装
每个 HTTP client 都可以发送一个 User-Agent header 来描述自己: 浏览器名称和版本、爬虫名称、库标识符。这个 header 是自报的。HTTP 中没有任何机制检查它是否真实，所以任何 client 都可以发送任意值。user-agent 伪装就是发送一个误导客户端身份的值，例如:
- 一个自动化脚本把自己表现成当前的桌面浏览器,
- 一个抓取器声称自己是知名搜索爬虫，以获得更有利的处理,
- 一个 AI agent 使用通用的 browser 字符串，从而被当作人来处理。
为什么这很重要
许多系统仍然会根据 user-agent 字符串做决策: 将已知爬虫加入允许名单，为 bot 提供不同内容，或将自动化流量排除在分析之外。这些决策都会继承这个 header 的弱点。如果某个 policy 说“允许任何声称自己是 crawler X 的请求”，那它实际上会放行所有复制了 crawler X 字符串的人。
对于接收 AI agent 流量的应用来说，这一点随着时间推移会变得更重要。Agents 越来越多地运行在真实浏览器或无头 browser 框架中，因此它们的 user-agent 字符串看起来和人类浏览器完全一样。另一些则会诚实标识自己。仅靠这个 header 无法判断谁是谁。我们关于如何判断网站流量是否来自 AI agents的文章会介绍更有效的信号。
比 header 更好的证据
- 密码学签名。 通过 HTTP Message Signatures 和 Web Bot Auth 这项工作，客户端可以证明自己持有由其所声明的运营方发布的密钥。复制的 user-agent 字符串无法重现签名。
- 运营方发布的验证。 一些爬虫运营方会发布 IP 段，或支持反向 DNS 检查，这些都比单独依赖 header 更难被冒充。Google 针对其爬虫文档化了 reverse DNS and IP range check，Microsoft 提供了 Verify Bingbot tool，而 OpenAI 为其每个 bot 发布 IP address files。Anthropic 对其托管 browser agent 的指引明确指出，任何人都可以发送相同的 User-Agent header，并建议检查其发布的 IP 地址。
- 一致性检查。 将声称的 client 与协议细节和交互信号进行比较，可以发现某些声明是否不匹配，但这产生的是推断，而不是证明。
- 凭证。 对于 API，API key 或 token 可以告诉你是哪个 account 在调用，而不管 header 里写了什么。
常见误解
- “浏览器 user-agent 就意味着人。” 无头浏览器和 agent 框架经常发送浏览器字符串。
- “爬虫 user-agent 就意味着那个爬虫。” 如果没有签名或运营方验证检查，它只能算是一个声明。
- “伪装一定是恶意的。” 一些合法工具会发送通用字符串，以避免被返回损坏的页面。伪装的意义在于降低对这个 header 的信任，而不是证明恶意意图。
Proof of Actor 如何处理 user-agent 字符串
Proof of Actor 会把 user-agent 声明记录为 Declared 证据: 这是客户端自述的信息，可能真实，也可能不真实。它不会自动把声明提升为 Verified。如果一条请求唯一的身份信息只是一个爬虫 user-agent 字符串，它会据此标记; 当证据不足时，结果会是 Unknown，而不是自信地猜测。然后，你在 Route 中的 policy 可以把已验证签名的 agent 和自声明的 agent 区别对待，例如在只读 route 上都允许，但对声明型请求施加更严格的限制。
来源
- RFC 9110: HTTP Semantics, User-Agent: 该 header 由 client 自报
- Google: Verifying Google's crawlers and fetchers: 反向 DNS 和已发布 IP range 检查
- Microsoft Bing: Verify Bingbot tool: 检查某个 IP address 是否属于 Bingbot
- OpenAI: Overview of OpenAI Crawlers: user agents 和已发布的 IP address files
- Anthropic: how Anthropic-hosted browsers identify themselves: 提醒 User-Agent header 可以被复制