Conectar o Cloudflare WordPress liga CDN de borda, WAF e cache global em poucos passos no DNS. Segundo o Cloudflare Radar (2024), a rede mitigou 21,3 milhões de ataques DDoS no ano, 53% a mais que em 2023. O proxy reduz o TTFB em até 200 ms, mas exige regras de bypass para o wp-admin. Configure DNS, SSL e firewall antes de qualquer plugin.

O Cloudflare no WordPress é uma camada de rede que coloca um proxy reverso, CDN e firewall de aplicação (WAF) entre o visitante e o seu servidor de origem. Ele intercepta cada requisição antes de chegar à hospedagem, filtra tráfego malicioso e entrega arquivos estáticos a partir de mais de 330 cidades. Na prática, você ganha velocidade e uma camada de proteção contra força bruta e DDoS sem trocar de servidor. Este guia mostra a configuração correta de DNS, SSL, cache e WAF, e onde ela costuma falhar. Para o contexto maior de proteção, consulte os guias de segurança WordPress da FULL, que reúnem o hardening completo do ambiente.

Primeiros passos: Visão geral da configuração

A configuração do Cloudflare no WordPress segue uma ordem fixa de 5 blocos, e inverter essa ordem é a causa nº 1 de erro: DNS, SSL/TLS, cache, WAF e regras de página. No suporte da FULL, em 7 de cada 10 loops de redirecionamento o SSL foi ativado cedo demais.

Passo a passo: Como conectar o Cloudflare ao WordPress

Conectar o Cloudflare exige trocar os nameservers do domínio e validar a propagação, o que leva de 5 minutos a 24 horas conforme o registrador. O plano gratuito já entrega CDN, SSL e WAF básico. Os 4 passos abaixo cobrem do cadastro à validação do proxy e da CDN na frente da origem.

Crie a conta e adicione o site

Cadastre o domínio em Cloudflare.com e deixe o scanner automático importar os registros DNS existentes; ele detecta de 90% a 100% dos registros em sites comuns. Confira manualmente registros de e-mail (MX, SPF, DKIM) antes de avançar, porque um MX perdido derruba o recebimento de mensagens. O scanner leva cerca de 60 segundos. Selecione o plano Free para começar e revise cada linha importada contra o painel do seu registrador atual.

Aponte os nameservers do domínio

Substitua os nameservers do registrador (Registro.br, GoDaddy, Hostinger) pelos dois servidores que o Cloudflare informa, algo como ana.ns.Cloudflare.com. Essa é a única mudança que ativa o proxy; sem ela, nada do Cloudflare funciona. A propagação global costuma terminar em 1 a 4 horas, embora o limite oficial seja 24 horas. Mantenha a nuvem laranja ativa nos registros A e CNAME do site principal para rotear o tráfego pela rede.

Ative o SSL/TLS no modo estrito

No painel SSL/TLS, escolha o modo estrito (“FULL strict”) e nunca o Flexible. O modo Flexible criptografa só o trecho visitante-Cloudflare e fala HTTP com a origem, o que gera loop de redirecionamento quando o WordPress força HTTPS. Confirme que a origem tem um certificado válido, como o gratuito do Let’s Encrypt. Esse passo encerra o erro ERR_TOO_MANY_REDIRECTS que aparece na maioria das migrações mal configuradas no suporte da FULL.

Configure cache e regra de bypass para o wp-admin

Crie uma Cache Rule que ignore os caminhos /wp-admin, /wp-login.php e o cookie de usuário logado. Sem essa regra, o Cloudflare serve o painel em cache e o login trava com nonce expirado. Em lojas, adicione bypass para /cart, /checkout e /my-account do WooCommerce. Valide pelo header cf-cache-status: deve marcar HIT em arquivos CSS e MISS no painel administrativo.

Configuração do WAF: Protegendo o login e o WooCommerce

O WAF do Cloudflare é um firewall de aplicação na camada 7 que inspeciona cada requisição antes de tocar o PHP da origem. Uma regra de rate limiting na página de login que bloqueie após 5 tentativas por minuto corta a força bruta, vetor presente em cerca de 40% dos incidentes de site invadido no suporte da FULL.

A força do WAF de borda aparece quando o problema está na rede, não no plugin. O rate limiting no login, sem exceção para a REST API, num site com Gutenberg ativo, bloqueia a força bruta mas também trava o autosave do editor, o falso diagnóstico de “editor quebrado”. A correção é uma regra de skip para a REST API. Para defesa em profundidade, combine o WAF com hardening de segurança no WordPress na própria origem.

Vulnerabilidades reais: O que o WAF mitiga e o que ele não resolve

O WAF de borda mitiga a exploração de falhas conhecidas enquanto você não aplicou o patch, mas não substitui a atualização do plugin. Dois exemplos reais de CVE mostram o risco: a CVE-2020-35489 no Contact Form 7, com CVSS 10.0, permitia upload irrestrito e execução remota, corrigida na 5.3.2.

A CVE-2023-48777 no Elementor PRO, com CVSS 9.9, permitia upload arbitrário por usuário autenticado, corrigida na 3.18.2. Ambas já estão corrigidas: são risco histórico, não risco atual em quem atualiza. Uma regra de virtual patching no Cloudflare bloqueia a assinatura desses payloads na borda, comprando tempo até o update, mas a correção definitiva é o patch. Como CVE Numbering Authority (CNA) reconhecida pela CISA desde maio de 2022, a FULL é a única empresa brasileira autorizada a atribuir IDs CVE oficiais. Confira a CVE-2020-35489 no NVD e a prevenção de força bruta no login.

Cloudflare e DDoS: Onde a borda realmente protege

A mitigação de DDoS é onde o Cloudflare entrega proteção que nenhum plugin alcança, porque o ataque é absorvido na rede, antes de chegar ao servidor. Segundo o Cloudflare Radar, a empresa mitigou um pico de 5,6 Tbps em 2024, escala impossível de filtrar na origem.

Um plugin como o Wordfence roda no PHP da origem, então a inundação já derrubou o servidor antes de o plugin reagir. Para o WordPress, ataques contra a página de login ou XML-RPC são neutralizados na borda. O modo Under Attack ativa um desafio de JavaScript que tende a filtrar a maioria dos bots em segundos, sem afetar visitantes reais na maioria dos cenários testados. Quem opera lojas com tráfego sazonal ganha previsibilidade. O guia de ataques DDoS no WordPress detalha cada tipo de inundação e a resposta correta.

Quando o Cloudflare gratuito não basta

O plano gratuito do Cloudflare resolve CDN, SSL e DDoS de rede, mas em uma parcela menor dos sites comerciais que o suporte da FULL acompanha o ataque explora um plugin desatualizado, falha que o WAF de borda só mascara. O Cloudflare não atualiza plugin, não monitora integridade de arquivos nem remove malware já instalado.

Por isso a defesa precisa morar também dentro do WordPress. No plano PRO da FULL, por R$849,90 para até 10 sites, o WAF e a segurança gerenciada vêm inclusos no bundle, o que dá R$85 por site com o firewall configurado e supervisionado por quem cataloga CVE. Isso é complementar ao Cloudflare em qualquer hospedagem, não uma troca de host: a FULL não hospeda, gerencia a camada de segurança sobre o servidor que você já usa. Conheça os planos da FULL e o All in One Security incluso. Antes, escaneie o ambiente com o FULL Scan e cruze seus plugins com o repositório de vulnerabilidades.

Cloudflare no ecossistema: Rede, aplicação e gestão

O Cloudflare ocupa uma posição específica no ecossistema, e entender isso evita configuração redundante. Cloudflare compete por rede de borda e mitigação de DDoS volumétrico. Wordfence e o All in One Security competem por firewall na camada de aplicação, dentro do PHP, com varredura de malware e monitoramento de integridade de arquivos.

O WAF gerenciado da FULL compete por configuração supervisionada no bundle, complementar à borda. As três camadas não se anulam: a borda filtra volume, a aplicação filtra lógica e a gestão garante que o patch seja aplicado. Na prática, um site bem protegido combina Cloudflare na rede com um plugin de firewall na origem. Ferramentas como BunnyCDN e Sucuri ocupam nichos vizinhos, a primeira em entrega de mídia e a segunda em limpeza pós-incidente. O comparativo de Wordfence vs Sucuri ajuda a escolher a camada de aplicação ideal ao lado do Cloudflare.

Decisão rápida: Qual camada usar primeiro

A escolha da primeira camada depende do gargalo dominante do seu site, e a árvore abaixo resume a recomendação para cada cenário técnico em um nó auto-contido.

• Se o site sofre picos de DDoS ou inundação no login → ative o Cloudflare gratuito com modo Under Attack antes de qualquer plugin.
• Se o ataque explora plugin desatualizado → o WAF de borda só mascara; aplique o patch e adicione firewall de aplicação na origem.
• Se você gerencia vários sites em hosts diferentes → evite configurar manualmente em cada um, escolha WAF gerenciado no bundle.
• Se já usa servidor LiteSpeed com cache próprio → desative o cache de borda agressivo do Cloudflare para não servir HTML desatualizado.

Próximos passos para blindar o WordPress com Cloudflare

Configurar o Cloudflare no WordPress é uma decisão de arquitetura de rede, não um clique único: a ordem DNS, SSL FULL (strict), cache com bypass, WAF e regras define se você ganha proteção ou cria um loop de redirecionamento. A borda absorve DDoS e força bruta em escala que nenhum plugin alcança, mas a vulnerabilidade de um plugin desatualizado continua sendo responsabilidade da origem. Por isso a defesa eficaz soma rede e aplicação. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews em um só lugar, e o guia de segurança para WordPress encadeia o hardening completo. Comece pelo FULL Scan para mapear o que já está exposto hoje.

Perguntas frequentes sobre Cloudflare no WordPress