从2026年10月8日至11日，Yandex失去了三个数据中心：萨索沃和弗拉基米尔完全停运，卡卢加则处于降级状态。Yandex Cloud进入紧急模式，并直接建议客户启用自己的灾难恢复计划。最有趣的事情发生在之后。Cloudflare分析了那些生活在这个云中的机器人发生了什么，发现它们并没有消失，而是在一天内迁移到了其他主机商，并且仍然通过相同的TLS指纹JA4被识别。对于所有从事解析和自动化的人来说，这是一个罕见的实证实验，涉及两个问题：当基础设施崩溃时该怎么办，以及为什么更换IP和主机不会改变机器人的“身份”。
Yandex发生了什么
根据BleepingComputer的报道，Yandex表示三个数据中心因无人机攻击而受损。Yandex没有指明罪魁祸首；媒体引用BBC的消息将袭击与乌克兰联系在一起。时间线如下：
- 10月8日 — 萨索沃（瑞亚赞州）：火灾，场地完全停运；
- 10月9日 — 卡卢加：降级运行，并未完全停运；
- 10月11日 — 弗拉基米尔：完全停运。
在Yandex Cloud的状态页面上，部分服务（控制台、API、IAM、数据库、S3、Kubernetes）仍然可用，但存在性能问题，计算和AI Studio部分可用。公司表示无法提供可靠的恢复时间，认为剩余资源配置不稳定，并建议客户使用替代的灾难恢复计划。在BleepingComputer发布时（10月12日），尚未有恢复时间和可能数据丢失的明确性。
Cloudflare看到的情况：流量下降，机器人没有
10月14日，Cloudflare发布了其网络事故的分析。关键数字如下：
- 10月11日，来自Yandex搜索（AS13238）的流量下降了99%，来自Yandex.Cloud（AS200350）的流量下降了90%；
- 在AS13238中，99.5%的请求在事故发生前是自动的，其中93.6%的机器人请求是Yandex的验证爬虫。该网络提供了大约7%的来自俄罗斯IP的所有机器人请求；
- 在Yandex.Cloud中，约95%的评估请求是机器人，并且没有一个是经过验证的。这大约占俄罗斯机器人流量的2%；
- 来自Yandex.Cloud的机器人流量下降了约40%，来自该网络的WordPress插件扫描下降了90%。
接下来是关键。几乎所有来自Yandex.Cloud的机器人请求都指向Cloudflare的一位客户账户，该客户来自博彩行业。在10月8日故障后，来自Yandex.Cloud的请求降至零——随后，来自其他俄罗斯主机商的相同请求立即出现，Radist和Selectel。它们具有相同的JA4 TLS指纹、相同的稀有路径和头部，以及相同的非标准User-Agent字符串。一周的结果是：俄罗斯机器人流量对博彩账户没有下降，反而增长——从1.677亿增加到1.701亿请求（+1.4%）。
Cloudflare的结论非常明确：物理基础设施是静态的，而恶意自动化的构建方式使其能够迁移。HTTP流量的下降显示了事故，但并不意味着机器人停止了。
轰动的版本和数据：“机器人沉默”被夸大了
与此同时，乌克兰反信息中心（ЦПД）表示，在对萨索沃的袭击后，Facebook和Telegram上可疑账户的消息数量在一天内下降了83.6%——从4032条降至660条。但是，正如TechRadar分析的那样，到了10月10日，活动恢复到4585条消息，而在10月11日超过了袭击前的水平。Cloudflare没有发现明显的变化：来自俄罗斯IP的机器人流量对某社交网络的“帖子、回复、点赞”端点仅下降了5.7%。Graphika也没有发现被追踪社区中活跃账户的损失。研究员Renee DiResta在Lawfare中称这个故事美丽，但更像是虚构而非事实。
给分析师的一个单独教训是：10月8日，整个俄罗斯的银行、零售、运营商和媒体都发生了故障，因此在这一天的任何“活动”下降都不能简单地归因于机器人。聚合流量容易误导。
第一课：IP和主机不是机器人的身份
Cloudflare识别“Yandex.Cloud → Radist/Selectel”的关联并不是通过地址——地址和ASN完全更改。它是通过行为和客户端指纹识别的：
- JA4 — TLS ClientHello的哈希：密码套件、扩展、协议版本的集合。它描述的是程序，而不是网络。相同的Python脚本在新服务器上也会产生相同的JA4；
- 稀有路径和头部 — HTTP头部的顺序和集合，普通浏览器中不会出现；
- 自定义User-Agent — 唯一的字符串，本身就是一个标签。
合法解析的实际结论是：更换数据中心或IP池并不会使您对反机器人系统“变新”，如果整个客户端栈保持不变。相反：如果您的爬虫诚实地自我介绍，行为谨慎且不攻击敏感端点，稳定的指纹就不是问题。问题出现在当客户端栈看起来像是现实用户所没有的东西：声称是Chrome的TLS指纹来自requests库，奇特的UA，非标准的头部。关于这个检测层的详细构造，我们在分析中写道 JA4和TLS指纹在抓取中的应用。
请注意另一个细节：机器人从一个数据中心迁移到了其他数据中心。对于Cloudflare来说，这仍然是同一类别的主机ASN，许多网站对其预先存在高度的不信任。网络不同——风险轮廓相同。
第二课：基础设施必须能够在数小时内迁移
恶意攻击者在一天内迁移，因为他们的自动化本身是可迁移的。诚实的团队，无论是收集价格、监控结果还是进行分析，都同样需要这种可迁移性。Yandex Cloud的建议“使用替代灾难恢复计划”只有在这样的计划已经存在时才有意义。最小的检查清单：
- 代码和配置——在云外。代码库、容器镜像、环境变量应该存放在可以用一条命令在其他主机上部署解析器的地方。
- 提前准备第二个主机商。在不同司法管辖区和地区的替代提供商处拥有账户、付款和测试服务器。在事故发生当天注册和通过审核——为时已晚。
- 输出层与计算分开。如果请求是通过代理提供商而不是直接从服务器IP发出的，计算迁移不会改变地理位置、IP类型或会话历史。服务器可以迁移，但对于网站，您仍然是同一个客户。
- 数据和队列——带有复制。解析结果和任务状态复制到另一个存储，否则在事故后将不得不重新开始。
- 备用提供商——确实不同。备用主机或代理提供商不应是同一基础设施下的不同品牌。我们在材料中探讨了如何检查代理 为什么备用代理提供商可能是同一池。
- 演练警报。每季度在备用场地启动解析器并运行实际任务。未曾运行过的计划在实践中通常不起作用。
在这种情况下，哪种类型的代理解决了什么问题
代理无法拯救您免受糟糕指纹的影响——这在Cloudflare的分析示例中显而易见。然而，它们将您的请求的“面孔”与代码物理运行的位置分开：
- 住宅代理——用于那些主机ASN被提前切断或需要验证码的网站。在迁移服务器时，出口仍然位于所需国家的家庭IP上。
- 数据中心代理——用于API和忠诚网站，速度和价格至关重要。它们也应该保存在独立于您的云提供商的地方，以便主机故障不会带走出口IP。
同时，代理只是一个层次。如果您的TLS栈、头部和客户端行为显著不同，它们将在任何IP上被识别，就像识别出迁移到Radist和Selectel的机器人一样。
这对网站所有者意味着什么
Cloudflare得出了相反的结论：ASN和流量量不是可靠的机器人标志。阻止“坏”网络在第一次迁移后就失效。更可靠的是观察行为：不同网络的JA4指纹、异常请求频率以及无论请求来自何处的敏感端点的WAF规则。反面也存在：40.5%的Cloudflare客户对Yandex爬虫返回了403代码，而在事故期间，来自Yandex网络的流量对新闻网站下降了44%——这意味着合法索引首先受到了影响。
结论
Yandex的事故成为了对两个简单真理的生动检验。第一：基础设施可能在一天内消失，而能够在数小时内迁移它的人将获得胜利——代码在云外、第二个主机和不依赖于服务器的输出层。第二：对于反机器人系统来说，您是您的客户端栈，而不是您的IP。新的数据中心与相同的JA4和相同的User-Agent——在新地址上的同一机器人。构建解析时，确保它能够经历场地的更换，同时在任何IP上看起来都同样整洁。