O Cloudflare é um serviço que fica entre os visitantes e o servidor do seu site, funcionando como proxy reverso: ele responde pelo DNS do domínio, entrega arquivos pela CDN e filtra ataques antes que eles cheguem à hospedagem. O site continua no seu servidor; o Cloudflare é a camada de velocidade e proteção na frente dele.
A seguir você vê como esse fluxo funciona, o que o plano gratuito inclui, qual modo de SSL escolher e o passo a passo para ativar o Cloudflare sem derrubar o site nem o e-mail.
O que é o Cloudflare
O Cloudflare é uma empresa americana que mantém uma das maiores redes de borda da internet, com servidores em centenas de cidades em mais de 100 países. O nome junta cloud (nuvem) e flare (clarão, sinalizador). Na prática, quando você coloca um site no Cloudflare, ele passa a usar quatro peças ao mesmo tempo:
- Proxy reverso: os visitantes se conectam ao Cloudflare, e não direto ao seu servidor. O IP da hospedagem fica escondido atrás dos IPs do Cloudflare.
- CDN: imagens, CSS, JavaScript e outros arquivos estáticos ficam guardados em cache nos servidores do Cloudflare e são entregues a partir do ponto mais próximo do visitante. Se o conceito for novo, veja como funciona uma CDN.
- DNS autoritativo: o Cloudflare passa a responder pelos registros do domínio (A, CNAME, MX, TXT), no lugar do DNS da hospedagem ou do registrador.
- WAF e proteção contra DDoS: um firewall de aplicação (WAF) analisa as requisições e bloqueia padrões de ataque, e a rede absorve picos de tráfego malicioso antes que eles cheguem ao servidor.
Cloudflare é hospedagem? Não. O Cloudflare não guarda os arquivos e o banco de dados do seu site de forma permanente. Ele precisa de um servidor de origem (hospedagem, VPS ou servidor dedicado) para funcionar. A confusão é comum porque, depois de ativado, os IPs que aparecem para o domínio são do Cloudflare.
Como o Cloudflare funciona
O caminho de uma visita muda assim que o domínio passa a usar os nameservers do Cloudflare. Em vez de ir direto ao servidor, a requisição faz uma parada na borda do Cloudflare:
- Consulta DNS: o navegador pergunta o IP de seusite.com.br. O DNS do Cloudflare responde com um IP do próprio Cloudflare, e não com o IP da hospedagem.
- Borda mais próxima: como esses IPs usam anycast (o mesmo endereço anunciado em muitos locais), a conexão cai no data center do Cloudflare mais perto do visitante.
- Filtro de segurança: a requisição passa pela proteção contra DDoS, pelas regras do WAF e pelas regras que você criou. Tráfego suspeito é bloqueado ou desafiado ali mesmo.
- Cache: se o arquivo pedido já está em cache (uma imagem, um CSS), o Cloudflare responde na hora, sem tocar no seu servidor.
- Origem: o que não está em cache (normalmente o HTML e as páginas dinâmicas) é buscado no seu servidor, devolvido ao visitante e, se for cacheável, guardado para as próximas visitas.
Um efeito colateral útil: o Cloudflare atende visitantes por IPv6 mesmo que o seu servidor só tenha IPv4, porque quem conversa com o visitante é a borda, e não a origem. E, como parte das requisições é respondida pelo cache, o servidor gasta menos CPU e banda, o que ajuda principalmente em VPS e Cloud Server com recursos fixos.
Para que serve: o que muda no seu site
Em vez de uma lista genérica de vantagens, veja o que cada recurso resolve e onde ele entra no painel:
| Problema | Recurso do Cloudflare | O que acontece |
|---|---|---|
| Site lento para quem está longe do servidor | CDN e cache | Arquivos estáticos saem da borda mais próxima, reduzindo a latência. |
| Ataque de negação de serviço | Proteção contra DDoS | O tráfego de ataque é filtrado na rede do Cloudflare, sem limite de volume, em todos os planos. |
| Tentativas de invasão (SQL injection, exploits conhecidos) | WAF com regras gerenciadas | Requisições com assinatura de ataque são bloqueadas antes de chegar ao site. |
| Robôs consumindo recursos | Regras personalizadas e desafios | Você bloqueia ou desafia por país, IP, caminho ou user agent. |
| Site sem HTTPS | Certificado de borda gratuito (Universal SSL) | O visitante passa a ver o cadeado, mas a conexão até o servidor depende do modo de SSL (veja abaixo). |
| Servidor no limite | Cache de arquivos | Menos requisições chegam à origem, o que adia upgrades de plano. |
Se o seu problema é especificamente ataque de volume, vale entender o que é um ataque DDoS e como se proteger além do Cloudflare, porque nem todo serviço do servidor (e-mail, FTP, SSH) passa pelo proxy.
Planos do Cloudflare e o que o gratuito inclui
O Cloudflare tem plano gratuito, e ele resolve a maioria dos sites pequenos e médios. Os planos para sites são Free (gratuito), Pro, Business e Enterprise. Os valores dos pagos mudam com frequência e variam por cobrança mensal ou anual, então confira na página oficial de planos antes de decidir.
Segundo a documentação oficial, o plano gratuito inclui:
- DNS e CDN para o domínio.
- Certificado de borda gratuito (Universal SSL), emitido e renovado automaticamente para o domínio e subdomínios de primeiro nível.
- Proteção contra DDoS sem limite de volume nas camadas 3, 4 e 7, disponível em todos os planos.
- WAF com o conjunto gratuito de regras gerenciadas (Free Managed Ruleset), voltado a vulnerabilidades de grande repercussão. As regras gerenciadas completas e o conjunto OWASP ficam a partir do Pro.
- 5 regras personalizadas de WAF por domínio (o Pro sobe para 20 e o Business para 100, conforme a documentação do WAF).
Atenção a tutoriais antigos: as Page Rules aparecem como recurso obsoleto (deprecated) na documentação do Cloudflare. Para cache, redirecionamentos e ajustes por URL, use as regras novas (Cache Rules, Redirect Rules e similares). Recursos como o Railgun, citados em artigos antigos, também saíram de linha.
No topo da linha, o Enterprise oferece recursos como o Keyless SSL, criado para bancos e empresas que não podem entregar a chave privada do certificado a terceiros. Nesse modelo, a chave fica na infraestrutura do cliente e o Cloudflare só consulta um servidor de chaves durante o handshake. É um add-on pago do Enterprise, sem uso para a maioria dos sites.
Modos de SSL: Off, Flexible, Full e Full (strict)
Com o Cloudflare, existem duas conexões: do visitante até o Cloudflare e do Cloudflare até o seu servidor. O modo de SSL define o que acontece na segunda, e é aqui que muita configuração dá errado:
| Modo | Visitante → Cloudflare | Cloudflare → servidor | Quando usar |
|---|---|---|---|
| Off | HTTP, sem criptografia | HTTP, sem criptografia | Nunca em site público. Navegadores mostram “não seguro”. |
| Flexible | HTTPS | HTTP, sem criptografia | Só como paliativo para servidor sem certificado. O cadeado aparece, mas o trecho até a origem trafega aberto. |
| Full | HTTPS | HTTPS, sem validar o certificado | Servidor com certificado autoassinado ou vencido. Criptografa, mas não confirma que o servidor é o seu. |
| Full (strict) | HTTPS | HTTPS, validando o certificado | Recomendado. Exige certificado válido na origem (de uma autoridade pública ou o Origin CA do Cloudflare). |
O Full (strict) é o único modo em que o Cloudflare criptografa o caminho inteiro e também confere a identidade do servidor, o que impede que alguém no meio do caminho se passe pela origem. A documentação oficial dos modos de SSL recomenda Full ou Full (strict) sempre que possível. Hoje o padrão é o modo automático, que testa a origem e aplica o modo mais seguro que ela suporta, sem nunca rebaixar a configuração.
O risco do Flexible: o visitante vê o cadeado e acredita que está tudo protegido, mas senhas e dados de formulário viajam sem criptografia entre o Cloudflare e o servidor. Além disso, se o site (WordPress, por exemplo) já força HTTPS, o Flexible costuma causar o erro de “redirecionamentos em excesso” (ERR_TOO_MANY_REDIRECTS).
Para usar o Full (strict), o servidor precisa de um certificado válido. Pode ser o da própria hospedagem ou um certificado Origin CA, gratuito em todos os planos, mas aceito só pelo Cloudflare. Com tudo em HTTPS, o passo seguinte é ativar o HSTS para que o navegador nunca mais tente a versão HTTP do site.
Como configurar o Cloudflare no seu site
A configuração básica leva poucos minutos de trabalho e algumas horas de espera pela troca de nameservers. Antes de começar, tenha à mão o acesso ao painel onde o domínio foi registrado (no caso de .br, o Registro.br).
- Crie a conta e adicione o site: no painel do Cloudflare, use a opção de adicionar um domínio (Onboard a domain), digite o domínio principal (sem www) e escolha o plano Free.
- Revise os registros DNS importados: o Cloudflare faz uma varredura automática, mas ela não garante encontrar tudo. Compare com a zona atual e confira o domínio raiz, o www, os subdomínios e os registros de e-mail (MX, SPF, DKIM e DMARC).
- Defina nuvem laranja ou cinza em cada registro: laranja (Proxied) para o que é site; cinza (DNS only) para o resto. A tabela logo abaixo mostra o que vai em cada um.
- Desative o DNSSEC no registrador, se estiver ativo: trocar os nameservers com DNSSEC ligado pode deixar o domínio inacessível. Você reativa depois, pelo Cloudflare.
- Troque os nameservers: copie os dois nameservers indicados pelo Cloudflare e substitua os atuais no painel do registrador.
- Aguarde a ativação: o Cloudflare informa que a troca pode levar até 24 horas no registrador; o domínio aparece como Active e você recebe um e-mail. Enquanto isso, o site segue no ar pelo DNS antigo. Entenda o motivo da espera em propagação de DNS.
- Ajuste o SSL: na seção SSL/TLS, confirme que o modo é Full (strict) ou o automático já com Full (strict) aplicado. Ative também “Always Use HTTPS” para redirecionar HTTP para HTTPS.
- Reative o DNSSEC pelo Cloudflare e publique o registro DS no registrador.
- Crie as regras de cache que o seu site precisa (veja a seguir).
Proxy laranja ou cinza: o que passar pelo Cloudflare
Só registros A, AAAA e CNAME podem passar pelo proxy, e o proxy só trata tráfego web (HTTP e HTTPS). Todo o resto precisa ficar em cinza, conforme a documentação de status do proxy:
| Registro | Status | Por quê |
|---|---|---|
seusite.com.br e www | Laranja (Proxied) | É o site: ganha CDN, WAF e proteção. |
mail, webmail, smtp, imap | Cinza (DNS only) | E-mail não é HTTP; com proxy, o cliente de e-mail não conecta. |
ftp, ssh, cpanel por IP direto | Cinza (DNS only) | Serviços fora de HTTP/HTTPS não passam pelo proxy. |
| MX, TXT (SPF, DKIM, DMARC) | Sempre DNS only | Esses tipos de registro não aceitam proxy. |
Regras de cache
Por padrão, o Cloudflare não guarda HTML nem JSON em cache; ele guarda arquivos por extensão (imagens, CSS, JS, fontes, PDF e similares). Isso é seguro para começar. Se quiser cachear também o HTML para ganhar velocidade, crie uma Cache Rule que cacheie as páginas e, antes dela, uma regra que ignore o cache nas áreas logadas. Num WordPress, a expressão para pular o cache fica assim:
(starts_with(http.request.uri.path, "/wp-admin"))
or (http.request.uri.path eq "/wp-login.php")
or (http.cookie contains "wordpress_logged_in")
or (http.cookie contains "woocommerce_items_in_cart")Para entender o que é guardado, onde e por quanto tempo, veja o que é cache. Sempre que publicar uma mudança importante e ela não aparecer, use a opção de limpar o cache (Purge Cache) no painel.
Cuidados antes e depois de ativar
A maior parte dos problemas com Cloudflare aparece em três pontos: e-mail, IP dos visitantes e cache de páginas dinâmicas.
- E-mail não passa pelo proxy: MX e os registros do servidor de e-mail ficam sempre em cinza. Se o mail.seusite.com.br apontar para o mesmo IP do site, esse IP fica público e um atacante pode ir direto ao servidor, sem passar pelo Cloudflare. Quando possível, use e-mail em servidor separado ou bloqueie no firewall do servidor o acesso web que não venha do Cloudflare.
- IP real do visitante: com o proxy, o servidor vê os IPs do Cloudflare em todas as requisições. Logs, bloqueios por IP, limitadores de login e plugins de segurança passam a enxergar o “visitante errado” até você configurar o servidor para ler o cabeçalho
CF-Connecting-IP. - Cache de HTML: cachear tudo sem exceções pode mostrar a um visitante a página de outro (carrinho, área do cliente, painel). Comece só com arquivos estáticos e libere o HTML com regras de exceção.
- Certificado na origem: se você pausar o Cloudflare ou mudar um registro para cinza, o certificado Origin CA não é aceito pelos navegadores. Quem usa Origin CA precisa manter o proxy ativo.
No Apache, a recomendação do Cloudflare é usar o módulo mod_remoteip, declarando o cabeçalho e cada faixa de IP publicada em cloudflare.com/ips (a lista muda; atualize de tempos em tempos):
# /etc/apache2/conf-available/remoteip.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
# ...repita RemoteIPTrustedProxy para cada faixa listada em cloudflare.com/ipsNo Nginx, o equivalente é o módulo realip, com set_real_ip_from para cada faixa e real_ip_header CF-Connecting-IP;. Em hospedagem compartilhada, esse ajuste é feito pelo provedor; em VPS ou Cloud Server, fica com você.
Na SAN: o Cloudflare acelera e protege, mas o site continua dependendo de uma boa origem. A hospedagem de sites da SAN roda em cloud, com cPanel, tráfego ilimitado, migração gratuita e suporte em português. Se você precisa ajustar o servidor por conta própria (como o mod_remoteip ou o firewall), o Cloud Server tem acesso root e cPanel/WHM.
Perguntas frequentes
Existe um plano gratuito, que inclui DNS, CDN, certificado de borda (Universal SSL), proteção contra DDoS sem limite de volume e um conjunto básico de regras de WAF. Os planos Pro, Business e Enterprise acrescentam regras gerenciadas completas, mais regras personalizadas e suporte; confira os valores atuais na página oficial de planos.
Sim, é um dos maiores provedores de CDN e segurança do mundo, mas a segurança depende da configuração. Use o modo de SSL Full (strict), mantenha o servidor atualizado e não deixe registros em cinza apontando para o mesmo IP do site sem necessidade.
Não. O Cloudflare fica na frente do servidor como proxy reverso e CDN, mas os arquivos e o banco de dados continuam na sua hospedagem, VPS ou servidor dedicado.
Continua, desde que os registros MX, SPF, DKIM e DMARC sejam copiados corretamente e os subdomínios de e-mail fiquem em DNS only (nuvem cinza). E-mail não passa pelo proxy do Cloudflare.
Para o modo recomendado, Full (strict), sim: a origem precisa de um certificado válido, que pode ser o da hospedagem ou um certificado Origin CA gratuito do Cloudflare. Sem certificado na origem, só sobra o modo Flexible, que deixa o trecho até o servidor sem criptografia.
