CLOUDFLARE

Desligar a escolha automática não desfaz a restrição de algoritmos. A mudança exige revisar o que scripts e procedimentos de recuperação realmente controlam.

A Cloudflare informou que, entre 01h06 e 01h54 UTC de 23 de agosto, alguns clientes podem ter enfrentado mais respostas 5xx e timeouts no tráfego entre origens na América do Norte e seu data center de Singapura. O incidente foi encerrado, mas a descrição pública específica apareceu depois do fim do intervalo de impacto.

A Cloudflare levou 8 minutos e 36 segundos para anunciar uma correção para um problema de desempenho de rede na Ásia-Pacífico. O aviso continuou em monitoramento e não informou local, produto ou sintoma, deixando para cada cliente a tarefa de separar a resposta da borda, o caminho de rede e o comportamento da origem.

Dois incidentes de Workers encerrados em 4 de agosto atingiram pontos diferentes da operação. Um objeto global `Temporal`, exposto sem intenção, informava 1970 sem gerar erro. Em outro caso, uma asserção bloqueava a implantação com `nodejs_compat` e data de compatibilidade a partir de 4 de agosto. A Cloudflare não disse que havia uma causa comum. O que os une é a necessidade de testar o contrato completo da plataforma: a configuração aceita antes do deploy e o comportamento entregue depois dele.

Cloudflare encerrou em 3 de agosto um incidente de aproximadamente uma hora e 51 minutos no Workers Builds. A cronologia mostra por que a continuidade de um serviço não pode ser medida apenas pela versão que já está no ar: às 15h38 UTC, os builds haviam parado de falhar, mas os usuários ainda podiam enfrentar atrasos. Nesse intervalo, uma aplicação poderia continuar respondendo enquanto sua equipe permanecia sem uma via previsível para publicar a próxima correção. O registro não informa causa, quantidade de clientes nem impacto no runtime, por isso a análise deve permanecer no componente de build indicado.

A Cloudflare resolveu uma ocorrência de Gateway em que clientes com IPv4 de saída dedicada vinculada a Londres podiam ficar sem acesso à internet pública. A janela pública durou 2 horas, 17 minutos e 50 segundos, incluindo quase 13 minutos de monitoramento depois da aplicação da correção. O aviso não quantificou a população atingida nem revelou a causa. Para equipes de continuidade, a lição não é tratar o episódio como pane londrina geral, mas reconhecer que um caminho alternativo só funciona quando preserva também a identidade de origem aceita pelos destinos.

Em 27 de junho de 2024, dois eventos de roteamento distintos afetaram a alcançabilidade do resolvedor público 1.1.1.1 da Cloudflare. Um anúncio indevido do prefixo específico 1.1.1.1/32 e um vazamento separado do prefixo 1.1.1.0/24 expuseram limites diferentes de filtragem, validação de origem, controle de exportação e blackholing remoto. O episódio mostra por que registros de alocação e ROAs são evidências importantes, mas não substituem políticas executadas nos roteadores nem determinam, sozinhos, quem podia impedir, detectar, conter e retirar uma rota problemática.

A ocorrência de 22 de janeiro de 2026 mostra por que uma alteração pequena e sintaticamente válida não basta para demonstrar a segurança de uma política BGP: é preciso provar, em cada camada, quais rotas o roteador passou a aceitar para exportação, para quais vizinhos e sob quais relações operacionais.

O incidente de 20 de fevereiro expôs um problema fundamental da infraestrutura de rede: documentos de autoridade sobre endereços IP não bastam quando registros de serviço, intenção de anúncio BGP, configuração efetivamente implantada e observação externa deixam de representar o mesmo estado.

A campanha de março de 2013 mostrou como recursão DNS exposta, falsificação de endereços de origem e caminhos compartilhados de interconexão podem converter falhas locais aparentemente pequenas em um custo externo de grande escala. Responsabilizar exige identificar quem controlava cada etapa executável, o que foi observado em cada ponto da rede e se o reparo foi comprovado.

A Cloudflare registrou às 11:51:07 UTC de 31 de julho um incidente menor que começou em Analytics, Dashboard e APIs relacionadas e depois alcançou builds de Pages e Workers. Uma correção entrou em monitoramento às 12:43:57, e o caso foi encerrado às 13:01:59. Segundo a empresa, a entrega de arquivos em cache pelo CDN e outras funções de segurança na borda não foram afetadas. O episódio separou a disponibilidade pública de um site da capacidade de observá-lo, configurá-lo e publicar alterações.