Cloudflare Page Rules no WordPress pode quebrar o login e o SSL do site quando regras de cache ou de "Always Use HTTPS" são aplicadas sobre wp-admin, wp-login.php ou wp-json sem exclusões corretas. Para configurar Page Rules sem quebrar SSL e login, siga este checklist:
- Confirme o modo SSL correto no Cloudflare (Full ou Full Strict)
- Exclua wp-admin e wp-login.php de qualquer regra de cache
- Crie regra separada para "Bypass Cache" em áreas administrativas
- Valide a ordem de prioridade das Page Rules
- Teste login em aba anônima antes de propagar em produção
- Purgue o cache do Cloudflare após cada alteração
Pré-requisitos
- Acesso ao painel Cloudflare com domínio já ativo (nameservers apontados)
- Acesso administrativo ao WordPress (wp-admin) e ao wp-config.php via SSH ou FTP
- Certificado SSL válido no servidor de origem (Let's Encrypt, AutoSSL ou pago)
- Plano Cloudflare com Page Rules disponíveis (Free permite 3 regras, planos pagos mais)
- Backup recente do site antes de qualquer alteração de cache ou SSL
Checklist: Cloudflare Page Rules no WordPress sem quebrar SSL e login
O checklist Cloudflare Page Rules começa pela verificação do modo SSL/TLS, porque é a causa mais comum de loop de redirecionamento no WordPress. Se o Cloudflare está em "Flexible" e o WordPress força HTTPS via FORCE_SSL_ADMIN, o navegador entra em loop entre HTTP (Cloudflare-origem) e HTTPS (regra do WordPress). O ideal é sempre configurar Full ou Full (Strict) quando há certificado válido instalado no servidor de origem.
- Acesse SSL/TLS no painel Cloudflare e mude para Full (Strict) se houver certificado válido
- Verifique se o wp-config.php não força HTTPS de forma conflitante com o Cloudflare
- Liste todas as Page Rules ativas e a ordem de execução (Cloudflare processa de cima para baixo)
- Identifique quais regras afetam URLs administrativas
Se você ainda está estruturando o DNS antes de ativar o proxy Cloudflare, vale revisar o guia de zona DNS: registros A, MX, CNAME e TXT do zero para garantir que os registros estão corretos antes de aplicar cache agressivo.
Excluindo wp-admin e wp-login.php do cache
A exclusão de cache no wp-admin é o passo que mais evita quebra de login, porque o Cloudflare por padrão não armazena páginas com cookies de sessão — mas uma regra de "Cache Everything" mal configurada ignora esse comportamento e serve HTML estático do painel administrativo. Isso trava formulários de login, nonces e a tela de plugins.
- Crie uma Page Rule com URL
seudominio.com.br/wp-admin/* - Defina a configuração "Cache Level: Bypass"
- Repita para
seudominio.com.br/wp-login.php - Se usar wp-json para plugins ou apps mobile, adicione
seudominio.com.br/wp-json/*com Bypass também
URL: seudominio.com.br/wp-admin/*
Configuração: Cache Level = Bypass
Security Level = Medium
Disable Performance
Output esperado: ao acessar /wp-admin, o cabeçalho de resposta deve mostrar cf-cache-status: BYPASS nas ferramentas de desenvolvedor do navegador, confirmando que o Cloudflare não está servindo versão em cache dessa área.
Ordem de prioridade das Page Rules
A ordem das Page Rules Cloudflare determina qual regra prevalece quando duas URLs coincidem, e regras posicionadas abaixo de uma correspondência mais genérica nunca são executadas. Isso é comum quando existe uma regra "Cache Everything" para seudominio.com.br/* no topo e a regra de bypass do wp-admin fica abaixo dela — nesse caso, a regra genérica sempre vence.
- Arraste a regra de bypass do wp-admin para o topo da lista
- Mantenha "Cache Everything" (se usada) como regra de menor prioridade
- Evite mais de 3 regras conflitantes no plano Free — considere Cache Rules como alternativa moderna
Se o WordPress está hospedado em um ambiente com cache adicional no servidor, revise também as configurações de proxy — o guia de como redirecionar um site http para https ajuda a entender como o redirecionamento interage com o proxy do Cloudflare.
Always Use HTTPS e Automatic HTTPS Rewrites
A opção Always Use HTTPS no Cloudflare redireciona todo tráfego HTTP para HTTPS na borda da CDN, mas se o WordPress também tiver esse redirecionamento no .htaccess ou em plugin de SSL, o resultado é um loop de redirecionamento infinito, especialmente perceptível no wp-login.php.
- Ative "Always Use HTTPS" apenas no Cloudflare, nunca duplicado em .htaccess e Cloudflare simultaneamente
- Desative regras de redirecionamento HTTPS forçado em plugins como Really Simple SSL se o Cloudflare já fizer isso
- Teste com
curl -I http://seudominio.com.br/wp-login.phpe confirme resposta única 301
curl -I http://seudominio.com.br/wp-login.php
HTTP/1.1 301 Moved Permanently
Location: https://seudominio.com.br/wp-login.php
Server: cloudflare
Se aparecer mais de um redirecionamento na cadeia (ex: 301 seguido de outro 301 para o mesmo domínio), há conflito entre Cloudflare e WordPress que precisa ser removido de um dos dois lados.
Testando login e checkout antes de propagar em produção
O teste de login pós-Page Rules deve ocorrer em aba anônima e com cache do navegador limpo, porque cookies antigos de sessão administrativa podem mascarar um problema que só aparece para usuários novos ou não logados.
- Abra o site em aba anônima e acesse /wp-admin
- Faça login normalmente e verifique se permanece autenticado ao navegar entre páginas do painel
- Se o site tiver WooCommerce, teste o checkout e a página de conta do cliente, pois cookies de carrinho também sofrem com cache mal configurado
- Purgue o cache do Cloudflare (Caching > Configuration > Purge Everything) após qualquer ajuste
Para ambientes com banco de dados MySQL que também recebem tráfego de área administrativa, vale revisar a conexão remota ao MySQL no cPanel caso o problema de login esteja relacionado a timeout de sessão no banco, e não apenas ao Cloudflare.
Problemas comuns e como resolver
Sintoma: loop infinito de redirecionamento ao acessar wp-login.php
Causa: modo SSL "Flexible" no Cloudflare combinado com força de HTTPS no WordPress, ou Page Rule de cache aplicada sobre a URL de login.
Solução: mude o modo SSL para Full (Strict), remova qualquer regra de cache sobre wp-login.php e confirme com curl -I que existe apenas um redirecionamento na cadeia.
Sintoma: alterações no painel WordPress não são salvas ou somem após recarregar
Causa: Page Rule "Cache Everything" está servindo uma versão em cache do wp-admin em vez da versão dinâmica com as alterações recentes.
Solução: crie regra de Bypass exclusiva para /wp-admin/* com prioridade acima da regra de cache geral e purgue o cache manualmente.
Sintoma: erro de certificado SSL inválido após ativar proxy Cloudflare
Causa: o certificado de origem expirou, não corresponde ao domínio ou o modo SSL está incompatível com o tipo de certificado instalado no servidor.
Solução: verifique a validade do certificado de origem via painel de hospedagem, reemita se necessário e ajuste o modo SSL do Cloudflare para Full (Strict) apenas quando o certificado for válido.
Sintoma: formulário de contato ou checkout não envia dados corretamente
Causa: regras de cache capturando requisições POST ou cookies de sessão sendo descartados por configuração agressiva de "Cache Everything".
Solução: adicione exclusões para endpoints de formulário e admin-ajax.php nas Page Rules, garantindo Bypass nessas URLs específicas.
Perguntas frequentes sobre Cloudflare Page Rules no WordPress
Por que o wp-admin fica em loop de redirecionamento depois de criar Page Rules no Cloudflare?
Isso ocorre quando uma regra de "Always Use HTTPS" ou "Cache Everything" é aplicada sobre a URL do wp-admin ou wp-login.php, forçando o navegador a redirecionar entre HTTP e HTTPS repetidamente. O problema piora quando o modo SSL no Cloudflare está como "Flexible" enquanto o WordPress já força HTTPS via wp-config.php. A correção é excluir essas URLs da regra de cache e alinhar o modo SSL para "Full" ou "Full (Strict)".
Quantas Page Rules o plano Free do Cloudflare permite?
O plano Free permite até 3 Page Rules ativas simultaneamente. Se o site precisar de mais regras específicas para WordPress (wp-admin, wp-login, wp-json, checkout), considere migrar parte da lógica para Cache Rules, disponíveis mesmo em contas gratuitas com limites maiores.
Cache Everything no Cloudflare quebra o WooCommerce?
Sim, se aplicado sem exclusões. O WooCommerce depende de cookies de sessão para carrinho e checkout, e uma regra genérica de "Cache Everything" pode servir páginas estáticas para todos os visitantes, ignorando o estado do carrinho. É necessário excluir /carrinho, /checkout e /minha-conta do cache.
Qual modo SSL do Cloudflare é mais seguro para WordPress?
Full (Strict) é o mais seguro, pois exige certificado válido tanto na borda do Cloudflare quanto na origem, validando a cadeia completa. Flexible deve ser evitado em produção porque a conexão entre Cloudflare e o servidor de origem fica sem criptografia, mesmo que o visitante veja HTTPS no navegador.
Como saber se uma Page Rule está causando o problema de login?
Desative temporariamente as Page Rules uma a uma e teste o login em aba anônima após cada desativação, purgando o cache do Cloudflare entre os testes. A regra responsável geralmente é a que contém "Cache Everything" ou "Always Use HTTPS" aplicada de forma ampla, sem exclusão de wp-admin.
Conclusão
- Sempre configure o modo SSL como Full (Strict) antes de criar qualquer regra de cache agressiva
- Exclua wp-admin, wp-login.php e wp-json de qualquer Page Rule de cache com prioridade máxima
- Teste login e checkout em aba anônima após cada alteração e purgue o cache do Cloudflare imediatamente
Leia também
- Comparativo de cache no cPanel: acelerar WordPress sem quebrar SSL
- Entenda como corrigir redirecionamento infinito HTTPS no WordPress
- Migrar WordPress entre hospedagens sem downtime: procedimento completo
Precisa de ajuda com WordPress e Cloudflare?
Configurar CDN e SSL sem quebrar o login exige testes cuidadosos em ambiente real — nossa equipe pode revisar a configuração do seu WordPress hospedado para evitar esses conflitos.