Resposta rápida
Use Invalidate Cache quando o objetivo é atualizar um conjunto de arquivos que pode ter itens inalterados. A Cloudflare mantém as cópias, marca o conteúdo como stale e, no próximo acesso, consulta a origem com ETag ou Last-Modified. Se a origem responder 304 Not Modified, o arquivo armazenado é reutilizado em vez de ser baixado novamente.
Use Purge quando a versão antiga não pode ser entregue outra vez, como depois de remover conteúdo sensível, revogar um arquivo ou corrigir uma resposta incorreta. O purge exclui a cópia da borda e força uma busca completa na origem no próximo acesso. Invalidation não é substituto seguro para remoção urgente, porque conteúdo stale ainda pode ser servido durante a revalidação ou se a origem falhar.
O que mudou em 28 de setembro
A Cloudflare lançou a invalidação de cache em 28 de setembro de 2026. O recurso, também chamado de soft purge, está disponível no painel em Caching e Configuration e por um novo endpoint invalidate_cache. Ele aceita os mesmos seletores do purge: URLs, cache tags, hostnames, prefixos e todo o conteúdo.
A diferença não está no filtro, mas no destino do objeto. O purge remove o conteúdo correspondente. A invalidação o conserva como stale e transfere a decisão para a próxima requisição condicional. Essa mudança pode reduzir tráfego de saída e trabalho da origem em catálogos, imagens e ativos versionados quando apenas parte do grupo realmente mudou.
Invalidate e purge não produzem o mesmo resultado
Depois de um purge, a próxima solicitação precisa obter a resposta completa da origem. Depois de uma invalidação, a Cloudflare envia uma requisição condicional com o validador conhecido. Uma resposta 304 renova o TTL sem transferir o corpo; uma resposta nova e cacheável substitui a cópia anterior.
A invalidação não faz prefetch. Nenhum conteúdo é atualizado quando o comando é enviado; a primeira solicitação posterior inicia a revalidação. Se o objeto já saiu do cache, não tem ETag nem Last-Modified ou a origem não entende requisições condicionais, a Cloudflare precisa buscar a resposta completa como faria em um cache miss.
Quando escolher purge
Escolha purge quando servir a versão anterior, mesmo por pouco tempo, cria risco operacional, jurídico ou de segurança. Atualize ou remova primeiro o conteúdo na origem e só depois execute o purge; caso contrário, a solicitação seguinte pode armazenar novamente a mesma versão antiga.
- Remova imediatamente um arquivo que não deveria continuar público.
- Revogue uma resposta com dado sensível, permissão errada ou informação incorreta.
- Interrompa a entrega de um ativo comprometido ou de uma configuração insegura.
- Use purge quando a origem não oferece validadores confiáveis ou revalidação condicional.
- Selecione a menor URL, tag, hostname ou prefixo que resolve o incidente.
Quando escolher invalidate
Escolha invalidate quando quer revisar um grupo amplo sem obrigar a origem a retransmitir todos os objetos. É especialmente útil para uma cache tag compartilhada por imagens de produtos, documentos ou ativos de uma implantação em que somente parte dos arquivos mudou.
Antes de usar, confirme que a origem envia ETag ou Last-Modified e responde corretamente a If-None-Match ou If-Modified-Since. Sem esse contrato, a operação continua válida, mas perde o principal benefício: os objetos inalterados serão baixados novamente.
- Teste um ativo cacheável e confirme ETag ou Last-Modified na resposta da origem.
- Valide que uma requisição condicional retorna 304 quando o conteúdo não mudou.
- Prefira URL ou tag específica em vez de invalidar toda a zona.
- Revise stale-while-revalidate e stale-if-error antes de aceitar conteúdo antigo durante falhas.
- Monitore tráfego, erros 5xx e latência da origem durante a primeira onda de acessos.
Como invalidar pelo painel e pela API
No painel, abra Caching, Configuration e Invalidate Cache. Em Custom Invalidation, selecione URL, Hostname, Tag ou Prefix e informe apenas o conjunto necessário. Em zonas com Version Management, confira o ambiente selecionado antes de confirmar, porque a operação de produção pode alcançar mais de um ambiente conforme a configuração.
Pela API, envie POST para https://api.cloudflare.com/client/v4/zones/{zone_id}/invalidate_cache com um token que tenha Cache Purge na zona. O corpo segue o formato do purge: files para URLs, tags para cache tags, hosts para hostnames, prefixes para prefixos ou purge_everything:true para tudo. O nome purge_everything continua no corpo mesmo quando o endpoint é invalidate_cache.
- Crie um token restrito à zona e à permissão Cache Purge; não use uma chave global em scripts.
- Envie files com a URL completa ou tags com a cache tag usada pela aplicação.
- Registre horário, seletor e resposta da API sem salvar o token no log.
- Evite purge_everything em rotinas automáticas; uma seleção ampla pode concentrar revalidações na origem.
Como verificar se a invalidação funcionou
Use uma URL de teste cacheável, com TTL positivo e ETag ou Last-Modified. Acesse até CF-Cache-Status indicar HIT, invalide a URL e faça uma nova solicitação observando os cabeçalhos. Confirme também nos logs da origem se a Cloudflare enviou a requisição condicional e recebeu 304; um único status visto pelo visitante não prova sozinho o caminho completo.
Quando o conteúdo não mudou, o resultado esperado pode passar por REVALIDATED e voltar a HIT. Conteúdo novo tende a mostrar EXPIRED e depois HIT. UPDATING indica entrega stale durante revalidação, STALE pode aparecer quando a origem falha e MISS indica que o objeto não estava mais armazenado. Tiered Cache e requisições concorrentes podem alterar o status observado na borda.
- Use curl -I ou curl --dump-header para registrar os cabeçalhos antes da mudança.
- Execute a invalidação somente na URL ou tag de teste.
- Repita a solicitação e compare CF-Cache-Status, Age, ETag e Last-Modified.
- Confira o 304 e os cabeçalhos condicionais nos logs da origem.
- Teste novamente depois da revalidação e confirme a volta para HIT.
Stale, Workers Cache e Cache Reserve exigem atenção
A Cloudflare pode entregar a cópia stale enquanto revalida ou quando a origem retorna 5xx ou não responde. Para impedir esse comportamento em conteúdo crítico, use purge e revise as diretivas de cache. stale-if-error=0 evita a entrega stale em falha; com Origin Cache Control ativo, must-revalidate, proxy-revalidate e s-maxage também podem impedir esse uso conforme a documentação.
A invalidação da zona não afeta o Workers Cache criado pelo Worker. Esse cache precisa ser tratado pelo próprio Worker com ctx.cache.purge(). No Cache Reserve, a invalidação mantém o objeto armazenado e ele continua gerando custo de armazenamento; revalidações e atualizações podem produzir operações de escrita. Considere esses efeitos antes de trocar purge por invalidate em grande volume.
Limites e próxima ação útil
Este guia foi verificado em 29 de setembro de 2026. Purge e invalidate compartilham os mesmos limites da conta, e uso intenso de uma operação reduz a capacidade disponível para a outra. Os valores variam por plano e por seletor; consulte a tabela oficial em vez de fixar números em uma automação.
Comece com uma única URL de baixo risco. Confirme os validadores da origem, compare os cabeçalhos, execute invalidate e verifique o 304 nos logs. Só depois amplie para uma tag ou prefixo. Se a origem estiver instável ou retornar 5xx, consulte o Cloudflare Status e faça um diagnóstico HTTP antes de disparar uma operação ampla que aumente a carga.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Invalidate cached content instead of purging itCloudflare Changelog
- Invalidate cached contentCloudflare Docs
- Purge cacheCloudflare Docs
- RevalidationCloudflare Docs
- Cache ReserveCloudflare Docs
- Cloudflare StatusCloudflare