Cabeçalhos da Cloudflare: o que significam cf-cache-status, cf-ray e outros

Você colocou o seu site WordPress atrás da Cloudflare e quer saber se a CDN está mesmo fazendo alguma coisa. De repente, as respostas do seu servidor trazem linhas como cf-cache-status: DYNAMIC ou cf-ray: 8f2a1c3d4e5f6a7b-FRA. Esses cabeçalhos funcionam como uma espécie de bula da Cloudflare: eles mostram se um arquivo veio do cache, qual data center respondeu e se alguma regra de segurança interferiu. Aqui você descobre o que cada valor significa e que conclusões pode tirar dele para o seu site.

O que são os cabeçalhos da Cloudflare e como ver os cabeçalhos HTTP do seu site?

A Cloudflare fica entre os seus visitantes e o seu servidor, funcionando como proxy. Toda requisição passa pela rede da Cloudflare e, no caminho, recebe cabeçalhos extras. Alguns deles aparecem no navegador dos seus visitantes, outros chegam apenas ao seu servidor. Como uma rede desse tipo funciona em geral, você confere no nosso artigo O que é uma CDN?.

O jeito mais rápido de ver os cabeçalhos é pelas ferramentas de desenvolvedor do seu navegador. Abra a aba “Rede”, recarregue a página e clique na primeira linha. No terminal é ainda mais rápido:

curl -sI https://example.com/

A resposta vai ser mais ou menos assim:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=0
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 8f2a1c3d4e5f6a7b-FRA

Se não aparece nenhuma linha começando com cf-, a requisição nem passa pela Cloudflare. Na maioria dos casos, o registro DNS está configurado como “DNS only” (nuvem cinza) em vez de “Proxied” (nuvem laranja).

O que significa cf-cache-status? Todos os valores explicados

O cabeçalho cf-cache-status é o mais importante de todos. Ele mostra como a Cloudflare tratou exatamente essa resposta. A documentação oficial lista nove valores:

• HIT: O arquivo estava no cache e veio direto da Cloudflare. O seu servidor nem ficou sabendo. É esse o valor que você quer ver.
• MISS: O arquivo pode ser armazenado em cache, mas ainda não estava neste data center. A Cloudflare buscou o arquivo no seu servidor. Na próxima requisição, deve aparecer HIT.
• EXPIRED: O arquivo estava no cache, mas tinha expirado. A Cloudflare buscou uma versão nova no seu servidor.
• REVALIDATED: A cópia no cache tinha expirado. A Cloudflare perguntou ao seu servidor se algo tinha mudado, e a resposta foi não. Ou seja, o arquivo veio do cache, mas o visitante precisou esperar por essa consulta.
• UPDATING: A cópia tinha expirado e mesmo assim foi entregue na hora, enquanto a Cloudflare a atualiza em segundo plano. Isso acontece quando o seu servidor envia stale-while-revalidate.
• STALE: A Cloudflare entregou uma cópia expirada porque o seu servidor não estava acessível. É um sinal de alerta que você deve levar a sério.
• BYPASS: Em princípio, o arquivo seria candidato ao cache, mas a resposta do seu servidor impediu isso, por exemplo por causa de um cookie.
• DYNAMIC: A Cloudflare nem chegou a consultar o cache, porque, pelas regras em vigor, esse conteúdo não é armazenado em cache.
• NONE/UNKNOWN: A Cloudflare gerou a resposta por conta própria, por exemplo em um redirecionamento para HTTPS, em um bloqueio do firewall ou em um Worker.

Bom saber: desde 26 de maio de 2026, a Cloudflare separa dois desses valores de forma mais clara. Antes, algumas respostas que não podiam ser armazenadas em cache recebiam MISS em toda requisição. Desde a mudança, aparece sempre BYPASS nesses casos. Agora MISS significa apenas: pode ser armazenado em cache, mas não está lá no momento. Muitos tutoriais mais antigos na internet ainda descrevem o comportamento anterior.

Por que o seu site WordPress mostra cf-cache-status: DYNAMIC?

Essa é a pergunta mais comum sobre o assunto, e a resposta é tranquilizadora: em uma página WordPress comum, DYNAMIC é o normal. Na configuração padrão, a Cloudflare não armazena HTML nem JSON em cache. A decisão é tomada pela extensão do arquivo, não pelo conteúdo. Imagens, CSS, JavaScript, fontes e PDFs vão para o cache, o HTML das suas páginas não.

Existe um bom motivo para isso. O WordPress gera as páginas de forma dinâmica, e a Cloudflare não tem como saber se o HTML contém naquele momento um carrinho de compras, uma barra de administração ou uma saudação personalizada. Se ela armazenasse essas páginas em cache sem que ninguém pedisse, no pior dos casos um visitante veria o carrinho de outra pessoa.

Já as suas imagens e scripts devem retornar HIT. Por isso, não confira só a página inicial, mas também um arquivo CSS ou uma imagem.

Se você quer que a Cloudflare entregue também o HTML, existem dois caminhos:

• Cache Rule: Você cria no painel uma regra que marca o HTML como “Eligible for cache”. Aí fica por sua conta garantir que usuários logados, a área administrativa, o carrinho e o checkout continuem excluídos.
• APO para WordPress: A Automatic Platform Optimization cuida dessas exceções para você e limpa o cache assim que você altera um post. Mais detalhes abaixo.

Se DYNAMIC aparece também em imagens ou CSS, a causa costuma ser uma regra com “Bypass cache” ou o Development Mode. Ele desativa o cache por completo durante três horas, e é fácil esquecer que ele está ligado.

cf-cache-status BYPASS ou sempre MISS: qual é a causa?

Com BYPASS, a Cloudflare queria armazenar em cache, mas a resposta do seu servidor não permitiu. O guia de solução de problemas cita principalmente estas causas:

• A resposta contém um cabeçalho Set-Cookie. No WordPress, esse é o caso clássico: uma loja, um plugin para sites multilíngues ou um plugin de rastreamento define um cookie em toda requisição, e pronto, nada mais vai para o cache.
• O seu servidor envia Cache-Control: no-store ou private.
• A resposta contém Vary: *.
• O arquivo é maior que o limite do seu plano (512 MB nos planos Free, Pro e Business).

Se toda requisição continua dando MISS, o arquivo até pode ser armazenado em cache, mas a Cloudflare nunca o encontra de novo. Por trás disso costumam estar parâmetros variáveis no endereço, como utm_source ou um ID de sessão, porque cada variação conta como um arquivo separado. Em sites com poucos visitantes, arquivos raramente acessados também saem do cache mais cedo. E cada data center tem o seu próprio cache: se duas requisições chegam a locais diferentes, você vê MISS duas vezes.

Uma boa ajuda é o cabeçalho Age. Ele informa, em segundos, há quanto tempo a cópia está no cache. Se você acessa um arquivo duas vezes seguidas e vê HIT com um Age crescente, está tudo funcionando.

O que o cabeçalho cf-ray revela?

Toda requisição que passa pela Cloudflare recebe um identificador próprio, o Ray ID. Ele aparece no cabeçalho cf-ray e tem duas partes: uma sequência de caracteres e um código de três letras. O código indica o data center que respondeu. FRA significa Frankfurt, AMS Amsterdã, CDG Paris.

No dia a dia, o Ray ID ajuda você em três situações. Quando a Cloudflare mostra uma página de erro a um visitante, o Ray ID aparece no rodapé da página, e com ele você encontra exatamente essa requisição nos logs ou nos Security Events. Em segundo lugar, pelo código você vê se os seus visitantes realmente chegam a um local próximo. E em terceiro lugar, ele esclarece muitos MISS misteriosos, quando duas requisições chegaram a data centers diferentes.

A Cloudflare, aliás, também envia o mesmo Ray ID para o seu servidor. Se você gravar esse valor no log de lá, consegue acompanhar uma requisição do navegador até o PHP.

cf-apo-via e cf-edge-cache: o APO para WordPress está funcionando?

Se você usa a Automatic Platform Optimization, aparecem mais dois cabeçalhos. Segundo a Cloudflare, você reconhece uma configuração que funciona por três linhas:

• cf-cache-status: HIT mostra que o HTML veio do cache.
• cf-apo-via: tcache mostra que o APO atendeu a requisição.
• cf-edge-cache: cache,platform=wordpress confirma que o plugin da Cloudflare está instalado e ativo no WordPress.

Se cf-edge-cache estiver ausente, geralmente o plugin está desativado ou não está conectado à sua conta. Se cf-apo-via mostrar um valor diferente de tcache, o APO não entregou a página a partir do cache, por exemplo porque você está logado. Por isso, teste sempre em uma janela anônima.

O que significa cf-mitigated: challenge?

Esse cabeçalho só aparece quando a Cloudflare entrega uma página de desafio no lugar da sua página, aquele aviso conhecido de que o visitante está sendo verificado por um instante. challenge é o único valor válido.

Para as pessoas, isso costuma ser só um pequeno atraso. Para tudo o que acessa o seu site de forma automática, é um obstáculo real. A página de desafio é sempre HTML, mesmo quando a requisição pedia JSON. Se o seu próprio JavaScript chama a REST API e de repente recebe uma página de desafio, ele cai em um erro que, sem esse cabeçalho, você dificilmente conseguiria entender. O mesmo vale para serviços de monitoramento, provedores de pagamento com webhooks e ferramentas de análise. Se você vê cf-mitigated: challenge em acessos que deveriam passar, vale a pena olhar os Security Events no painel. Lá aparece qual regra foi acionada.

Quais cabeçalhos da Cloudflare chegam ao seu servidor?

Nem todos os cabeçalhos são destinados ao navegador. A Cloudflare adiciona alguns deles à requisição antes que ela chegue ao seu servidor. A lista completa é longa, mas para o WordPress estes são os mais importantes:

• CF-Connecting-IP: o endereço IP real do visitante. Sem esse cabeçalho, o seu servidor vê apenas endereços da Cloudflare.
• X-Forwarded-For: a cadeia de todos os proxies pelos quais a requisição passou. Para o endereço do visitante, a Cloudflare recomenda ler de preferência CF-Connecting-IP.
• X-Forwarded-Proto e CF-Visitor: mostram se o visitante chegou via HTTP ou HTTPS.
• CF-IPCountry: o país do visitante como código de duas letras. XX significa desconhecido, T1 indica a rede Tor.
• CDN-Loop: impede que uma requisição fique rodando em círculos pela Cloudflare sem parar.

O endereço IP real é mais do que um detalhe. Plugins de segurança bloqueiam atacantes pelo endereço IP, o WordPress salva esse endereço junto com os comentários, e a sua hospedagem o analisa nos logs. Se lá chega apenas o endereço da Cloudflare, o seu plugin pode acabar bloqueando todos os visitantes de uma vez. A maioria das hospedagens e dos plugins de segurança pode ser configurada para isso. Um ponto importante: só confie no cabeçalho se a requisição vier de fato de um endereço da rede da Cloudflare. Caso contrário, qualquer pessoa pode escrever o endereço IP que quiser no cabeçalho.

Uma fonte de erro bem conhecida também está ligada a isso. Com a configuração de SSL “Flexible”, a Cloudflare se comunica com o seu servidor sem criptografia. O WordPress então acha que o visitante chegou via HTTP, redireciona para HTTPS e surge um loop infinito. A solução correta é um certificado no servidor e a configuração “Full (strict)”.

Como usar o Cache-Control para controlar o que a Cloudflare guarda em cache?

Quanto tempo a Cloudflare guarda um arquivo é decidido, antes de tudo, pelo seu servidor. Para isso existem três cabeçalhos, que a Cloudflare avalia nesta ordem:

1. Cloudflare-CDN-Cache-Control vale apenas para a Cloudflare e não é repassado ao navegador.
2. CDN-Cache-Control vale para todas as CDNs no caminho.
3. Cache-Control vale para os navegadores e, se os outros dois estiverem ausentes, também para a Cloudflare.

Assim você controla o navegador e a CDN separadamente. Um exemplo: o navegador deve guardar um arquivo por apenas uma hora, a Cloudflare por um dia inteiro.

Cache-Control: max-age=3600
Cloudflare-CDN-Cache-Control: max-age=86400

Se o seu servidor não envia nenhuma instrução, valem os valores padrão. Respostas com status 200 e 301 ficam 120 minutos no cache, redirecionamentos com 302 e 303 apenas 20 minutos, erros com 404 e 410 três minutos. Este último ponto surpreende muita gente: se você fizer o upload de uma imagem que estava faltando, a Cloudflare ainda pode entregar a mensagem de erro antiga por alguns minutos.

Que outros cabeçalhos a Cloudflare adiciona?

Além das linhas mais conhecidas, talvez você note mais algumas:

• server: cloudflare substitui a identificação do seu servidor web. De fora, ninguém mais consegue ver se por trás roda Apache, nginx ou LiteSpeed.
• report-to e nel fazem parte do Network Error Logging. Por meio deles, o navegador informa erros de conexão à Cloudflare. O recurso pode ser desativado no painel, o que é interessante para alguns sites do ponto de vista da proteção de dados.
• alt-svc avisa o navegador de que o site também pode ser acessado via HTTP/3. A Cloudflare remove um cabeçalho alt-svc próprio do seu servidor.

Alguns cabeçalhos do seu servidor, por sinal, nunca chegam ao visitante. Entre eles estão Cache-Tag e os cabeçalhos X-Accel do nginx. Então não estranhe se você procurar por eles no navegador e não encontrar.

Como verificar os cabeçalhos da Cloudflare com o InspectWP?

Ao criar um relatório, o InspectWP lê os cabeçalhos do seu site e mostra, na seção “Cabeçalhos”, entre outros, cf-cache-status e cf-ray. Assim, sem abrir o terminal, você vê se o seu site passa pela Cloudflare e como a página inicial foi entregue. Além disso, aparecem os valores relacionados ao cache: a compressão, a versão do HTTP e os cabeçalhos de segurança.

Isso é especialmente útil quando você cuida de vários sites. Com os relatórios automáticos, você percebe quando uma página de repente deixa de vir do cache ou quando a Cloudflare nem está mais na frente do site depois de uma migração. Se uma página de desafio da Cloudflare bloquear a varredura, o InspectWP avisa você. No nosso artigo de ajuda O que fazer quando a varredura falha, você vê como ajustar a proteção contra bots para isso. Um relatório gratuito mostra em pouco tempo quais cabeçalhos o seu site está enviando neste momento.