Cloudflare's Major 18 de novembro - Um resumo

Em 18 de novembro de 2025, uma grande fatia da internet caiu.
Se abrisse o ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase, ou inúmeros sites mais pequenos, era recebido com uma página de erro 5xx da Cloudflare - ou os sites simplesmente não carregavam. O que a princípio parecia ser mais um grande momento de "a internet está quebrada" acabou sendo algo mais sutil e, de certa forma, mais preocupante: um bug auto-infligido dentro da própria infraestrutura da Cloudflare.

Abaixo está um resumo detalhado do que aconteceu na interrupção da Cloudflare de ontem (18 de novembro de 2025), porque aconteceu, quem foi afetado e que lições as equipas de infraestrutura devem tirar dela.

O que realmente aconteceu ontem?

Na terça-feira, 18 de novembro de 2025, por volta do final da manhã UTC, a Cloudflare começou a retornar grandes volumes de erros de servidor HTTP 5xx para o tráfego que passava por sua rede. Para os usuários finais, isso significava páginas de "Erro interno do servidor" ou "Erro de gateway" ao tentar acessar muitos sites e aplicativos populares.

De acordo com o blogue pós-incidente da Cloudflare, a interrupção:

• Começou a afetar o tráfego HTTP dos clientes às 11:28 UTC

• Foram observados erros 5xx generalizados nos principais serviços de CDN e segurança

• Tomou medidas importantes de mitigação por volta das 13:05-14:30 UTC

• O volume de erros 5xx voltou à linha de base às 17:06 UTC Blogue da Cloudflare

A própria Cloudflare descreveu-a como a sua pior interrupção desde 2019, porque não afetou apenas uma funcionalidade ou painel - interrompeu a camada de proxy central que encaminha a maior parte do tráfego dos clientes através da sua rede. Blogue da Cloudflare

O monitoramento de terceiros confirmou isso. A Cisco ThousandEyes observou uma interrupção global que afectou a Cloudflare, com timeouts e erros 5xx em serviços como o X, OpenAI (ChatGPT) e Anthropic, enquanto os caminhos da rede pareciam saudáveis. Isso apontava fortemente para uma falha no serviço de backend, e não para um problema de roteamento ou no nível do ISP. ThousandEyes

Quem foi afetado?

Uma vez que a Cloudflare se encontra à frente de uma grande parte da Internet (cerca de 20% dos sites da Web dependem da Cloudflare para desempenho e segurança), o raio da explosão foi enorme. AP News+1

Entre os serviços que foram afectados:

• ChatGPT / OpenAI

• X (antigo Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends e outras plataformas de jogos

• Vários sítios de transportes públicos e governamentais, incluindo o New Jersey Transit e os sistemas digitais dos caminhos-de-ferro franceses SNCF AP News+1

Os rastreadores de interrupções, como o Downdetector, registaram milhares de relatórios de problemas simultâneos no pico. A Reuters relatou cerca de 5.000 utilizadores afectados só para o X num determinado momento, antes de as contagens diminuírem à medida que as correcções eram lançadas. Reuters

Do ponto de vista do utilizador, isto manifestou-se da seguinte forma

• Sites que não carregam de todo

• Fluxos de login suspensos ou com falhas (especialmente quando o Cloudflare Access ou o Turnstile estavam envolvidos)

• APIs respondendo intermitentemente ou com erros 5xx

• Painéis de controlo e painéis de administração a falharem

Por outras palavras: grandes partes da Internet "sentiram-se em baixo", embora a causa principal estivesse concentrada nos sistemas internos de um único fornecedor.

Como o Cloudflare funciona normalmente (em termos simples)

Para compreender por que razão esta interrupção foi tão grave, é útil conhecer o percurso aproximado de um pedido através da rede do Cloudflare.

O Cloudflare atua como um CDN de proxy reverso e uma camada de segurança:

1. Seu navegador ou aplicativo se conecta ao Cloudflare em vez de diretamente ao site de origem.

2. A Cloudflare termina o TLS e o HTTP em sua borda.

3. As solicitações fluem para o sistema de proxy principal da Cloudflare, chamado FL ("Frontline") e sua geração mais recente, FL2.

4. Esse proxy central:

   • Aplica regras de WAF (web application firewall)

   • Executa modelos de gerenciamento de bots

   • Lida com proteção DDoS, cache, saída para a origem

   • Encaminha o tráfego para outros produtos internos como Workers, R2, Access, etc. Blogue da Cloudflare

Em funcionamento normal, esta arquitetura é altamente resistente: se um centro de dados tiver um problema, o tráfego é encaminhado através de outros; as alterações de configuração são implementadas cuidadosamente; as funcionalidades individuais devem falhar de forma contida.

A interrupção de ontem foi precisamente má porque a falha estava dentro do próprio caminho do proxy comum e estava intimamente ligada a um ficheiro de configuração que é enviado para todo o mundo frequente e automaticamente.

A causa principal: um ficheiro de funcionalidades de gestão de bots que se tornou desonesto

A explicação oficial da Cloudflare aponta para um culpado principal:
um ficheiro de configuração de funcionalidades utilizado pelo seu sistema de gestão de bots. Blogue da Cloudflare

Aqui está a cadeia de eventos em linguagem simples:

1. O Bot Management usa um "ficheiro de caraterísticas"

   • O modelo de deteção de bots da Cloudflare baseia-se num conjunto de "caraterísticas" - sinais sobre cada pedido usados para decidir se é humano ou um bot.

   • Estas caraterísticas são agrupadas num ficheiro de configuração que é regenerado a cada poucos minutos e implementado globalmente, para que a Cloudflare se possa adaptar rapidamente a novos padrões de ataque. Blogue da Cloudflare

2. Uma mudança no comportamento de consulta do ClickHouse

   • O ficheiro de caraterísticas é gerado por consultas a uma base de dados do ClickHouse.

   • A Cloudflare fez uma alteração por volta das 11:05 UTC para melhorar a segurança e as permissões para consultas distribuídas - permitindo que os utilizadores vejam metadados não apenas de um esquema predefinido, mas também de tabelas r0 subjacentes. Blogue do Cloudflare

   • A consulta que constrói a lista de recursos não filtrava por nome de banco de dados; de repente, começou a obter colunas duplicadas tanto do padrão quanto do r0, efetivamente dobrando o número de linhas de recursos.

3. O ficheiro de caraterísticas explodiu em tamanho

   • O módulo Bot Management tem um limite rígido para o número de caraterísticas que aceita (definido para 200, bem acima dos ~60 normalmente em uso).

   • Quando o arquivo recém-gerado excedeu esse limite, o módulo atingiu o limite e entrou em pânico, devido a um erro não tratado no código Rust que usou Result::unwrap() em um valor de erro. Blogue do Cloudflare

4. Os principais serviços de proxy começaram a retornar erros 5xx

   • Como o Bot Management está integrado ao caminho do proxy principal, o pânico apareceu como respostas HTTP 5xx para qualquer tráfego que dependesse desse módulo.

   • No novo motor FL2, os clientes viram erros 5xx explícitos.

   • No mecanismo FL mais antigo, as pontuações de bots foram silenciosamente para zero, o que poderia causar falsos positivos nas regras de bloqueio de bots. Blogue da Cloudflare

5. A parte realmente desagradável: o ficheiro continuava a alternar entre "bom" e "mau"

   • O cluster ClickHouse estava a ser gradualmente atualizado e o ficheiro de caraterísticas era regenerado a cada cinco minutos.

   • Por vezes, a consulta era executada em nós actualizados (produzindo um ficheiro mau), outras vezes em nós não actualizados (produzindo um ficheiro bom).

   • Isso significa que, durante algum tempo, a rede da Cloudflare oscilou entre o funcionamento normal e a falha, à medida que diferentes versões do ficheiro eram propagadas. Blogue da Cloudflare

Essa oscilação tornou a situação extremamente confusa internamente. Inicialmente, as equipas da Cloudflare suspeitaram de um ataque DDoS maciço porque o padrão de erro não se parecia com uma simples falha de software. Até a página de estado da Cloudflare, que está alojada fora da sua própria infraestrutura, apresentou brevemente erros - uma coincidência que alimentou ainda mais a suspeita de um ataque externo. O Blogue Cloudflare+1

Só quando perceberam que o fator comum era o ficheiro de caraterísticas do bot é que a situação se tornou clara.

Linha do tempo do incidente

Com base no postmortem da Cloudflare e em relatórios de terceiros, podemos montar uma linha do tempo aproximada para 18 de novembro de 2025: Blogue da Cloudflare+2ThousandEyes+2

• 11:05 UTC - Uma alteração no controle de acesso ao banco de dados é implantada no ClickHouse.

• 11:20-11:30 UTC - Versões ruins do arquivo de recurso de gerenciamento de bots começam a ser geradas e propagadas.

• 11:28 UTC - Primeiro impacto no cliente: erros HTTP 5xx elevados observados no tráfego do cliente.

• 11:30-11:32 UTC - Ferramentas externas de monitoramento e testes automatizados começam a detetar falhas intermitentes.

• 11:35 UTC - A Cloudflare abre uma chamada de incidente interno; a investigação começa.

• ~11:48 UTC - A Cloudflare publica uma atualização de status confirmando um incidente. Reenvio

• 11:30-13:05 UTC - As equipas concentram-se no que parece ser um comportamento degradado do Workers KV e investigam várias causas possíveis (incluindo cenários de ataque).

• 13:05 UTC - Mitigação chave: O Workers KV e o Cloudflare Access são deslocados para contornar o proxy principal; o impacto é reduzido. Blogue da Cloudflare

• 14:30 UTC - A causa raiz foi identificada; a geração e a propagação de arquivos de caraterísticas ruins foram interrompidas. Um arquivo de configuração conhecido como bom é inserido manualmente e o proxy principal é reiniciado. A maior parte do tráfego do núcleo volta ao normal. Blogue da Cloudflare

• 14:40-15:30 UTC - Problemas no painel e no login persistem enquanto o Turnstile e o acúmulo de tentativas de autenticação criam picos de carga secundários. Blog da Cloudflare

• 17:06 UTC - As taxas de erro retornam à linha de base; a Cloudflare declara que os sistemas estão totalmente normais. Blogue da Cloudflare

Do ponto de vista do utilizador, a interrupção foi pior entre o final da manhã e o início da tarde UTC, embora as janelas de impacto exactas variassem consoante a região e os produtos Cloudflare de que cada serviço dependia.

Por que essa interrupção é tão importante

Risco de centralização

A Cloudflare faz parte de um pequeno conjunto de fornecedores centrais de infra-estruturas de Internet, juntamente com as principais plataformas de nuvem (AWS, Azure, GCP) e outras grandes CDN. Quando um destes intervenientes falha, o impacto é grande e muitas vezes não é óbvio.

Esta falha:

• Não foi causada por um erro de encaminhamento BGP ou por um corte de cabo do ISP.

• Não resultou de um ataque malicioso (apesar das suspeitas iniciais).

• Foi causada por uma única configuração e um bug de limites num componente interno.

Isso é importante porque mostra como sistemas complexos e fortemente acoplados podem falhar catastroficamente, mesmo sem interferência externa. Quando muitas organizações se baseiam no mesmo fornecedor, esse fornecedor torna-se de facto uma peça sistemicamente importante da Internet.

As dependências "suaves" também são afectadas

Alguns dos serviços afectados não estavam apenas a utilizar o Cloudflare como um CDN burro. Estavam-no a fazer:

• Usavam o Cloudflare Access para autenticação e acesso de confiança zero.

• Utilizavam o Workers KV como parte dos planos de controlo interno.

• Confiar no Turnstile para logins resistentes a bots. O Blog+1da Cloudflare

Quando esses produtos falharam, não foi apenas o conteúdo do site que caiu - logins, funções de administração e APIs internas também falharam. Isso torna a recuperação mais complexa: sua página de status, ferramentas de incidentes ou interface de administração também podem depender do mesmo provedor que acabou de falhar.

O que a Cloudflare diz que vai mudar

O blogue da Cloudflare descreve várias medidas de correção que a empresa já está a tomar para reduzir o risco de algo semelhante voltar a acontecer: Blogue da Cloudflare

1. Reforçar a ingestão de ficheiros de configuração gerados automaticamente
   Tratar as configurações geradas internamente com o mesmo ceticismo e validação que a entrada fornecida pelo utilizador, incluindo a verificação rigorosa do esquema e do tamanho antes da implementação.

2. Mais kill switches globais
   Facilite a desativação rápida de módulos internos problemáticos (como o Bot Management) em toda a rede, para que eles falhem na abertura em vez de causar pânico em todo o caminho do proxy.

3. Proteger os recursos do sistema contra tempestades de erros
   Certifique-se de que os despejos do núcleo, os metadados de depuração e as ferramentas de observabilidade não possam sobrecarregar a CPU e a memória quando os erros começarem a aumentar.

4. Analise os modos de falha nos módulos principais do proxy
   Audite sistematicamente como cada módulo interno se comporta sob entradas ou configurações inesperadas e garanta uma degradação graciosa em vez de uma falha global.

5. Refinar as implementações e o isolamento
   Embora não tenha sido explicado em grande detalhe, o incidente sugere que a Cloudflare irá provavelmente segmentar ainda mais a forma como as novas configurações e comportamentos de BD se propagam, para reduzir a possibilidade de uma única alteração incorrecta afetar toda a frota.

Também enquadraram o incidente como uma falha absoluta das suas expectativas de resiliência, chamando-lhe "inaceitável" e reconhecendo explicitamente a dor que causou tanto aos clientes como aos utilizadores comuns da Internet. Blogue da Cloudflare

Lições para as equipas de infraestrutura e SRE

Mesmo que não esteja a gerir algo tão grande como a Cloudflare, existem algumas lições práticas de design e operacionais nesta interrupção:

Tratar a configuração interna como uma entrada não confiável

É fácil assumir que a "nossa própria" configuração gerada está sempre correta. O dia de ontem mostra porque é que isso é perigoso:

• Valide sempre o tamanho, a forma e os limites dos ficheiros de configuração antes de os aplicar.

• Considere a aplicação canária da configuração a um pequeno subconjunto de tráfego ou nós primeiro, com reversão automática em caso de anomalias.

• Mantenha limites superiores e disjuntores rigorosos em torno de contagens de recursos, pré-alocação de memória e uso de CPU.

Design para falhas parciais graciosas

Um bug no módulo Bot Management não deve ser capaz de colocar em pânico todo o caminho do proxy:

• Predefinição para falha-aberta vs falha-fechada em algumas camadas de segurança quando a alternativa é a interrupção completa.

• Construir kill switches claros e testados para funcionalidades não essenciais.

• Garantir que os subsistemas críticos (autenticação, página de estado, ferramentas de incidentes) possam funcionar em modo degradado ou através de rotas alternativas.

Observar os sinais corretos

A oscilação entre "boa configuração" e "má configuração" a cada cinco minutos fez com que o sinal parecesse um tráfego de ataque ou um comportamento externo ruidoso:

• Certifique-se de que tem correlação por versão ou por configuração no seu pipeline de observabilidade.

• Crie painéis que tornem as alterações de configuração visualmente óbvias em cima de gráficos de erros.

• Inclua testes sintéticos fortes de um ponto de vista externo, para que possa distinguir rapidamente a falha interna de problemas de rede/caminho.

Não coloque todos os seus ovos em uma única cesta de infraestrutura

Para organizações que usam o Cloudflare:

• Considere configurações de vários CDNs para propriedades realmente críticas.

• Evite tornar sua página de status totalmente dependente do mesmo provedor que sua pilha principal (o Cloudflare faz isso, mas houve um problema coincidente com o host da página de status ontem que confundiu ainda mais as coisas). Blogue do Cloudflare+1

• Pense duas vezes antes de acoplar fortemente a autenticação, os planos de controlo da API e a entrega do frontend ao mesmo fornecedor sem caminhos de recurso.

O panorama geral

Só nos últimos meses, assistimos a grandes interrupções no Microsoft Azure, Amazon Web Services e, agora, Cloudflare, que deixaram temporariamente offline grandes quantidades de serviços para consumidores e empresas. AP News+2TheWashington Post+2

O padrão é claro:

• A Internet está cada vez mais dependente de um punhado de gigantescos fornecedores de infra-estruturas.

• As interrupções são frequentemente auto-infligidas, resultando de alterações internas complexas e não de ataques externos.

• Mesmo os fornecedores com práticas de SRE de classe mundial podem ainda ser prejudicados por interações inesperadas entre a configuração, o comportamento da base de dados e os limites codificados.

O incidente de ontem da Cloudflare é um lembrete claro de que "a nuvem" não é mágica. No fundo, continua a ser um software escrito por humanos, sujeito às mesmas classes de erros que qualquer outra aplicação - só que com um número muito maior de pessoas a depender dele.

Para os utilizadores, o incidente será sobretudo recordado como "aquela manhã em que o X e o ChatGPT não carregavam".
Para os engenheiros, será provavelmente estudado como um exemplo de como erros de configuração subtis num sistema distribuído central podem transformar-se num evento global na Internet.