Cloudflare: o que é e o que o plano grátis entrega

Você trocou os nameservers do domínio, o painel listou os registros DNS com uma nuvem laranja ao lado de cada um e o site continuou no ar como antes. Parece que nada mudou depois de colocar o site na Cloudflare.

Mudou bastante. A partir dali, quem digita o endereço do site conversa primeiro com uma rede de terceiros, e só depois, se o pedido passar pelos filtros, com o seu servidor. A nuvem laranja liga esse desvio. A cinza desliga.

Muita gente para nesse ponto. O registro principal fica laranja, mas um subdomínio antigo, um registro de e-mail ou o histórico do DNS continuam entregando o endereço real do servidor para quem procurar.

A Cloudflare protege o tráfego que passa por ela. Se o IP do servidor continua público, o atacante ignora a proteção e fala direto com a origem.

O que a Cloudflare faz entre o visitante e o servidor

O nome técnico do que acontece é proxy reverso. Proxy reverso é um intermediário que atende em nome do servidor. O navegador do visitante abre a conexão com uma máquina da rede, e essa máquina decide o destino do pedido: responde com uma cópia guardada, bloqueia ou repassa para a sua origem.

A segunda peça é a CDN, sigla para rede de distribuição de conteúdo. Arquivos que mudam pouco, como imagens, folhas de estilo e scripts, ficam guardados em servidores espalhados por vários países. O visitante recebe o arquivo do ponto mais próximo dele, e o pedido nem chega ao seu servidor. Quanto mais o cache acerta, menos a origem trabalha.

A terceira peça é o DNS, que liga tudo. A documentação sobre status de proxy descreve as duas posições de cada registro. Em modo proxied, a consulta DNS responde com endereços anycast da rede e o tráfego HTTP e HTTPS passa pela borda. Em modo DNS-only, a resposta é o IP real do seu servidor e a borda fica de fora.

O certificado também muda de lugar. O visitante negocia o HTTPS com a borda, e a borda abre outra conexão com a origem. Se essa segunda conexão roda sem certificado válido, o cadeado aparece no navegador, mas o trecho entre a borda e o servidor fica sem a mesma proteção. O ajuste do lado do servidor é o mesmo que já aparece em SSL e HTTPS no WordPress, e na borda o modo indicado é o Full (strict).

O que o plano Free entrega de verdade

A página de planos da Cloudflare lista o mesmo núcleo para todos os níveis, do Free ao contrato sob medida: CDN, certificado universal, WAF com um conjunto gratuito de regras gerenciadas e proteção DDoS sem medição de volume. Os itens citados aqui são da versão consultada em outubro de 2026.

A proteção sem medição é o item que mais pesa para site pequeno. Um ataque de negação de serviço volumétrico tenta afogar o servidor em pedidos, e a conta da banda costuma cair em quem é atacado. No plano gratuito, a rede absorve esse volume sem cobrar pelo tamanho do ataque. O mecanismo está explicado em o que é ataque DDoS.

O WAF do Free é mais limitado. A documentação de regras gerenciadas separa dois pacotes: o conjunto gratuito, disponível em todos os planos, e o conjunto principal da empresa mais o conjunto OWASP, disponíveis a partir do Pro. Quem quer entender o que um firewall de aplicação filtra pode começar por o que é WAF.

O suporte é a diferença que mais aparece quando algo dá errado. Pela página de contato com o suporte, o usuário do Free tem comunidade e Discord, e o chamado técnico fica restrito a cobrança, conta e registro de domínio. Se o site quebrou por causa de uma regra mal configurada, você resolve com a documentação e com o fórum.

Free, Pro e Business lado a lado

A tabela junta preço, WAF, cache e suporte, com valores da página de planos e da página de suporte consultadas em outubro de 2026.

A linha do Pro usa a descrição que a própria empresa dá ao plano. Acima do Business existe o plano por contrato, com preço sob consulta e telefone de emergência no suporte.

Pages e Workers: quando a rede vira hospedagem

O proxy pressupõe um servidor de origem. O Pages dispensa essa origem para sites estáticos: você liga um repositório, o serviço roda o build a cada alteração e publica os arquivos gerados direto na rede. Não existe servidor seu para atacar, porque os arquivos já moram na borda.

O Atraca é publicado no Cloudflare Pages. O repositório tem um arquivo de configuração do Wrangler, a ferramenta de linha de comando da plataforma, e cada post vira HTML estático servido pela borda.

O Workers resolve outro problema. Ele executa código JavaScript nos servidores da Cloudflare, antes de o pedido chegar a qualquer origem. Dá para reescrever cabeçalho, redirecionar por país, montar uma API pequena ou servir uma página inteira sem servidor nenhum. Os dois produtos têm cotas gratuitas, comparadas com as de outros provedores em serviços de nuvem gratuitos.

O dia em que a Cloudflare caiu

Concentrar DNS, certificado, cache e proteção num único fornecedor tem um custo, e ele apareceu em 18 de novembro de 2025. O post-mortem oficial, assinado por Matthew Prince, registra que as falhas começaram às 11h20 UTC.

A causa foi uma mudança de permissões num banco de dados ClickHouse. Depois dela, a consulta que gera um arquivo de configuração do sistema de gerenciamento de bots passou a devolver linhas duplicadas, porque não filtrava pelo nome do banco. O arquivo dobrou de tamanho e passou do limite que o software leitor aceitava. O software falhou, e o proxy começou a devolver erros 5xx.

O texto afirma que o problema não foi causado por ataque nem por atividade maliciosa de nenhum tipo. O tráfego principal voltou a fluir quase normalmente às 14h30 UTC, e todos os sistemas estavam normais às 17h06 UTC.

Um detalhe do relatório interessa a quem administra site. O login no painel falhou para a maioria dos usuários, porque dependia do Turnstile, que também caiu. Desligar o proxy pelo painel, para apontar o DNS direto para a origem, ficou difícil justamente nessas horas.

O erro clássico: o IP da origem continua público

A borda só filtra o que passa por ela. Se alguém descobre o IP do servidor, manda pedidos direto para ele, e a Cloudflare nem fica sabendo do ataque.

O guia de proteção do servidor de origem lista os vazamentos mais comuns. Registros DNS-only de subdomínios web devolvem o IP real. Registros SPF e TXT às vezes carregam o endereço do servidor. Serviços de histórico de DNS guardam o IP que o domínio usava antes da migração. E-mail hospedado na mesma máquina do site revela o IP na mensagem de retorno quando alguém escreve para um endereço inexistente.

O mesmo guia propõe camadas de correção. A mais simples é bloquear no firewall do servidor todo tráfego que não venha das faixas de IP da rede. A documentação classifica essa opção como moderadamente segura, porque está sujeita a falsificação de IP. O Authenticated Origin Pulls acrescenta um certificado que prova que o pedido veio da borda. O Cloudflare Tunnel liga o servidor à rede sem nenhum IP público roteável, e por isso fica no topo da escala.

Em WordPress, essas medidas somam com o endurecimento do servidor tratado em segurança WordPress, porque o WAF na frente do site só filtra os pedidos que chegam pela borda.

Como configurar sem deixar a porta dos fundos aberta

1. Revise todos os registros DNS. Tudo que serve web fica em modo proxied. DNS-only só para e-mail, verificação de domínio e serviços que não são HTTP.
2. Procure o IP do servidor no próprio DNS. Leia SPF, TXT e subdomínios antigos, como ftp ou dev, que podem ter ficado em modo DNS-only.
3. Troque o IP da origem depois da migração. O histórico de DNS guarda o endereço anterior, e só um IP novo, que nunca apareceu sem proxy, resolve isso.
4. Feche o firewall do servidor. Aceite conexões nas portas 80 e 443 apenas das faixas de IP publicadas pela rede.
5. Ajuste o certificado. Use o modo Full (strict) com certificado válido na origem e avalie o Authenticated Origin Pulls.
6. Tire o e-mail da máquina do site. Um provedor de e-mail separado elimina o vazamento pela mensagem de retorno.
7. Escreva o plano para a borda fora do ar. Defina quem decide desligar o proxy, como fazer isso sem depender do painel e o que fica exposto enquanto o IP estiver público.

O ponto que fica

A nuvem laranja cuida do caminho da frente. O caminho dos fundos fecha no firewall do servidor, com uma regra que aceita tráfego web apenas das faixas de IP que a própria Cloudflare publica.