Yandex（Yandex）数据中心遭袭的报道传出后，网上称俄罗斯机器人农场和影响力行动已瘫痪，HTTP 流量陡降似印证受损阻止了恶意行为者。但汇总流量指标易误导。Yandex 有两个 ASN：AS13238 用于 Yandex搜索（Yandex Search），AS200350 运行 Yandex.Cloud（Yandex.Cloud）。我们用 Cloudflare Radar（Cloudflare Radar）和 Bot Management（Bot Management）数据分析发现，两者流量均降但影响不同：AS13238 的下滑几乎全是索引网页等资源的已验证搜索爬虫；AS200350 的漏洞扫描等恶意活动减少，大规模自动化却迁移到其他托管商。

在有关 Yandex 数据中心遭袭的报道出现后，网上开始流传一种说法：俄罗斯的机器人农场和影响力行动已经被打下线。HTTP 流量图显示流量陡降，更让人猜测基础设施损毁已经阻止了这些恶意行为者。但整体流量指标很容易误导人。Yandex 关联着两个自治系统编号（ASNs）：AS13238 用于 Yandex 的搜索引擎，AS200350 则运行其云服务。

我们用 Cloudflare Radar 和 Bot Management 数据分析了这两个 ASN 受到的影响：两者流量都出现下降，但受到的影响并不相同。

• Yandex Search（AS13238）：流量下降几乎全部来自已验证的搜索爬虫，它们原本在抓取网页、图片和站点资源。
• Yandex.Cloud（AS200350）：漏洞扫描和探测等恶意活动有所减少，但大规模自动化流量并未消失，而是转移到了其他托管服务商。

虽然恶意流量可能来自某家服务商，但这并不一定能说明谁该为这些流量负责。要理解为什么此次袭击对恶意流量几乎没有持久影响，需要分析请求行为，而不只是看整体流量模式。

发生了什么：袭击的影响与事件前基线

10 月 7 日至 11 日，据报道乌克兰无人机袭击了俄罗斯三处 Yandex 设施，逐步使数据中心和网络容量下线。在 Cloudflare Radar 上可以看到，10 月 11 日 Yandex 网络几乎彻底瘫痪：Yandex Search（AS13238）流量比基线下降 99%，Yandex.Cloud（AS200350）下降 90%。尽管出现过短暂的部分恢复，两个网络直到 10 月 13 日仍处在中断状态，稳定在比正常基线低 86–90% 的水平。（截至 10 月 14 日 18:00 UTC，流量为正常水平的 85%。）

整体 HTTP 流量下降只能说明网络瘫痪，并不能揭示恶意或规避性机器人是否被阻断。查看事件前的自动化基线可以看到，在袭击前，自动化请求占 Cloudflare 网络观察到的全部 HTTP 流量的 36.1%，占来自俄罗斯 IP 地址的流量的 35.8%。

由于两个受影响的 ASN 承担的角色不同，中断对自动化活动的影响也不一样。

Yandex Search ASN（AS13238）用于搜索索引抓取。Cloudflare 将其 99.5% 的请求归类为自动化请求，其中 93.6% 的机器人请求被归为已验证机器人。分析显示，来自该 ASN 的流量会索引页面、渲染页面并渲染图片，这与搜索爬虫的行为一致。Yandex Search ASN 提供了约 7% 的俄罗斯来源机器人请求，仅占全球总量的 0.05%。

Yandex.Cloud ASN（AS200350）是云托管网络，承载的自动化流量组合非常不同。其约 95.0% 的已评分请求是机器人，但观察到的机器人请求中没有一个是 Cloudflare 已验证的。Yandex.Cloud 的机器人看起来更像软件应用：近三分之二的请求会向网站发送数据，有些把自己标识为 JavaScript、Python 或 Go 程序，而且相比 Yandex 的搜索机器人，有更大比例流向软件公司。Yandex.Cloud ASN 提供了约 2% 的俄罗斯来源机器人请求，仅占全球总量的 0.01%。

事件对整体机器人流量的影响

“机器人流量”指的是对 Cloudflare 网络上网站的自动化请求，例如爬虫和脚本，不一定指社交媒体平台上的活动。随着 Yandex 网络容量丧失，它们的机器人请求也随之下降。这在意料之中：来自 Yandex Search 和 Yandex.Cloud 的流量几乎全是自动化流量。虽然总流量出现了明显下降，但我们没有看到任何证据表明，恶意流量的全球性中断与 Yandex 流量下降有关。

来自俄罗斯的机器人请求下降幅度，大致与下线的 Yandex 流量成比例，因为这些网络的请求大多是自动化的。

| 日期（UTC+3） | 全球机器人请求（占全部 HTTP 请求比例）* | 俄罗斯来源机器人请求（占俄罗斯来源 HTTP 请求比例） | |---|---|---| | 10 月 1–6 日：事件前基线 | 39.4% | 50.4% | | 10 月 7–8 日：无人机袭击 Sasovo | 39.2% (-0.2%) | 48% (-2.4%) | | 10 月 9 日：无人机袭击 Kaluga | 39.4% (+0%) | 42.5% (-7.9%) | | 10 月 11 日：无人机袭击 Vladimir | 39.5% (+0.1%) | 42.2% (-8.2%) | | 10 月 12 日 | 39.6% (+0.2%) | 43.6% (-6.8%) | | 10 月 13 日 | 39.5% (+0.1%) | 42.1% (-8.3%) |

* Radar 同时按总 HTTP 请求和 HTML 请求（近似页面浏览）统计全球流量。上表反映总请求量。

Yandex Search ASN（AS13238）受到的影响：搜索抓取减少

Yandex Search ASN 的下降几乎全部是搜索抓取。抽样请求显示，78.1% 属于已验证的 YandexBot，11.5% 属于 YandexRenderResourcesBot，1.9% 属于 YandexImages。

在各行业和服务中，降幅最大的是出版和报纸领域，来自 Yandex 网络的流量下降了 44%。在事件前，该 ASN 流向新闻站点的流量中约有 90% 是 YandexBot 在索引文章，其中 40.5% 的 Cloudflare 客户返回 HTTP 403 Forbidden，因为站点所有者屏蔽了该爬虫。当 Yandex Search ASN 下线后，客户只是看到来自 Yandex 的索引变少。

Yandex.Cloud ASN（AS200350）受到的影响：合法使用与迁移的恶意流量

Yandex.Cloud 呈现出完全不同的情况。在报道的袭击发生后，来自 Yandex.Cloud 的机器人流量下降了约 40%。多个类似攻击的类别降幅尤为明显。例如，WordPress 插件探测下降了 90%，被扫描器识别的请求下降了 93%。值得注意的是（也很说明问题），在事件期间，Cloudflare 客户对 Yandex.Cloud 流量的拦截也下降了 70%，这表明来自该 ASN、真正打到 Cloudflare WAF 上的恶意流量按比例变得更少了。

对各业务垂直领域的影响

按请求目标行业划分，Yandex.Cloud 的机器人流量也很有意思：

| 目标行业 | 事件前机器人流量 | 事件期间机器人流量（10 月 7–13 日） | 变化 | 4xx（客户端错误）HTTP 响应状态占比：事件前 → 事件期间 | |---|---|---|---|---| | 计算机软件 | 24.24M | 15.18M | -37.4% | 18.5% → 15.9% | | 赌博 | 23.01M | 18.80M | -18.3% | 99.1% → 99.3% | | 媒体（含成人） | 1.33M | 223.1K | -83.3% | 82.0% → 61.8% | | 互联网与电信 | 524.2K | 206.5K | -60.6% | 71.4% → 51.1% | | 旅行 / 旅游 | 363.9K | 158.1K | -56.6% | 27.0% → 12.3% | | 零售 / 批发 | 316.0K | 167.7K | -46.9% | 71.0% → 55.9% | | 游戏 / 电脑游戏 | 226.3K | 63.2K | -72.1% | 51.4% → 9.2% | | 出版 / 报纸 | 90.8K | 8.8K | -90.3% | 90.2% → 61.4% |

Yandex.Cloud ASN 的大部分流量落在两个行业桶里：计算机软件和赌博。计算机软件桶对一个用于托管第三方应用和软件集成的 ASN 来说是可预期的。事实上，我们甚至看到 api.cloudflare.com 是 Yandex.Cloud 请求流量排名靠前的主机名。该部分流量在事件前和事件期间总体都成功（请求返回 200），说明属于合法使用。

赌博行业提供了最清楚的证据，表明恶意自动化是转移了，而不是消失。Yandex.Cloud 的机器人请求几乎全部针对一个赌博客户账户，流量在该账户的多个主机名之间转移。在 10 月 8 日中断发生后，来自 Yandex.Cloud、流向该账户的机器人请求立即降为零。与此同时，完全相同的请求开始出现在其他俄罗斯托管 ASN，包括 Radist 和 Selectel。这些传入流量在不同服务商之间保持了完全一致的指纹：

• 相同的 JA4 TLS 客户端指纹
• 相同的异常请求路径和 HTTP 头
• 相同的自定义 User-Agent 字符串

总体来看，针对赌博账户的俄罗斯机器人流量在一周内基本持平，从 1.677 亿次请求变为 1.701 亿次请求（+1.4%）。自动化从未停止运行；一旦 Yandex.Cloud 不可用，运营者只是把工作负载迁移到了其他云服务商。

在大多数行业中，来自 Yandex.Cloud、返回任何 HTTP 4xx 响应的机器人请求占比都下降了。这主要是因为上述类似攻击的流量减少。结合赌博客户的分析可以看出，原本通过 Yandex.Cloud 发送请求的恶意流量，在服务中断后只是把“服务”转移到了其他服务商。

最后，在分析社交媒体流量时，我们发现无论是来自俄罗斯 IP 的流量（事件期间总流量下降 0.6%），还是全球流量（事件期间总流量增长 1.2%），都没有出现意外变化。我们对某个社交媒体平台的“发帖”“回复”“点赞”端点所遭受的机器人流量重复了这一分析，同样没有发现意外变化：事件前或事件期间，来自俄罗斯 IP 的流量（事件期间总流量下降 5.7%）或全球流量（事件期间总流量增长 1.1%）均是如此。根据我们的评估，这些数据似乎不支持“袭击使社交媒体操纵瘫痪”的说法，不过如果缺少 Cloudflare 之外的数据做进一步分析，我们不能断定完全没有关联。

数据说明了什么，又没说明什么

当 Yandex 网络的流量崩溃时，网上散布着猜测，认为俄罗斯影响力行动和恶意僵尸网络遭受了毁灭性打击。Cloudflare 的数据讲述的是另一个故事：在 Cloudflare 的网络上，没有证据表明这些袭击把社交媒体操纵打下线，或以其他方式扰乱了互联网上的恶意活动。相反，数据说明：

• 搜索索引抓取下降。从 Yandex Search ASN 下降的流量绝大多数是已验证的 YandexBot 爬虫，它们在抓取新闻文章和网页资源。主要影响是 Yandex Search 中的内容发现减少。
• 恶意自动化是迁移而非停止。虽然 Yandex.Cloud 上的漏洞扫描和插件探测一度下降，但大规模操作很快转向了其他托管网络。

网络中断只意味着特定服务器不再发送请求，并不代表自动化威胁消失了。云工作负载是可移植的，因此当数据中心下线或 IP 前缀被屏蔽时，运营者可以在几小时内把脚本迁移到另一家服务商。

此处的分析提醒我们，客户端 ASN 的流量规模并不可靠，不能作为解读自动化机器人行为的依据。防御自动化威胁需要检查请求行为，例如识别共用的 JA4 指纹、监控异常请求速率，并对敏感端点应用 WAF 规则，无论请求来自哪个网络。物理基础设施是静态的，但恶意自动化天生就是为了迁移而构建的。

社区讨论以质疑和辨析为主，多数意见认为所谓俄罗斯水军被袭击“打下线”的说法缺乏证据或被误读，少数人则依据流量跌幅坚持机器人确实被击垮。分歧主轴在于：观察到的流量变化究竟证明水军消失，还是只反映爬虫流量、中介路由，或俄罗斯集中式云服务（如 Yandex Cloud）中断的副作用。

认为所谓俄罗斯水军被袭击打下线是误读或假象

• 论据概括：Cloudflare 网络遥测并未显示袭击把社交操纵或恶意活动打下线；所谓“水军崩溃”被一份深度研究报告称为由误读流量数据和伪造病毒图造成的分析幻象。许多人指出，下降的其实可能是搜索引擎爬虫，而非垃圾水军；也有个人体验称仍看到和以往一样多的机器人，并认为乌克兰要清除水军还有更多工作要做。专业运营的流量归因并不简单，来源 ASN 下降不等于机器人消失，技术原因见下文补充。（认可度：较多人）
• 引用： > Cloudflare 网络上并没有证据显示袭击把社交操纵流量打下线，这直接反驳了“俄罗斯水军因攻击神奇消失”的流行说法。（@gruez）

认为流量数据恰恰证明机器人被打下线

• 少数人反向解读数据，认为面向“出版商和报纸”的机器人流量大幅下降已足够说明问题，坚持俄罗斯机器人确实因袭击被打下线；这与主流的误读判断形成直接对立。（认可度：少数人）
• 引用： > 面向“出版商和报纸”的机器人流量下降了 90.3%，这显然说明俄罗斯机器人已经被打了下线。（@alpineman）

认为更值得关注的是俄罗斯集中式云与数字基础设施被打瘫

• 较多人认为，把爬虫流量和水军混为一谈让人忽略了更大的故事：俄罗斯政府推动数字服务集中到少数被官方挑选的“赢家”企业手中，这些企业构成国家监控体系的骨干，因此高度集中的数据中心成为极具吸引力的目标。讨论将 Yandex Cloud 长时间全红、恢复无期类比 AWS us-east-1 或 AWS、Google、Stripe、Dropbox 同时宕机，强调其对日常服务的真实冲击。（认可度：较多人）
• 引用： > 把爬虫流量和水军混为一谈，反而让人忽略了更大的故事：俄罗斯把数字服务集中到少数“赢家”手中，成为监控骨干，袭击数据中心好比 AWS、Google、Stripe 和 Dropbox 同时下线且恢复无期。（@mopsi）

认为机器人可能已转移到其他供应商，应追踪并继续封锁

• 较多人默认机器人并未消失，而是转移到替代云供应商，因此追问它们具体转移到了哪些提供商、是否在俄罗斯境内，以便继续封锁；若替代供应商在俄境内，乌克兰可以继续以“数据中心阻断即服务”的方式打击。也有人从网络设计角度提到多 ASN 对冗余和追踪的影响，并疑问当前是否更容易定位机器人来源。（认可度：较多人）
• 引用： > 它们转移到了别的哪些供应商？我们好去封锁。（@sdcfgy）

有价值的补充

• 专业机器人运营通常会把流量经中介转发，而不是直接从自有 ASN 发出，因此仅凭某类来源 ASN 的流量下降，无法判断机器人是否还在活动；这是关于流量归因的技术提醒。（源自 @ratg13）
• 有人仍看到和往常一样多的机器人，并给出一条 nginx 规则思路：把访问 xmlrpc、wp-login.php、wp-admin 等路径的请求 301 重定向到链路本地地址 169.254.169.254，以触发 AWS GuardDuty 或 GCP SCC 等云平台安全机制；这条带恶作剧色彩的补充代表社区对“水军并未消失”的情绪。（源自 @Bender）