Авария Yandex Cloud: боты переехали к другим хостерам за сутки. Что это значит для парсинга

С 8 по 11 октября 2026 года Яндекс потерял три дата-центра: Сасово и Владимир остановились полностью, Калуга работала с деградацией. Yandex Cloud перешёл в аварийный режим и прямо посоветовал клиентам включать собственные планы аварийного восстановления. Самое интересное случилось потом. Cloudflare разобрал, что стало с ботами, которые жили в этом облаке, и увидел: они не исчезли, а за сутки переехали к другим хостерам. И остались узнаваемыми по тому же TLS-отпечатку JA4. Для всех, кто занимается парсингом и автоматизацией, это редкий натурный эксперимент сразу по двум вопросам: что делать, когда падает инфраструктура, и почему смена IP и хостинга не меняет «личность» бота.

Что произошло с Яндексом

По данным BleepingComputer, Яндекс сообщил о повреждении трёх дата-центров атаками беспилотников. Сам Яндекс виновника не называл; СМИ со ссылкой на BBC связывают удары с Украиной. Хронология такая:

• 8 октября — Сасово (Рязанская область): пожар, площадка остановлена полностью;
• 9 октября — Калуга: работа с деградацией, не полная остановка;
• 11 октября — Владимир: остановлен полностью.

На странице статуса Yandex Cloud часть сервисов (консоль, API, IAM, базы данных, S3, Kubernetes) оставалась доступной с проблемами производительности, Compute и AI Studio работали частично. Компания писала, что не может назвать надёжные сроки восстановления, считает оставшуюся конфигурацию ресурсов нестабильной и рекомендует клиентам использовать альтернативные планы аварийного восстановления. Сроков восстановления и ясности по возможной потере данных на момент публикации BleepingComputer (12 октября) не было.

Что увидел Cloudflare: трафик упал, боты — нет

14 октября Cloudflare опубликовал разбор аварии со стороны своей сети. Ключевые цифры:

• 11 октября трафик из сети Яндекс Поиска (AS13238) упал на 99% от нормы, из Yandex.Cloud (AS200350) — на 90%;
• 99,5% запросов из AS13238 и до аварии были автоматическими, причём 93,6% бот-запросов — это верифицированные краулеры Яндекса. Эта сеть давала около 7% всех бот-запросов из российских IP;
• в Yandex.Cloud около 95% оценённых запросов были ботами, и ни один из них не был верифицированным. Это около 2% российского бот-трафика;
• бот-трафик из Yandex.Cloud снизился примерно на 40%, сканирование WordPress-плагинов с этой сети — на 90%.

А дальше главное. Почти все бот-запросы из Yandex.Cloud были направлены на один аккаунт клиента Cloudflare из сферы азартных игр. Сразу после сбоя 8 октября запросы из Yandex.Cloud к нему упали до нуля — и тут же появились идентичные запросы из сетей других российских хостеров, Radist и Selectel. С тем же JA4-отпечатком TLS, теми же редкими путями и заголовками и теми же нестандартными строками User-Agent. Итог за неделю: российский бот-трафик к гемблинг-аккаунтам не упал, а вырос — с 167,7 до 170,1 млн запросов (+1,4%).

Вывод Cloudflare сформулирован жёстко: физическая инфраструктура статична, а вредоносная автоматизация построена так, чтобы переезжать. Падение объёма HTTP-трафика показывает аварию, но не означает, что боты остановились.

Громкая версия и данные: почему «боты замолчали» оказалось преувеличением

Параллельно украинский Центр противодействия дезинформации (ЦПД) заявил, что после удара по Сасово число сообщений подозрительных аккаунтов в Facebook и Telegram за день упало на 83,6% — с 4 032 до 660. Но, как разобрал TechRadar, уже 10 октября активность вернулась к 4 585 сообщениям, а 11 октября превысила уровень до удара. Cloudflare не нашёл заметного сдвига: бот-трафик из российских IP к эндпоинтам «пост, ответ, лайк» одной соцсети снизился лишь на 5,7%. Graphika тоже не увидела потери активных аккаунтов в отслеживаемых сообществах. Исследовательница Рене ДиРеста в Lawfare назвала историю красивой, но больше похожей на вымысел, чем на факт.

Отдельный урок для аналитиков: 8 октября по всей России сбоили банки, ритейл, операторы и СМИ, поэтому любое падение «активности» в этот день нельзя без оговорок списывать на ботов. Агрегированный трафик легко вводит в заблуждение.

Урок первый: IP и хостинг — не личность бота

Связку «Yandex.Cloud → Radist/Selectel» Cloudflare распознал не по адресам — адреса и ASN поменялись полностью. Распознал по поведению и отпечатку клиента:

• JA4 — хэш TLS ClientHello: набор шифров, расширений, версий протокола. Он описывает программу, а не сеть. Тот же Python-скрипт на новом сервере даёт тот же JA4;
• редкие пути и заголовки — порядок и набор HTTP-заголовков, которые не встречаются у обычных браузеров;
• собственный User-Agent — уникальная строка, которая сама по себе служит меткой.

Практический вывод для легального парсинга: смена дата-центра или пула IP не делает вас «новым» для антибота, если весь клиентский стек остаётся прежним. И наоборот: если ваш краулер честно представляется, ведёт себя аккуратно и не бьёт по чувствительным эндпоинтам, стабильный отпечаток — не проблема. Проблема возникает, когда стек выглядит как нечто, чего не бывает у реальных пользователей: заявленный Chrome с TLS-отпечатком библиотеки requests, экзотический UA, нестандартные заголовки. Подробно о том, как устроен этот слой детекта, мы писали в разборе JA4 и TLS-фингерпринтинга при скрапинге.

Заметьте ещё одну деталь: боты переехали из одного дата-центра в другие дата-центры. Для Cloudflare это всё та же категория хостинговых ASN, к которым у многих сайтов заранее повышенное недоверие. Сеть другая — профиль риска тот же.

Урок второй: инфраструктуру надо уметь перевезти за часы

Злоумышленники переехали за сутки, потому что их автоматизация изначально переносима. Честным командам, которые собирают цены, мониторят выдачу или ведут аналитику, такая переносимость нужна не меньше. Рекомендация Yandex Cloud «используйте альтернативные планы аварийного восстановления» хороша только тогда, когда такой план уже есть. Минимальный чек-лист:

1. Код и конфиги — вне облака. Репозиторий, образы контейнеров, переменные окружения должны лежать так, чтобы развернуть парсер у другого хостера можно было одной командой.
2. Второй хостер заранее. Аккаунт, оплата и тестовый сервер у альтернативного провайдера в другой юрисдикции и другом регионе. Регистрироваться и проходить проверку в день аварии — поздно.
3. Выходной слой отдельно от вычислений. Если запросы к целевым сайтам идут через прокси-провайдера, а не напрямую с IP сервера, переезд вычислений не меняет ни гео, ни тип IP, ни историю сессий. Сервер можно перенести, а для сайта вы остаётесь тем же клиентом.
4. Данные и очереди — с репликацией. Результаты парсинга и состояние задач копируются в другое хранилище, иначе после аварии придётся начинать обход заново.
5. Запасной провайдер — действительно другой. Резервный хостинг или прокси-провайдер не должен оказаться той же инфраструктурой под другим брендом. Как это проверить на прокси, мы разбирали в материале о том, почему запасной прокси-провайдер может оказаться тем же пулом.
6. Учебная тревога. Раз в квартал поднимайте парсер на запасной площадке и прогоняйте реальную задачу. План, который ни разу не запускали, на практике обычно не работает.

Какой тип прокси что решает в такой ситуации

Прокси не спасают от плохого отпечатка — это видно на примере из разбора Cloudflare. Зато они отвязывают «лицо» ваших запросов от того, где физически крутится код:

• Резидентные прокси — для сайтов, где хостинговые ASN режутся заранее или получают капчу. При переезде сервера выход остаётся на домашних IP нужной страны.
• Прокси дата-центров — для API и лояльных сайтов, где важна скорость и цена. Их тоже стоит держать у независимого от вашего облака провайдера, чтобы авария хостинга не забирала с собой и выходные IP.

При этом прокси — только один слой. Если TLS-стек, заголовки и поведение вашего клиента выделяются, их узнают на любом IP, как узнали ботов, переехавших к Radist и Selectel.

Что это значит для владельцев сайтов

Cloudflare делает и обратный вывод: ASN и объём трафика — ненадёжный признак бота. Блокировка «плохой» сети работает до первого переезда. Надёжнее смотреть на поведение: общие JA4-отпечатки у разных сетей, аномальную частоту запросов и правила WAF на чувствительных эндпоинтах вне зависимости от того, откуда пришёл запрос. Обратная сторона медали тоже есть: 40,5% клиентов Cloudflare отвечали краулеру Яндекса кодом 403, а трафик из сетей Яндекса к новостным сайтам за время аварии упал на 44% — то есть пострадала прежде всего легитимная индексация.

Вывод

Авария Яндекса стала живой проверкой двух простых истин. Первая: инфраструктура может исчезнуть за день, и выигрывает тот, кто умеет перевезти её за часы, — с кодом вне облака, вторым хостером и выходным слоем, не привязанным к серверу. Вторая: для антибота вы — это ваш клиентский стек, а не ваш IP. Новый дата-центр с тем же JA4 и тем же User-Agent — это тот же бот по новому адресу. Стройте парсинг так, чтобы он переживал смену площадки и при этом выглядел одинаково аккуратно на любом IP.