逆向分析：四大AI服务的网络流量对比

逆向分析：四大AI服务的网络流量对比 | 前端进阶之旅

Full translation

完整中文译文

有人向 AI 助手询问我运营的网站时，这个助手是真的获取页面，还是从之前建立的索引中回答？我想得到明确答案，所以设置了一个 nginx 探针，向主要聊天机器人提示应该强制实时获取的查询。这篇文章是服务器记录的内容，以及你可以从中安全测量的东西。

两种不同的信号

"AI 流量"通常指两件事之一，nginx 日志让区别显而易见。

提供商端获取。助手直接命中源站，通常带有专用用户代理，没有 referrer。

真实点击访问。人读了 AI 的答案，点击引用，以正常浏览器身份到达，带有助手的 referrer。

把这两者折叠到一个单一的 AI 流量数字里会隐藏数据中最有用的区分。一个是模型来读你的网站。另一个是因为模型指向，人类在读你的网站。

自定义 nginx 日志格式捕获默认日志压缩掉的请求头：

log_format ai_probe escape=json
  '{'
    '"time":"$time_iso8601",'
    '"ip":"$remote_addr",'
    '"uri":"$request_uri",'
    '"status":$status,'
    '"ua":"$http_user_agent",'
    '"referer":"$http_referer",'
    '"accept":"$http_accept"'
  '}';

每个助手都收到指向唯一查询字符串的提示（/?ai=chatgpt、/?ai=claude 等），所以我可以用单一 grep 命令区分哪个命中来自哪个助手。我在多个会话中重复运行提示，这样临时缓存命中就不会隐藏检索路径。

谁公布了自己，以及如何公布

五个助手用检索特定的信号在用户代理中出现。

所有五个都获取了页面。

谁没有公布自己

三个助手没有明确的检索用户代理可以捕获。

下面详细说明每个助手。

ChatGPT：候选页面间的多 IP 突发

ChatGPT-User 从同一突发中的多个源 IP 命中源站，通常在模型决定引用哪个时一次拉取多个候选页面。在我运营的另一个生产网站上，最近 24 小时的时间窗口捕获了来自五个不同 Azure 范围的 ChatGPT-User 请求：23.98.x.x、20.215.x.x、40.67.x.x、51.8.x.x 和 51.107.x.x。这与 OpenAI 在其机器人文档中对该代理的描述相符。如果你基于单个源 IP 进行速率限制，你会计数不足。

Claude：每次都先检查 robots.txt

Claude-User 在每次页面获取前拉取 /robots.txt，来自 Anthropic 拥有的 IP 空间中的 216.73.216.0/24 范围。重定向被干净地跟踪，包括常见的尾部斜杠规范化。robots 预检与 Anthropic 在其爬虫文档中记录的行为相符。如果你想让 Claude 跳过你的网站，在 robots.txt 中添加 User-agent: Claude-User disallow。Claude 会在下次获取时遵守。Anthropic 还运营两个其他不应与此混淆的机器人：Claude-SearchBot（其搜索索引）和 ClaudeBot（其训练爬虫）。只有 Claude-User 意味着真实用户刚才向 Claude 询问了关于你页面的内容。

Perplexity：直接获取，没有客套

Perplexity-User 直接获取页面。没有 Accept 请求头，没有 referrer。另外，PerplexityBot（其搜索索引爬虫，不是用户检索的）ping 了 /robots.txt。我总共捕获了很少的 Perplexity 检索运行，而 Perplexity 可以从自己的索引回答而不命中源站，所以安全的措辞是 Perplexity 可以检索实时内容；它不必检索。参见 Perplexity 的机器人文档了解其自己的表述。

Gemini：没有命中，一次都没有

探针在 Gemini 运行期间从 gemini.google.com 和 google.com 捕获了真实点击访问，正常浏览器在用户读了答案并点击引用后到达。这部分信号是干净的。在提供商获取方，什么都没有到达。这里有两个单独的观察：

观察到的。在 Gemini 提示窗口期间，来自任何 Google 用户代理的零请求到达。Gemini 完全从其自己的索引回答；它没有执行到达我的源站的实时提供商端获取。

结构性的。Google 没有为 Gemini 发布检索特定的用户代理。根据 Google 自己的爬虫文档，AI Overviews 和 AI Mode 基于 Googlebot 填充的相同搜索索引。如果 Gemini 曾进行实时获取，它会以 Googlebot 的身份到达，无法从普通搜索索引与区分。

三个实践后果：

Googlebot 命中无法仅从请求中归属于 Gemini vs 经典搜索。

阻止 Google-Extended 不会阻止 Googlebot。它限制 Googlebot 爬取的内容是否可用于 Gemini 训练和基础。

仅从日志测量 AI 流量在供应商之间会是不对称的。Google 的差距是结构性的，不是可以解决的东西。

Copilot 和 Grok 以普通浏览器身份到达

Microsoft Copilot 以纯 Chrome 135 on Linux x86_64 的身份获取页面，带有完整的浏览器风格 Accept 请求头和常见的 CSS、JS 和图像请求突发。没有明确的 Copilot 用户代理，在提示窗口期间没有 Bingbot 活动。根据 Microsoft 对生成式 AI 和公共网站的指导，Copilot 基于由 Bingbot 填充的 Bing 索引，但我们观察到的实时获取不是 Bingbot。仅从你的日志中，你无法通过用户代理积极地将 Copilot 获取归属于 Copilot。

Grok 以纯 Mac Safari 26 的身份获取页面，在第二次运行中以纯 Mac Chrome 143 的身份。没有明确的 UA，没有后缀，没有请求头信号能让你从请求单独归属到 xAI。Grok 没有记录检索特定的机器人。与 Copilot 相同的可观察性问题，甚至更少的文档可回退到。

在 Gemini、Copilot 和 Grok 之间，三个主要聊天机器人中的三个要么在提供商获取日志中不可见（Gemini），要么无法与普通人类访客区分（Copilot 和 Grok）。如果你试图仅从日志测量 AI 流量，计划错过这三个。

Meta AI：两个已记录的机器人，一个观察到的，没有确信的映射

Meta 似乎维护自己的索引，就像 Google 一样。在单独测试中，Meta AI 返回不再存在于实时页面上的信息，与索引优先检索路径一致：当页面已知时从索引服务，仅当不知道时才实时获取。

当 Meta 在我们的探针中执行实时获取时（通过其 Muse Spark 表面提示），请求到达为 meta-webindexer/1.1，带有 Accept: /。Meta 自己的网络爬虫文档将不同的机器人 Meta-ExternalFetcher 描述为 Facebook、Messenger、Instagram 和 WhatsApp AI 功能的用户启动检索机器人，并记录它可能绕过 robots.txt，理由是人或代理跟踪了特定链接。

在给定会话中只有这些机器人之一出现，探针无法隔离触发每一个的因素：产品表面、首次 vs 重复获取、先前索引状态或其他。meta-webindexer 和 Meta-ExternalFetcher 都是 Meta 的实时获取机器人。如果你想明确地按 UA 阻止其中任何一个，而不是假设单一名称覆盖 Meta 的所有 AI 功能。

Manus 以平凡的方式宣布自己

Manus 以 Mozilla/5.0 ... Chrome/132.0 ... ; Manus-User/1.0 的身份获取。那个 Manus-User/1.0 后缀是你在日志中发现 Manus 的方式。与此探针中测试的其他代理不同，Manus 呈现了完整页面：HTML、每个 CSS 文件、每个 JS 文件、每个图像。在此探针的代理中，Manus 是在 UA 中清晰标记自己的，最容易在日志中识别的。

你实际上可以测量什么

你可以从日志中测量两件事而无需猜测。

供应商记录的或探针观察到的检索用户代理命中你的源站：ChatGPT-User、Claude-User、Perplexity-User、Manus-User、Meta-ExternalFetcher（已记录）和 meta-webindexer（观察到的；Meta 机器人类对我们来说不完全清楚）。

正常浏览器用户代理，带有聊天机器人作为 referrer：chatgpt.com、claude.ai、perplexity.ai、gemini.google.com、copilot.microsoft.com、grok.com、meta.ai 和 google.com / bing.com 作为更广泛的桶（没有办法仅使用 HTTP 隔离 AI Mode 或 Copilot 从经典搜索）。

搜索索引机器人（OAI-SearchBot、Claude-SearchBot、PerplexityBot、Googlebot、Bingbot）也出现在日志中，但它们不是回答特定用户问题的 AI——它们在建立索引。不要将它们计为实时检索。训练机器人（GPTBot、ClaudeBot、CCBot）是第三个单独的信号，也不应计为检索。

相关的值得命名的一点：搜索索引和训练机器人不期望为了响应特定用户查询而命中源站，所以它们在像这样的探针期间的缺席是结构性的，不是反对它们的证据。测量训练或索引活动需要单独的长时间窗口日志拉取，不是提示驱动的测试。

附录：供应商记录的机器人分类

Microsoft Copilot 和 Grok 不在此表中。两个供应商都没有记录我们可以引用的检索特定的用户代理；我们从两者观察到的实时获取都以普通浏览器身份出现。

在你自己的网站上检查这个

我们的 robots.txt 检查器读取你的实时文件并报告它当前允许或阻止哪些检索、搜索和训练用户代理。无需账户。这是将上表转换为关于你的域的一个具体答案的最快方式。