O Varnish no Magento 2 pode estar instalado, ativo e aparentemente saudável, mas ainda assim devolver MISS em todas as requisições. Quando isso acontece, a loja continua processando páginas no backend com mais frequência do que deveria, aumentando o trabalho do PHP, do banco de dados e dos demais serviços.
Nem todo MISS, porém, representa uma falha. Checkout, carrinho, conta do cliente e outras páginas personalizadas não devem ser tratadas como conteúdo público. O diagnóstico correto consiste em testar uma URL que possa ser armazenada, repetir a requisição nas mesmas condições e descobrir qual camada está impedindo o HIT.
O que HIT, MISS e BYPASS indicam no Varnish?
Os nomes exatos dos cabeçalhos variam conforme a VCL, o proxy, a CDN e a infraestrutura. Em termos práticos, os estados normalmente indicam:
- HIT: o objeto foi encontrado no cache e pôde ser entregue sem uma nova geração completa pelo Magento.
- MISS: o objeto não estava disponível para aquela requisição. A primeira visita pode gerar um MISS legítimo e armazenar a resposta para a próxima.
- BYPASS ou PASS: a requisição não é elegível para cache ou alguma regra determinou que ela deveria chegar ao backend.
Um teste isolado não basta. A primeira requisição pode preencher o cache; a segunda, feita com os mesmos parâmetros e sem cookies de sessão, é a que ajuda a confirmar se o objeto pode ser reutilizado.
Varnish no Magento 2: faça estes 8 testes
1. Confirme se o Magento está configurado para usar Varnish
No diretório da aplicação, consulte a configuração com o mesmo usuário responsável pela manutenção do Magento:
php bin/magento config:show system/full_page_cache/caching_application
php bin/magento cache:statusO primeiro comando ajuda a verificar a aplicação selecionada para o cache de página inteira. O segundo mostra se os tipos de cache estão habilitados. Não altere o valor diretamente em produção antes de confirmar a topologia: selecionar Varnish no painel não instala o serviço, não configura portas e não garante que o tráfego passe por ele.
Se a configuração parece correta, mas alterações da loja não chegam à vitrine, também vale separar cache de indexação. Consulte o roteiro sobre indexadores Magento 2 travados antes de reindexar indiscriminadamente.
2. Verifique por onde a requisição realmente passa
Mapeie a sequência entre navegador, CDN, balanceador, Varnish, servidor web e PHP-FPM. Uma configuração correta não terá efeito se o DNS ou o proxy estiver encaminhando o tráfego diretamente para o backend.
Examine os cabeçalhos de uma página pública, preferencialmente uma categoria ou um produto disponível:
curl -sI https://www.exemplo.com.br/categoria-testeProcure cabeçalhos de cache definidos pela infraestrutura, valores de Age e sinais de múltiplos proxies. A ausência de um cabeçalho específico não prova que o Varnish esteja inativo, pois a VCL pode removê-lo. Compare também os logs de acesso do Varnish e do servidor web no mesmo horário.
3. Repita o teste sem cookies de sessão
Um navegador usado para acessar conta, carrinho ou Admin acumula cookies que podem tornar a resposta personalizada. Faça o diagnóstico em janela anônima ou pelo terminal, sem reutilizar cookies.
curl -sI https://www.exemplo.com.br/produto-teste
curl -sI https://www.exemplo.com.br/produto-testeExecute as duas chamadas em sequência e compare todos os cabeçalhos. Se a resposta permanece em MISS, registre se o backend está criando cookies mesmo para um visitante anônimo. Extensões de personalização, banners, geolocalização, consentimento ou integrações podem iniciar sessão cedo demais.
4. Confira se a resposta permite armazenamento
Analise principalmente Cache-Control, Set-Cookie, Vary e os cabeçalhos personalizados da sua VCL. Diretivas que marcam a resposta como privada ou impedem armazenamento podem explicar por que o objeto nunca chega ao cache.
Não remova essas diretivas globalmente para forçar um HIT. Elas podem proteger conteúdo individual, preços por grupo, dados de sessão e informações do cliente. Primeiro identifique qual módulo ou bloco produziu o cabeçalho e confirme se a página deveria ser pública.
5. Teste uma URL realmente elegível para cache
Não use carrinho, checkout, área do cliente, comparação personalizada ou uma rota administrativa como referência. Esses fluxos possuem conteúdo dependente da sessão e podem passar pelo backend por projeto.
Escolha uma página pública estável, sem parâmetros de campanha, filtros ou ordenações. Confirme ainda se a URL não redireciona. Um teste que começa em HTTP, passa por HTTPS e termina em outra versão da URL pode produzir resultados diferentes em cada etapa.
6. Procure parâmetros que fragmentam a chave de cache
Parâmetros de URL podem criar objetos distintos. Se cada requisição chega com uma combinação diferente de identificadores de campanha, moeda, store view, ordenação ou filtros, o Varnish pode nunca reutilizar o mesmo objeto.
Compare a URL canônica sem parâmetros com a versão observada no navegador:
curl -sI 'https://www.exemplo.com.br/categoria-teste'
curl -sI 'https://www.exemplo.com.br/categoria-teste?utm_source=teste'A normalização de parâmetros deve ser planejada com cautela. Remover elementos relevantes da chave pode fazer usuários receberem conteúdo incorreto. Documente quais parâmetros alteram de fato a resposta antes de ajustar a VCL.
7. Valide VCL, portas e comunicação com o backend
Confirme se a VCL carregada corresponde ao ambiente e à configuração atual da loja. Verifique endereço e porta do backend, regras de exclusão, timeouts e eventuais adaptações feitas para CDN ou balanceador.
Antes de substituir a VCL em produção:
- exporte e versione o arquivo atual;
- compare as diferenças com a nova configuração;
- valide a sintaxe;
- teste em staging com uma cópia representativa da loja;
- prepare retorno para a versão anterior.
Uma porta incorreta costuma causar indisponibilidade ou erro de conexão, e não apenas MISS. Se o diagnóstico terminar em resposta 503, use o procedimento específico para erro 503 no Magento 2 antes de reiniciar todos os serviços.
8. Investigue invalidações excessivas
Mesmo quando o cache funciona, ele pode ser invalidado com tanta frequência que quase toda visita encontra um objeto recém-removido. Observe se o problema coincide com importações, sincronizações de ERP, salvamento de produtos, atualizações de estoque, deploys ou rotinas próprias.
Correlacione horários dos MISS com logs de limpeza e banimento. Evite executar cache:flush repetidamente como tentativa genérica de correção: isso elimina objetos úteis e pode criar um pico de requisições no backend enquanto o cache é reconstruído.
Como diferenciar falha do Varnish e lentidão do backend
Se a primeira resposta é lenta e a segunda apresenta HIT com redução clara no tempo, o Varnish provavelmente está cumprindo sua função, mas a geração inicial da página continua cara. Nesse caso, investigue consultas, blocos não armazenáveis, chamadas externas, extensões e capacidade do PHP-FPM.
Se todas as respostas são MISS, concentre-se em elegibilidade, cookies, cabeçalhos, chave de cache e invalidações. Se nenhuma requisição aparece nos logs do Varnish, revise DNS e proxies. Já falhas limitadas ao painel exigem outro caminho: veja como diagnosticar quando o Admin do Magento 2 não abre.
O que registrar antes de alterar a configuração
Monte uma evidência mínima para evitar mudanças por tentativa e erro:
- URL exata e horário do teste;
- cabeçalhos completos de duas requisições consecutivas;
- presença de cookies e parâmetros;
- status HTTP e redirecionamentos;
- topologia entre CDN, Varnish e backend;
- versão da VCL carregada;
- eventos de limpeza ou invalidação no mesmo período;
- diferença entre visitante anônimo e cliente autenticado.
Esses dados ajudam a localizar a camada responsável sem desligar personalizações ou enfraquecer controles de sessão.
Perguntas frequentes sobre Varnish no Magento 2
Um MISS na primeira visita significa que o Varnish está quebrado?
Não. A primeira requisição pode gerar e armazenar o objeto. Repita o acesso à mesma URL, sem cookies e parâmetros diferentes, e compare os cabeçalhos.
O checkout deve retornar cache HIT?
Não é um teste adequado. Checkout, carrinho e conta possuem conteúdo associado à sessão e normalmente precisam chegar ao backend. Use uma categoria ou página de produto pública.
Limpar todo o cache corrige MISS permanente?
Em geral, não. A limpeza pode apenas reiniciar o ciclo de preenchimento. Se cookies, cabeçalhos ou regras impedem o armazenamento, a resposta continuará em MISS.
Posso remover todos os cookies da VCL para aumentar o HIT?
Não. Cookies podem controlar sessão, personalização e segurança. A remoção indiscriminada pode misturar contextos de usuários. Analise cada cookie e valide qualquer ajuste em staging.
Conclusão
Quando o Varnish no Magento 2 só retorna MISS, a solução não é forçar cache em todas as rotas. O caminho seguro é confirmar a passagem do tráfego, testar páginas públicas sem cookies, analisar cabeçalhos, validar a VCL e localizar invalidações excessivas.
Se a loja continua sobrecarregando o backend ou os cabeçalhos não deixam clara a origem do problema, uma análise conjunta da aplicação e da infraestrutura pode reduzir tentativas arriscadas. A equipe do SuporteMagento.com.br pode ajudar a revisar o fluxo de cache e preparar as correções em um ambiente controlado.
