Já se sabe o que causou a queda global do Cloudflare ontem, e não foi um ataque cibernético.

Matthew Prince, cofundador e CEO da Cloudflare, publicou um post no blog para detalhar o que levou ao apagão global de 18 de novembro. O relato deixa claro como uma falha aparentemente minúscula pode escalar rapidamente e causar impactos enormes.

A instabilidade durou várias horas. X, ChatGPT, Spotify, Downdetector… milhares de sites ficaram fora do ar, exibindo o erro 500 - o código clássico que indica que o servidor não conseguiu processar a solicitação.

Pouco depois do início do problema, a Cloudflare reconheceu que a origem estava na própria empresa. E a gigante norte-americana, peça central da infraestrutura da Web moderna, levou um tempo até identificar o que havia derrubado um dos maiores redes do planeta. Agora, o motivo foi finalmente esclarecido e, apesar das suspeitas iniciais, não se tratou de um ataque cibernético. “O incidente não foi causado, direta ou indiretamente, por qualquer atividade maliciosa de qualquer natureza”, reforçou o CEO.

Cloudflare: um pequeno erro que virou um problema gigantesco

Afinal, o que colocou cerca de 20% da Web de joelhos? A falha veio de um arquivo usado pelo módulo de gerenciamento de bots da Cloudflare, atualizado a cada poucos minutos para ajudar a separar tráfego humano de tráfego automatizado.

Na prática, uma alteração de permissões no banco de dados interno desencadeou um efeito dominó inesperado. O sistema passou a enviar o dobro de dados em relação ao normal, o que fez o arquivo dobrar de tamanho. O ponto crítico é que esse módulo - embutido no proxy principal da Cloudflare, responsável por processar todo o tráfego - tem um limite fixo para o tamanho do arquivo que consegue carregar em memória. Quando o arquivo ultrapassou esse limite de forma repentina, o proxy disparou um erro interno e começou a devolver erros 500 em todos os pontos que dependiam do módulo de gerenciamento de bots.

O arquivo era regenerado a cada cinco minutos. Dependendo do nó de banco de dados utilizado, ele saía correto ou corrompido, o que explicava o comportamento “vai e volta”: sites caíam e depois retornavam. Para normalizar a situação, a Cloudflare precisou interromper imediatamente a distribuição do arquivo defeituoso e reinjetar uma versão íntegra. Às 18h06 (horário de Paris), todos os serviços já estavam estabilizados.

O risco de uma Web concentrada em poucos provedores

O episódio é mais uma evidência de que depender de um pequeno número de atores para sustentar a infraestrutura global da Web aumenta significativamente a exposição a riscos. As grandes quedas de Amazon Web Services (AWS), Azure e, agora, Cloudflare mostram como a concentração pode transformar um problema interno em uma interrupção com alcance mundial.

Além disso, o caso reforça a importância de práticas como limites mais flexíveis (ou mecanismos de degradação controlada), validações mais rigorosas na cadeia de geração e distribuição de arquivos e estratégias de redundância que reduzam o impacto de componentes críticos dentro do proxy principal. Para empresas e serviços que rodam por trás de CDNs e provedores de segurança, vale também revisar planos de contingência e arquitetura multi-fornecedor, sempre que viável, para diminuir a dependência de um único ponto de falha.