Acidente no Yandex Cloud: bots migraram para outros provedores em 24 horas. O que isso significa para o scraping?

De 8 a 11 de outubro de 2026, o Yandex perdeu três data centers: Sasovo e Vladimir pararam completamente, enquanto Kaluga operou com degradação. O Yandex Cloud entrou em modo de emergência e aconselhou diretamente os clientes a ativar seus próprios planos de recuperação de desastres. O mais interessante aconteceu depois. O Cloudflare analisou o que aconteceu com os bots que estavam nessa nuvem e viu que eles não desapareceram, mas mudaram para outros provedores em um dia. E permaneceram reconhecíveis pelo mesmo fingerprint TLS JA4. Para todos que trabalham com scraping e automação, isso é um experimento raro em dois aspectos: o que fazer quando a infraestrutura falha e por que a mudança de IP e hospedagem não altera a "identidade" do bot.

O que aconteceu com o Yandex

De acordo com o BleepingComputer, o Yandex relatou danos a três data centers devido a ataques de drones. O próprio Yandex não nomeou o culpado; a mídia, citando a BBC, relaciona os ataques à Ucrânia. A cronologia é a seguinte:

• 8 de outubro — Sasovo (região de Riazan): incêndio, local totalmente parado;
• 9 de outubro — Kaluga: operação com degradação, não parada total;
• 11 de outubro — Vladimir: parado completamente.

Na página de status do Yandex Cloud, parte dos serviços (console, API, IAM, bancos de dados, S3, Kubernetes) permaneceu acessível com problemas de desempenho, enquanto Compute e AI Studio operaram parcialmente. A empresa informou que não podia fornecer prazos confiáveis para a recuperação, considerava a configuração restante dos recursos instável e recomendava que os clientes utilizassem planos alternativos de recuperação de desastres. Não havia prazos de recuperação ou clareza sobre a possível perda de dados no momento da publicação do BleepingComputer (12 de outubro).

O que o Cloudflare viu: o tráfego caiu, mas os bots não

Em 14 de outubro, o Cloudflare publicou uma análise do incidente do lado de sua rede. Números-chave:

• Em 11 de outubro, o tráfego da rede de Pesquisa do Yandex (AS13238) caiu 99% em relação à normalidade, enquanto o Yandex.Cloud (AS200350) caiu 90%;
• 99,5% das solicitações de AS13238 antes do incidente eram automáticas, e 93,6% das solicitações de bots eram crawlers verificados do Yandex. Essa rede representava cerca de 7% de todas as solicitações de bots de IPs russos;
• No Yandex.Cloud, cerca de 95% das solicitações avaliadas eram de bots, e nenhuma delas era verificada. Isso representa cerca de 2% do tráfego de bots russos;
• O tráfego de bots do Yandex.Cloud caiu cerca de 40%, enquanto a varredura de plugins do WordPress dessa rede caiu 90%.

E então vem o principal. Quase todas as solicitações de bots do Yandex.Cloud foram direcionadas a uma conta de cliente do Cloudflare no setor de jogos de azar. Imediatamente após a falha em 8 de outubro, as solicitações do Yandex.Cloud para essa conta caíram a zero — e logo apareceram solicitações idênticas de redes de outros provedores russos, Radist e Selectel. Com o mesmo fingerprint JA4 TLS, os mesmos caminhos e cabeçalhos raros e as mesmas strings de User-Agent não padrão. O resultado da semana: o tráfego de bots russos para contas de jogos de azar não caiu, mas aumentou — de 167,7 para 170,1 milhões de solicitações (+1,4%).

A conclusão do Cloudflare foi contundente: a infraestrutura física é estática, enquanto a automação maliciosa é construída para se mudar. A queda no volume de tráfego HTTP indica um incidente, mas não significa que os bots pararam.

Versão barulhenta e dados: por que "os bots ficaram em silêncio" foi um exagero

Paralelamente, o Centro Ucraniano de Combate à Desinformação (CPD) afirmou que, após o ataque a Sasovo, o número de mensagens de contas suspeitas no Facebook e Telegram caiu 83,6% em um dia — de 4.032 para 660. Mas, como analisou o TechRadar, já em 10 de outubro a atividade voltou a 4.585 mensagens, e em 11 de outubro superou o nível anterior ao ataque. O Cloudflare não encontrou um desvio significativo: o tráfego de bots de IPs russos para endpoints de "postagem, resposta, curtida" de uma rede social caiu apenas 5,7%. A Graphika também não viu perda de contas ativas nas comunidades monitoradas. A pesquisadora Renée DiResta, no Lawfare, chamou a história de bonita, mas mais parecida com ficção do que com fato.

Uma lição separada para os analistas: em 8 de outubro, bancos, varejo, operadores e meios de comunicação em toda a Rússia falharam, portanto, qualquer queda na "atividade" nesse dia não pode ser atribuída aos bots sem ressalvas. O tráfego agregado pode facilmente levar a enganos.

Lição um: IP e hospedagem não são a identidade do bot

A conexão "Yandex.Cloud → Radist/Selectel" foi reconhecida pelo Cloudflare não pelos endereços — os endereços e ASN mudaram completamente. Foi reconhecida pelo comportamento e pelo fingerprint do cliente:

• JA4 — hash do TLS ClientHello: conjunto de cifras, extensões, versões do protocolo. Ele descreve o programa, não a rede. O mesmo script Python em um novo servidor gera o mesmo JA4;
• caminhos e cabeçalhos raros — a ordem e o conjunto de cabeçalhos HTTP que não aparecem em navegadores comuns;
• User-Agent próprio — uma string única que serve como etiqueta.

A conclusão prática para scraping legal: mudar de data center ou pool de IP não faz de você "novo" para um anti-bot, se todo o stack do cliente permanecer o mesmo. E vice-versa: se seu crawler se apresenta honestamente, se comporta de maneira cuidadosa e não ataca endpoints sensíveis, um fingerprint estável não é um problema. O problema surge quando o stack parece algo que não existe entre usuários reais: um Chrome declarado com um fingerprint TLS da biblioteca requests, um UA exótico, cabeçalhos não padrão. Detalhes sobre como esse nível de detecção funciona foram discutidos na análise JA4 e TLS fingerprinting em scraping.

Note mais um detalhe: os bots mudaram de um data center para outros data centers. Para o Cloudflare, ainda é a mesma categoria de ASN de hospedagem, que muitos sites já têm desconfiança elevada. A rede é diferente — o perfil de risco é o mesmo.

Lição dois: a infraestrutura deve ser capaz de ser transferida em horas

Os criminosos mudaram em um dia porque sua automação era originalmente portátil. Equipes honestas que coletam preços, monitoram resultados ou fazem análises precisam dessa portabilidade tanto quanto. A recomendação do Yandex Cloud de "usar planos alternativos de recuperação de desastres" é boa apenas quando tal plano já existe. Uma lista mínima de verificação:

1. Código e configurações — fora da nuvem. Repositórios, imagens de contêineres, variáveis de ambiente devem estar organizados de forma que o parser possa ser implantado em outro provedor com um único comando.
2. Segundo provedor previamente. Conta, pagamento e servidor de teste com um provedor alternativo em outra jurisdição e região. Registrar-se e passar pela verificação no dia do incidente é tarde demais.
3. Camada de saída separada dos cálculos. Se as solicitações para sites-alvo vão através de um provedor de proxy, e não diretamente do IP do servidor, a mudança de cálculos não altera a geolocalização, o tipo de IP ou o histórico de sessões. O servidor pode ser transferido, mas para o site você continua sendo o mesmo cliente.
4. Dados e filas — com replicação. Os resultados do scraping e o estado das tarefas são copiados para outro armazenamento, caso contrário, após um incidente, você terá que começar o processo novamente.
5. Provedor de backup — realmente diferente. O backup de hospedagem ou provedor de proxy não deve ser a mesma infraestrutura sob uma marca diferente. Como verificar isso em proxies, discutimos no material sobre por que um provedor de proxy de backup pode ser o mesmo pool.
6. Alarme de treinamento. Uma vez por trimestre, levante o parser em um site de backup e execute uma tarefa real. Um plano que nunca foi testado geralmente não funciona na prática.

Que tipo de proxy resolve o que em tal situação

Proxies não salvam de um fingerprint ruim — isso é evidente no exemplo da análise do Cloudflare. No entanto, eles desvinculam a "identidade" de suas solicitações do local onde o código está fisicamente rodando:

• Proxies residenciais — para sites onde ASN de hospedagem são cortados previamente ou recebem CAPTCHA. Ao mudar de servidor, a saída permanece em IPs domésticos do país desejado.
• Proxies de data center — para APIs e sites leais, onde a velocidade e o preço são importantes. Eles também devem ser mantidos com um provedor independente de sua nuvem, para que um incidente de hospedagem não leve também os IPs de saída.

Entretanto, proxies são apenas uma camada. Se o stack TLS, cabeçalhos e comportamento do seu cliente se destacam, eles serão reconhecidos em qualquer IP, assim como reconheceram os bots que mudaram para Radist e Selectel.

O que isso significa para os proprietários de sites

O Cloudflare faz uma conclusão oposta: ASN e volume de tráfego são sinais pouco confiáveis de bots. O bloqueio de uma "rede ruim" funciona até o primeiro movimento. É mais confiável observar o comportamento: fingerprints JA4 comuns entre diferentes redes, frequência anômala de solicitações e regras WAF em endpoints sensíveis, independentemente de onde a solicitação veio. O lado oposto também existe: 40,5% dos clientes do Cloudflare responderam ao crawler do Yandex com código 403, e o tráfego das redes do Yandex para sites de notícias caiu 44% durante o incidente — ou seja, a indexação legítima foi a mais afetada.

Conclusão

O incidente do Yandex se tornou uma verificação viva de duas verdades simples. A primeira: a infraestrutura pode desaparecer em um dia, e vence quem consegue transferi-la em horas — com código fora da nuvem, um segundo provedor e uma camada de saída não vinculada ao servidor. A segunda: para um anti-bot, você é seu stack de cliente, e não seu IP. Um novo data center com o mesmo JA4 e o mesmo User-Agent é o mesmo bot em um novo endereço. Construa seu scraping de forma que ele sobreviva a mudanças de plataforma e ainda pareça igualmente cuidadoso em qualquer IP.