Checklist: Cloudflare Page Rules no WordPress sem quebrar SSL e login

Por Equipe Técnica AviraHost · 10 min de leitura · Atualizado em · cloudflare, page-rules, wordpress, ssl, wp-login, dns, cache, avirahost · 0

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:

  1. Confirme o modo SSL correto no Cloudflare (Full ou Full Strict)
  2. Exclua wp-admin e wp-login.php de qualquer regra de cache
  3. Crie regra separada para "Bypass Cache" em áreas administrativas
  4. Valide a ordem de prioridade das Page Rules
  5. Teste login em aba anônima antes de propagar em produção
  6. 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.

  1. Acesse SSL/TLS no painel Cloudflare e mude para Full (Strict) se houver certificado válido
  2. Verifique se o wp-config.php não força HTTPS de forma conflitante com o Cloudflare
  3. Liste todas as Page Rules ativas e a ordem de execução (Cloudflare processa de cima para baixo)
  4. 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.

  1. Crie uma Page Rule com URL seudominio.com.br/wp-admin/*
  2. Defina a configuração "Cache Level: Bypass"
  3. Repita para seudominio.com.br/wp-login.php
  4. 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.

  1. Arraste a regra de bypass do wp-admin para o topo da lista
  2. Mantenha "Cache Everything" (se usada) como regra de menor prioridade
  3. 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.

  1. Ative "Always Use HTTPS" apenas no Cloudflare, nunca duplicado em .htaccess e Cloudflare simultaneamente
  2. Desative regras de redirecionamento HTTPS forçado em plugins como Really Simple SSL se o Cloudflare já fizer isso
  3. Teste com curl -I http://seudominio.com.br/wp-login.php e 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.

  1. Abra o site em aba anônima e acesse /wp-admin
  2. Faça login normalmente e verifique se permanece autenticado ao navegar entre páginas do painel
  3. 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
  4. 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

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.

Conheça os planos de hospedagem WordPress da AviraHost


Esta resposta foi útil?