2026年11月12日

Como configurar a Cloudflare no WordPress: DNS, SSL, IP real e WAF

Segurança

Este artigo é uma edição localizada do original em japonês. Ler o original em japonês

Colocar a Cloudflare na frente de um site WordPress segue esta ordem: ① adicionar o site na Cloudflare e trocar os servidores de nomes (nameservers) do domínio; ② definir o modo de criptografia SSL/TLS como Full (strict); ③ restaurar no servidor o IP real do visitante; ④ proteger a tela de login com regras personalizadas do WAF. Mesmo no plano gratuito, estão disponíveis CDN, SSL, proteção contra DDoS e regras personalizadas (até 5).

Este artigo explica cada configuração e o que verificar depois da troca. Os nomes e a disposição das telas da Cloudflare podem mudar, por isso o texto segue a documentação oficial (developers.cloudflare.com) de novembro de 2026.

O que decidir antes de começar

Você vai passar a gestão do DNS para a Cloudflare. O registrador do domínio continua o mesmo, mas a edição dos registros DNS passa a ser feita na tela da Cloudflare.
Os registros DNS de e-mail (MX etc.) não devem passar pelo proxy. A Cloudflare só intermedia o tráfego web (HTTP/HTTPS).
Confirme que a origem (o servidor onde o WordPress está instalado) tem um certificado SSL válido. Se o HTTPS já funciona com Let's Encrypt ou similar, não precisa mudar nada.
Se o DNSSEC estiver ativado no registrador, desative-o antes de trocar os servidores de nomes. Um registro DS antigo que permaneça causa falha na resolução de nomes.

Passo 1: adicione o site e troque os servidores de nomes

Crie uma conta na Cloudflare e adicione o domínio no painel (Dashboard). Você pode escolher o plano Free.
A Cloudflare lê os registros DNS atuais e mostra uma lista; confira se não falta nada. Alguns registros não são lidos, então compare com a tela atual de gerenciamento de DNS e adicione manualmente os que estiverem faltando.
Nos registros A (ou AAAA e CNAME) do site, deixe o status do proxy ligado (nuvem laranja). Nos registros MX e nos registros A usados pelo servidor de e-mail, deixe desligado (somente DNS, nuvem cinza).
A Cloudflare mostra dois nomes de servidores de nomes. Eles têm o formato 〇〇.ns.cloudflare.com e são atribuídos a cada conta. Use os dois que aparecem na sua tela, e não os nomes citados em outros artigos.
No painel do registrador do domínio, troque os servidores de nomes por esses dois.

Para verificar se a troca foi concluída, use os comandos abaixo. A propagação pode levar algumas horas.

# Se os servidores de nomes são os dois da Cloudflare
dig NS example.com +short

# Se está passando pela Cloudflare (retorna server: cloudflare e cf-ray)
curl -sI https://example.com | grep -iE '^(server|cf-ray):'

Quando o status do domínio no painel da Cloudflare mudar para ativo (Active), a troca está concluída.

Passo 2: defina o SSL/TLS como Full (strict)

O SSL/TLS da Cloudflare tem modos que definem como a conexão é criptografada entre o visitante e a Cloudflare e entre a Cloudflare e a origem.

Modo	Entre a Cloudflare e a origem	Uso no WordPress
Off	Sem criptografia	Não use
Flexible	HTTP (sem criptografia)	Não use. Causa loops de redirecionamento e conteúdo misto
Full	HTTPS (sem validar o certificado)	Solução provisória até ter um certificado
Full (strict)	HTTPS (validando o certificado)	Use este

A configuração é feita na página de visão geral (Overview) de SSL/TLS no painel da Cloudflare. O padrão "Automatic SSL/TLS" escolhe automaticamente o modo mais seguro dentro do que a origem suporta. Se você escolher Full (strict) por conta própria, não corre o risco de funcionar em um modo que não pretendia. Como certificado da origem, é possível usar um de uma autoridade certificadora pública (como o Let's Encrypt) ou um certificado Origin CA emitido pela Cloudflare.

O motivo para evitar o Flexible é este. No Flexible, a requisição chega à origem por HTTP, então o WordPress ou o servidor responde "veio por HTTP, redirecione para HTTPS", e a Cloudflare volta a buscar na origem por HTTP, formando um ciclo (o navegador mostra ERR_TOO_MANY_REDIRECTS). Com o Full (strict), a requisição também chega à origem por HTTPS, e não é preciso nenhum código extra no WordPress para olhar o X-Forwarded-Proto e reescrever $_SERVER['HTTPS'].

Confirme também que, em "Configurações" → "Geral" (Settings → General) do WordPress, o "Endereço do WordPress (URL)" e o "Endereço do site (URL)" começam com https://. Se imagens e outros recursos continuarem em http://, veja como corrigir conteúdo misto.

Passo 3: restaure o IP real do visitante

Quando o site passa pela Cloudflare, a origem da conexão que chega ao servidor (REMOTE_ADDR) é um endereço IP da Cloudflare. Nesse estado, os logs de acesso, o IP dos comentários e os plugins que limitam tentativas de login tratam todos os visitantes como se fossem um IP da Cloudflare. A Cloudflare repassa o IP do visitante no cabeçalho CF-Connecting-IP, então configure o servidor para confiar nesse cabeçalho somente quando a conexão vier da Cloudflare.

Se você reescrever o REMOTE_ADDR com o valor do cabeçalho sem verificar a origem da conexão, quem acessar a origem diretamente, sem passar pela Cloudflare, poderá declarar o IP que quiser pelo cabeçalho. Por isso, não use aquele código de artigos antigos que apenas atribui ao REMOTE_ADDR o valor de HTTP_CF_CONNECTING_IP quando ele existe.

A lista de endereços IP da Cloudflare é publicada em https://www.cloudflare.com/ips/. Como a lista pode mudar, revise-a periodicamente.

No Nginx

Use o ngx_http_realip_module. No bloco http ou server, liste todos os intervalos da Cloudflare.

# Intervalos de IP da Cloudflare (em novembro de 2026; veja o mais recente em cloudflare.com/ips)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;

sudo nginx -t && sudo systemctl reload nginx

No Apache (Debian / Ubuntu)

Use o mod_remoteip. Crie o arquivo /etc/apache2/conf-available/remoteip.conf e liste os intervalos da Cloudflare em RemoteIPTrustedProxy.

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32

sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

Para registrar o IP real no log de acesso, troque o %h por %a no LogFormat (combined) de /etc/apache2/apache2.conf.

Se você não pode alterar a configuração do servidor (wp-config.php)

Em hospedagens compartilhadas e similares, em que não é possível mexer na configuração do servidor web, faça a mesma verificação no wp-config.php. Coloque o código antes da linha require_once ABSPATH . 'wp-settings.php';. Ele só usa o valor de CF-Connecting-IP (desde que seja um endereço IP válido) quando a origem da conexão estiver dentro dos intervalos da Cloudflare.

<?php
// Só usa o CF-Connecting-IP como IP do visitante quando a conexão vem pela Cloudflare
$cf_ranges = [
    '173.245.48.0/20', '103.21.244.0/22', '103.22.200.0/22', '103.31.4.0/22',
    '141.101.64.0/18', '108.162.192.0/18', '190.93.240.0/20', '188.114.96.0/20',
    '197.234.240.0/22', '198.41.128.0/17', '162.158.0.0/15', '104.16.0.0/13',
    '104.24.0.0/14', '172.64.0.0/13', '131.0.72.0/22',
    '2400:cb00::/32', '2606:4700::/32', '2803:f800::/32', '2405:b500::/32',
    '2405:8100::/32', '2a06:98c0::/29', '2c0f:f248::/32',
];

function cf_ip_in_range(string $ip, string $cidr): bool
{
    [$net, $bits] = explode('/', $cidr);
    $ip_bin  = inet_pton($ip);
    $net_bin = inet_pton($net);
    if ($ip_bin === false || $net_bin === false || strlen($ip_bin) !== strlen($net_bin)) {
        return false;
    }
    $bits  = (int) $bits;
    $bytes = intdiv($bits, 8);
    if ($bytes > 0 && substr($ip_bin, 0, $bytes) !== substr($net_bin, 0, $bytes)) {
        return false;
    }
    $rest = $bits % 8;
    if ($rest === 0) {
        return true;
    }
    $mask = (0xFF << (8 - $rest)) & 0xFF;
    return (ord($ip_bin[$bytes]) & $mask) === (ord($net_bin[$bytes]) & $mask);
}

if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']) && !empty($_SERVER['REMOTE_ADDR'])) {
    foreach ($cf_ranges as $range) {
        if (cf_ip_in_range($_SERVER['REMOTE_ADDR'], $range)) {
            $visitor = filter_var($_SERVER['HTTP_CF_CONNECTING_IP'], FILTER_VALIDATE_IP);
            if ($visitor !== false) {
                $_SERVER['REMOTE_ADDR'] = $visitor;
            }
            break;
        }
    }
}

O wp-config.php já começa com <?php, então não copie o <?php da primeira linha; cole a partir da segunda linha. Antes de colar, faça um backup do wp-config.php.

Passo 4: proteja a tela de login com regras personalizadas do WAF

As regras personalizadas do WAF da Cloudflare podem ser criadas em até 5 no plano gratuito, e permitem escolher ações diferentes de Log (como Block e Managed Challenge). Para criar, abra a página Security rules do painel, escolha "Create rule" e depois "Custom rules", defina a condição (Field, Operator, Value) e a ação e clique em "Deploy".

Exemplo 1: liberar o login e o painel apenas para o seu IP

É um exemplo para quando você tem um IP fixo em casa ou na empresa. Escrito como expressão, fica assim (troque 203.0.113.10 e 198.51.100.0/24 pelos seus IPs).

(http.request.uri.path eq "/wp-login.php" or starts_with(http.request.uri.path, "/wp-admin/"))
and http.request.uri.path ne "/wp-admin/admin-ajax.php"
and not ip.src in {203.0.113.10 198.51.100.0/24}

A ação é Block. O /wp-admin/admin-ajax.php foi excluído da condição porque funções das páginas públicas, como formulários de contato e rolagem infinita, podem chamá-lo sem login.

Exemplo 2: sem IP fixo, restrinja por país e Managed Challenge

(http.request.uri.path eq "/wp-login.php" or http.request.uri.path eq "/xmlrpc.php")
and not ip.src.country in {"JP"}

Para identificar o país, use ip.src.country (código de 2 letras da ISO 3166-1). O ip.geoip.country de artigos antigos está obsoleto. Quanto à ação, comece com Managed Challenge, veja nos eventos de segurança se algum acesso legítimo está sendo barrado e, se necessário, mude para Block. A documentação da Cloudflare também recomenda esse caminho. O xmlrpc.php é usado por quem publica pelo Jetpack ou por aplicativos de celular, então verifique se você o usa antes de incluí-lo na condição.

A restrição por país é um reforço que pode ser contornado com VPN. Combine-a com autenticação em dois fatores e limite de tentativas de login. O método para identificar o país no Nginx é explicado em Como restringir o acesso por país no Nginx com GeoIP2.

Passo 5: comportamento padrão do cache e limpeza ao publicar

Por padrão, a Cloudflare não faz cache de HTML. Ela guarda em cache arquivos estáticos definidos pela extensão, como imagens, CSS, JavaScript e fontes. Respostas que contêm o cabeçalho Set-Cookie também não entram no cache. Por isso, se você não configurar nada, o painel e a tela de login nunca ficam em cache na Cloudflare.

Se quiser fazer cache também do HTML, amplie o alcance com Cache Rules, mas então será preciso excluir /wp-admin/, /wp-login.php, as pré-visualizações e as telas de usuários logados. Se errar a exclusão, telas voltadas para administradores podem ser exibidas a outras pessoas; por isso, se não tiver certeza, o mais seguro é manter o padrão.

Se você trocou um CSS ou uma imagem e a exibição não mudou, faça a limpeza (purge) nas configurações de cache do painel. Para limpar automaticamente a cada publicação ou atualização de um post, chame a API da Cloudflare. Primeiro, crie na Cloudflare um token de API com apenas a permissão "Cache Purge" e escreva-o, junto com o ID da zona (exibido na página de visão geral do domínio), como constantes no wp-config.php.

define( 'CF_ZONE_ID', 'ID_DA_ZONA' );
define( 'CF_API_TOKEN', 'TOKEN_DA_API' );

Coloque o código a seguir no functions.php do tema filho ou em um pequeno plugin próprio (também pode ser no Code Snippets e similares).

<?php
// Ao publicar ou atualizar um post, apaga da Cloudflare o cache desse artigo e da página inicial
function cf_purge_urls(array $urls): bool
{
    if (!defined('CF_ZONE_ID') || !defined('CF_API_TOKEN')) {
        return false;
    }

    $response = wp_remote_post(
        'https://api.cloudflare.com/client/v4/zones/' . CF_ZONE_ID . '/purge_cache',
        [
            'headers' => [
                'Authorization' => 'Bearer ' . CF_API_TOKEN,
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode(['files' => array_values($urls)]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('Cloudflare purge failed: ' . $response->get_error_message());
        return false;
    }

    $result = json_decode(wp_remote_retrieve_body($response), true);
    return !empty($result['success']);
}

add_action('publish_post', function (int $post_id): void {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    cf_purge_urls([get_permalink($post_id), home_url('/')]);
});

O publish_post é disparado quando um post é publicado e quando um post já publicado é atualizado. A API purge_cache aceita, além de files (que indica as URLs), o purge_everything, que limpa tudo; porém, a limpeza total obriga a buscar de novo também todos os arquivos estáticos, então não a use a cada publicação de artigo.

O que verificar depois da troca

O resultado de curl -sI mostra server: cloudflare e cf-ray, e o navegador exibe o cadeado
Você consegue entrar no painel, salvar posts e enviar arquivos de mídia
Os novos comentários e os logs de acesso registram o IP do visitante, e não o IP da Cloudflare
Os e-mails do formulário de contato chegam (o registro MX não está atrás do proxy)
Se você criou regras personalizadas do WAF, abra o wp-login.php a partir de uma conexão não autorizada (por exemplo, a rede móvel do celular) e veja se aparece bloqueio ou desafio

Problemas comuns

Aparece ERR_TOO_MANY_REDIRECTS

Verifique se o modo SSL/TLS não está em Flexible. Instale um certificado na origem e mude para Full (strict) para resolver.

Não consigo mais entrar no painel

Pode ser que o seu IP ou o seu país não esteja incluído na condição da regra personalizada do WAF. No painel da Cloudflare, desative a regra temporariamente, veja nos eventos de segurança qual regra barrou o acesso e só depois corrija a expressão.

Todos os acessos aparecem com o mesmo IP

A restauração do IP real do passo 3 não está funcionando. No Nginx, confira os intervalos de set_real_ip_from e o real_ip_header; no Apache, confira se o remoteip está ativado.

Resumo

Troque os servidores de nomes pelos dois atribuídos à sua conta e não coloque no proxy os registros de e-mail, como o MX
Use SSL/TLS em Full (strict). O Flexible causa loops de redirecionamento e conteúdo misto
Restaure o IP real confiando no CF-Connecting-IP somente quando a origem da conexão estiver nos intervalos da Cloudflare
Restrinja o login por IP ou país com regras personalizadas do WAF e comece com Managed Challenge para observar
O HTML não entra em cache por padrão. A limpeza na publicação é feita com um token de API que tenha apenas a permissão "Cache Purge"