Cache do Varnish no Magento 2 exibe página antiga? Faça 9 testes antes de limpar tudo

Cache Varnish Magento 2 pode ser a origem de produtos, preços, banners e páginas que continuam antigos mesmo após uma atualização no Admin. Entretanto, o conteúdo também pode estar retido no cache interno da aplicação, CDN, navegador ou até em um bloco personalizado que não foi invalidado corretamente.

Antes de reiniciar o Varnish ou executar uma limpeza geral, escolha uma URL afetada, registre a alteração esperada e faça os testes abaixo. O objetivo é localizar a camada que ainda entrega a versão anterior sem prejudicar todo o tráfego da loja.

Cache Varnish Magento 2: confirme o que está desatualizado

Comece delimitando o sintoma. Anote a URL, visão de loja, horário da alteração e conteúdo esperado. Verifique se o problema afeta apenas um produto, uma categoria, a página inicial ou várias áreas do site.

Compare também visitantes, clientes autenticados e uma janela anônima. O Magento trata algumas informações privadas, como minicarrinho e dados do cliente, separadamente do conteúdo público armazenado pelo cache de página completa. Se apenas um usuário enxerga dados antigos, o Varnish pode não ser o responsável.

1. Descubra se a alteração chegou ao banco e à aplicação

Abra o produto, bloco ou configuração no Admin e confirme se os dados salvos estão corretos na visão de loja afetada. Em instalações com múltiplos sites, uma mudança feita no escopo global pode ser sobrescrita por um valor específico da loja.

Se preços, categorias ou atributos dependem de indexação, verifique os indexadores:

bin/magento indexer:status

Um índice atrasado pode fazer a aplicação gerar conteúdo antigo novamente. Nesse caso, limpar o Varnish apenas mascara o problema até a página voltar a ser armazenada. Se a atualização depende de processamento agendado, consulte também o diagnóstico para quando o cron do Magento 2 parou.

2. Compare a resposta pública com uma requisição controlada

Faça uma requisição aos cabeçalhos da URL afetada. Execute o comando duas vezes para comparar as respostas:

curl -sI https://www.exemplo.com.br/produto.html
curl -sI https://www.exemplo.com.br/produto.html

Procure cabeçalhos relacionados a idade, cache, proxy ou depuração, quando estiverem disponíveis. Nomes como Age, Via, X-Cache ou X-Magento-Cache-Debug podem ajudar, mas variam conforme a configuração do Varnish, do proxy, da CDN e do servidor web.

Não conclua que houve falha apenas porque um cabeçalho não apareceu. Muitas infraestruturas removem essas informações na borda por decisão operacional ou de segurança.

3. Verifique se o Magento está configurado para usar o Varnish

Consulte o estado dos caches e a configuração da aplicação de cache de página completa:

bin/magento cache:status
bin/magento config:show system/full_page_cache/caching_application

Compare o resultado com a arquitetura esperada para o ambiente. Também confirme no Admin a configuração de cache de página completa e os hosts usados para invalidação. É possível ter o Varnish ativo na infraestrutura enquanto o Magento está configurado de outra forma, impedindo o envio correto das solicitações de limpeza.

Evite alterar essa opção diretamente em produção sem conhecer o fluxo entre balanceador, CDN, Varnish e servidor de origem.

4. Confirme que o tráfego realmente atravessa o Varnish

Revise o caminho completo da requisição: DNS, CDN, balanceador, Varnish, Nginx ou Apache e PHP-FPM. Uma mudança de proxy, porta ou upstream pode desviar parte do tráfego e criar resultados inconsistentes.

Quando houver mais de um nó, teste repetidamente e registre os cabeçalhos. Se o conteúdo alternar entre novo e antigo, investigue se todos os nós utilizam a mesma configuração e recebem as invalidações. Reiniciar um único servidor não resolve uma inconsistência distribuída.

5. Limpe somente o cache de página completa

Depois de preservar as evidências, faça uma limpeza direcionada:

bin/magento cache:clean full_page

O comando cache:clean atua sobre o tipo indicado sem a abrangência de uma limpeza indiscriminada do armazenamento. Teste novamente a URL e observe se a primeira resposta mostra o conteúdo correto.

Evite começar com cache:flush. Dependendo da arquitetura, ele pode remover mais dados do armazenamento compartilhado do que o necessário, aumentar a carga na origem e apagar pistas úteis para o diagnóstico.

6. Teste se a invalidação automática está chegando ao Varnish

Altere um conteúdo controlado em homologação ou em uma página de baixo impacto, limpe apenas o cache correspondente pelo fluxo normal do Magento e acompanhe os registros do Varnish e do servidor web.

O teste deve responder a três perguntas:

• o Magento iniciou uma solicitação de invalidação;
• a solicitação chegou ao host e à porta esperados;
• o Varnish removeu ou marcou como inválidos os objetos relacionados.

Falhas de rede, hosts incorretos, regras de acesso ou uma VCL incompatível podem interromper esse caminho. Não abra permissões amplas para requisições de limpeza: a invalidação deve ser aceita apenas de origens autorizadas.

7. Investigue tags ausentes em módulos e blocos personalizados

O Magento associa identidades de cache aos conteúdos para invalidar páginas relacionadas quando uma entidade muda. Extensões e blocos personalizados que não fornecem as identidades adequadas podem permanecer armazenados depois da edição de um produto, categoria ou bloco CMS.

Se o problema ocorre somente em um componente personalizado, compare o comportamento com um bloco nativo. Revise a implementação do módulo, as tags produzidas e as configurações de cache do bloco. Desativar todo o cache permanentemente não é uma correção aceitável: reduz a capacidade da loja e esconde a falha de invalidação.

8. Separe Varnish, navegador e CDN

Uma página correta no servidor pode continuar antiga no navegador ou na CDN. Teste em janela anônima, outro dispositivo e uma requisição direta à origem somente quando isso for permitido pela infraestrutura.

Revise cabeçalhos como Cache-Control, Expires e Age. Se houver CDN, verifique suas regras de TTL e purge. Parâmetros de URL, cookies e variações de protocolo ou domínio também podem gerar objetos diferentes para uma página aparentemente igual.

Tenha cuidado ao contornar proxies em produção. A origem pode não estar preparada para receber tráfego público direto, e testes sem o cabeçalho de host correto podem produzir conclusões erradas.

9. Verifique erros na geração da página depois da limpeza

Quando o objeto antigo é removido, a próxima visita precisa gerar uma nova resposta na aplicação. Se esse processo falhar, o Varnish pode entregar conteúdo em grace, retornar erro ou apresentar um comportamento diferente conforme a VCL.

Correlacione o horário do teste com os logs do Magento, PHP-FPM, servidor web e Varnish. Caso a limpeza revele uma resposta HTTP 500, siga um processo de diagnóstico que preserve os registros, como o roteiro para encontrar a causa do erro 500 no Magento 2.

Sequência segura para corrigir páginas antigas

1. registre URL, escopo, horário e conteúdo esperado;
2. confirme o dado no Admin e o estado dos indexadores;
3. compare respostas por navegador e curl;
4. identifique as camadas de cache percorridas;
5. execute uma limpeza restrita ao cache de página completa;
6. teste a invalidação automática;
7. revise VCL, hosts e personalizações se o problema retornar;
8. homologue a correção antes de alterar produção.

Após a correção, valide página inicial, categorias, produtos, busca, carrinho e checkout. A limpeza do cache não deve comprometer sessões ou dados privados. Se o carrinho ou pagamento apresentar carregamento contínuo, use os testes específicos para checkout do Magento 2 que fica carregando.

Conclusão

Um problema de cache Varnish Magento 2 não deve ser tratado apenas com reinicializações e limpezas gerais. A correção duradoura depende de identificar onde o conteúdo ficou retido, verificar se a invalidação funciona e confirmar que módulos personalizados produzem as tags adequadas.

Se as páginas antigas retornam depois da limpeza ou o ambiente possui CDN, múltiplos nós e integrações personalizadas, uma análise técnica pode reduzir o risco de indisponibilidade. A equipe do Suporte Magento pode auxiliar no diagnóstico da aplicação e da infraestrutura.

Perguntas frequentes sobre cache Varnish Magento 2

Posso reiniciar o Varnish para atualizar todas as páginas?

O reinício pode remover objetos ou interromper o serviço, conforme a configuração, mas não corrige a causa da invalidação defeituosa. Prefira identificar a URL afetada e executar uma limpeza direcionada.

Qual é a diferença entre cache:clean e cache:flush?

O cache:clean limpa os tipos de cache selecionados pelo Magento. O cache:flush esvazia o armazenamento associado e pode afetar outros dados quando o backend é compartilhado. Por isso, não deve ser a primeira ação.

Por que a página antiga volta depois de limpar o cache?

Isso pode ocorrer quando o índice continua desatualizado, a origem gera novamente o conteúdo antigo, uma CDN mantém outra cópia ou o módulo não associa as tags corretas à página.

O Varnish deve armazenar páginas de carrinho e checkout?

Áreas privadas e sensíveis não devem ser tratadas como páginas públicas comuns. O comportamento efetivo depende das regras do Magento, da VCL e das personalizações, que precisam ser verificadas durante a homologação.