Falha global de rede da Cloudflare

• Houve degradação no desempenho de serviços internos na rede global da Cloudflare, afetando vários serviços de forma intermitente
• Serviços principais como Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers sofreram instabilidades temporárias
• A equipe de engenharia identificou o problema e realizou o trabalho de correção, e os serviços WARP e Access foram os primeiros a ser restaurados
• Depois disso, as taxas globais de erro e a latência voltaram gradualmente aos níveis normais, e o serviço de dashboard também foi restaurado
• No momento, todos os serviços estão operando normalmente, e o incidente foi totalmente resolvido

---

Visão geral do incidente

• A Cloudflare sofreu uma degradação de serviço interno (Internal Service Degradation), com interrupções intermitentes em alguns serviços
  • Os serviços afetados incluíram Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers
  • A empresa iniciou imediatamente o trabalho de recuperação e continuou atualizando o andamento da resolução

Identificação do problema e resposta inicial

• A Cloudflare confirmou a degradação dos serviços internos na fase de investigação (Investigating)
  • Alguns clientes tiveram erros intermitentes e lentidão
  • A equipe de engenharia trabalhou em paralelo na análise da causa e na recuperação
• Depois, identificou a causa do problema (Identified) e iniciou a correção
  • Durante a correção, o acesso ao WARP na região de Londres foi temporariamente desativado, e os usuários dessa região enfrentaram falhas de conexão com a internet

Progresso da recuperação dos serviços

• Após a correção, os serviços Access e WARP foram restaurados primeiro, fazendo a taxa de erros voltar aos níveis anteriores ao incidente
  • O acesso ao WARP na região de Londres foi reativado
• Em seguida, foi dado continuidade ao trabalho de restauração dos serviços para clientes de Application Services
  • As mudanças para restaurar o serviço de dashboard foram implantadas
  • Alguns clientes ainda enfrentaram problemas para fazer login ou usar o dashboard, mas isso foi resolvido com correções adicionais

Estabilização de toda a rede

• Globalmente, as taxas de erro e a latência (latency) diminuíram gradualmente e voltaram aos níveis normais
  • Os cálculos de pontuação do Bot Management (bot scores) foram afetados temporariamente, mas se normalizaram durante a recuperação
  • A equipe de engenharia removeu os erros restantes e acelerou a recuperação de toda a rede
• Depois disso, todos os serviços passaram a funcionar normalmente, e as taxas de erro e a latência foram totalmente normalizadas

Encerramento do incidente e medidas posteriores

• A Cloudflare confirmou que todos os serviços estão operando normalmente e encerrou o incidente
  • No momento, não há mudanças adicionais de configuração, e a plataforma está sendo monitorada de perto
  • Está em andamento uma investigação pós-incidente (post-incident investigation) sobre a causa da falha, e os resultados serão divulgados depois
• Esta falha foi registrada como um incidente que afetou toda a rede global

[GN⁺]

Opiniões no Hacker News

• Alguém com um token de API da Cloudflare compartilhou um comando para desativar o proxy da CF
  Dá para usar curl para buscar o zone ID e os registros DNS e depois fazer uma requisição PATCH definindo "proxied": false
  Mas é preciso cuidado com perda de certificado SSL, queda de segurança/desempenho e risco de exposição do IP do backend

  • Se você só tiver a antiga Global API Key, pode usar os headers X-Auth-Email e X-Auth-Key
    E quem configurou o acesso para permitir apenas tráfego da Cloudflare precisa desativar essa regra temporariamente
  • Pensei que deveria usar esse método da próxima vez, mas como eu não tinha criado um token de API antes, só pude esperar
    Felizmente agora tudo voltou a ficar online
  • Resolvi isso com o provider do Terraform, mas esse método é útil para quem não consegue acessar o dashboard
  • Boa dica. Só para constar, no curl a requisição GET é o padrão, então -X GET não é necessário
    Se usar a opção -d, vira POST automaticamente, e para PATCH o correto é -X PATCH
  • Ao ativar o Cloudflare WARP, alguns sites voltam a funcionar. O 1.1.1.1 provavelmente tem efeito parecido
    Mesmo assim, depois do túnel, alguns sites ainda continuam parcialmente fora do ar

• Segundo o CTO da Cloudflare, um bug potencial no sistema de bloqueio de bots saiu de controle após uma mudança de configuração e causou uma falha em toda a rede
  Ele explicou na fonte que não foi um ataque, e sim um problema interno

  • É surpreendente que grandes empresas ainda não façam rollout gradual de mudanças de configuração
    Código e configuração são ambos dados, e o padrão de lançar tudo globalmente de uma vez e causar uma grande indisponibilidade continua se repetindo
  • Seria bom se essa informação essencial estivesse no topo dos comentários. Foi difícil achar isso no meio das especulações sobre ataque cibernético
  • Uma única mudança de configuração derrubou as ações da CF em 4%. Fico curioso sobre o impacto econômico desse tipo de indisponibilidade em toda a indústria

• Um colega correu até mim de repente dizendo que, logo depois de mudar uma configuração na Cloudflare, o site caiu e ele entrou em pânico achando que tinha quebrado tudo
  Disse que ficou aliviado ao ver este post

  • Brinquei: “É pior do que isso, foi você que derrubou a Cloudflare inteira”
  • Mas será que não foi mesmo? Já houve o grande incidente da Fastly, então a suspeita continua
  • Fiquei pensando se existe uma palavra exata para essa estranha sensação de alívio ao descobrir que não foi alguém cometendo um erro
  • Vai que esse colega é funcionário da Cloudflare
  • Eu também recebi dezenas de mensagens de clientes dizendo que o site não funcionava, e como eu tinha mudado uma configuração ontem, comecei a suar frio
    Quando vi a mensagem “Cloudflare down”, senti um alívio genuíno

• Verifiquei da Holanda e quase todos os serviços estavam fora do ar
  O dashboard da Cloudflare também estava inacessível, assim como o dashboard da Betterstack
  Ironicamente, a página de status estava no ar, então a situação era de não conseguir avisar os clientes

  • Tive a mesma experiência. O motivo de só o HN estar normal é que ele não usa Cloudflare
    Escrevi um post no blog dizendo: “se não precisa, não coloque atrás da Cloudflare”
  • Todo ano a gente relembra como é arriscado depender demais da AWS ou da Cloudflare, mas não é fácil substituir
    Ainda assim, quando acontece uma pane desse porte, os clientes às vezes mostram uma compreensão inesperada
  • O dashboard da Cloudflare não morreu completamente; se insistir bastante, dá para desligar o proxy
    Levou alguns minutos, mas consegui desvincular o hcker.news da CF
  • Vendo uma situação dessas, parece haver oportunidade de negócio para um serviço que hospede páginas de status em VPS local
  • No meu side project Total Real Returns,
    coloquei embaixo um widget de uptime em tempo real ligado a uma página de status externa
    Dá para usar como referência o SVG de status e a página de status externa

• Quando a Cloudflare ou a AWS param, há um certo prazer em ver meus serviços self-hosted funcionando perfeitamente
  Neste momento, eu estou mais estável do que os 99,999% de disponibilidade deles

  • Até meu site pessoal meio capenga sobreviveu a falhas da AWS, Azure e Cloudflare
    Agora estou pensando em instalar um rastreador de uptime
  • Meu site self-hosted acabou caindo justamente por causa do proxy da Cloudflare. Que frustração
  • Empresas tradicionais estão vendo sistemas como Oracle e SAP seguirem normais, enquanto apenas os novos serviços baseados em nuvem param
    É uma lição que startups SaaS deveriam aprender
  • Muita gente pergunta como lidar com DNS. Eu também hospedo num Raspberry Pi, e tinha acabado de migrar o DNS para a Cloudflare
    É engraçado, mas também estranhamente satisfatório, que meu site pequeno tenha saído do ar

• Ultimamente parece que as grandes falhas de infraestrutura aumentaram muito. Tanto AWS quanto Cloudflare estão bem abaixo do SLA

  • Isso coincide com o momento em que grandes empresas fizeram demissões em massa e falaram em substituir por IA
  • Esse tipo de incidente mostra como a quantidade de “noves” no SLA não significa muita coisa
    Não é uptime real, e sim um número definido arbitrariamente pela empresa
  • Tem gente que chama isso de “vibe code theory”. É uma teoria meio em tom de piada de que, quanto mais código feito no feeling, mais bugs e panes aparecem
  • Há também a análise de que a cultura de deploy apressado vem da combinação entre a proibição de deploy no fim do ano e a pressão por metas do Q4
  • Ou, numa visão mais conspiratória, poderia até ser um ataque cibernético em nível estatal

• Quando a Cloudflare ou a AWS param, metade da web para; o problema da centralização é sério

  • Os usuários também não ligam tanto. Como a percepção é de que “a internet caiu”, cada serviço individual consegue escapar da responsabilidade
    Esse é um dos motivos de a estrutura não mudar
  • Na defesa contra DDoS, há economia de escala. Quanto mais clientes, maior a banda e mais forte a defesa
    CDNs pequenas têm dificuldade para competir, e no fim se forma uma estrutura de monopólio natural
    O plano gratuito da Cloudflare fazia parte dessa estratégia para explorar esse efeito de rede
  • Mais preocupante do que um ponto único de falha é que essa centralização pode distorcer os padrões da web e o futuro da hospedagem autônoma
    Além disso, pode virar um alvo concentrado para censura governamental
  • A Let's Encrypt também representa um risco potencial.
    Dois terços da web dependem dela, a duração dos certificados está cada vez menor e, se houver um hack ou indisponibilidade, a web inteira pode travar
    Hoje é uma organização bem-intencionada, mas não dá para esquecer que o Google do passado também parecia assim
  • Depois da febre da AWS, os desenvolvedores passaram a depender só da nuvem em vez de servidores dedicados
    Há muitos backups no nível de software, mas o bom senso de multi-hosting no nível da infraestrutura foi se perdendo

• Ironicamente, o DownDetector também usa Cloudflare Turnstile e caiu junto

  • Também houve um aumento enorme de relatos de falha na AWS, mas isso provavelmente é falso positivo
  • Eu também vi esse comportamento

• A mensagem visual de desculpas da Cloudflare — “Your browser: Working / Host: Working / Cloudflare: Error” — chamou atenção

  • Foi a primeira vez que vi essa tela. No meu caso, porém, o “Host” era Cloudflare Pages, então o sentido ficou meio ambíguo
  • É até engraçado que, ao clicar em “Cloudflare”, ele ainda diga que o problema é do servidor do cliente
  • Gostei da honestidade da mensagem, mas os usuários só reagiam com “arruma o wi-fi”
  • Ainda assim, dava para entender claramente a situação e agir. Se necessário, era possível desativar o proxy para minimizar o impacto no serviço
  • Eu também passei uma hora vasculhando logs até perceber que o problema não era no meu servidor

• Sites que usam o Cloudflare Challenge (“I’m not a robot”) também pararam com erro HTTP 500
  Aparecia a mensagem para “desbloquear challenges.cloudflare.com”

  • Hoje em dia o nível de tratamento de erros está muito baixo. As empresas fogem da responsabilidade e culpam o usuário,
    ou mostram uma tela de carregamento infinito. Na prática, o backend retorna um erro claro, mas o frontend esconde isso
    Recentemente até vi um caso em que o erro de senha longa demais era mostrado como “este e-mail já está em uso”
  • Com essa falha, a busca com IA do chat.bing.com (GPT5) também parou
    Ironicamente, acabou virando uma situação em que a IA exige que você prove que é humano
  • Alguns sites, como o pinkbike, mostravam a mensagem “you have been blocked”
  • Ou seja, não só robôs, mas pessoas de verdade também estavam sendo bloqueadas /s
  • O frontend parece presumir que o usuário bloqueou o domínio no DNS ou por extensão
    É engraçada essa negação em tom de /s de que o Captcha da Cloudflare jamais poderia cair