Quando o Varnish no Magento 2 não retorna HIT, a loja pode encaminhar ao PHP requisições que deveriam ser atendidas pelo cache. O resultado costuma aparecer como maior tempo de resposta, aumento no consumo de CPU e lentidão mais perceptível durante picos de acesso.
Entretanto, um MISS isolado não comprova defeito. A primeira visita a uma página, uma invalidação recente, determinados cookies e áreas personalizadas podem impedir o reaproveitamento da resposta. Os nove testes abaixo ajudam a descobrir se existe uma falha real de configuração, encaminhamento, VCL ou política de cache.
O que HIT, MISS, PASS e BYPASS significam?
Antes de modificar o ambiente, é importante interpretar o comportamento observado. Os nomes exatos dos cabeçalhos dependem da infraestrutura e da VCL utilizada, mas os estados normalmente representam:
- HIT: a resposta foi encontrada no cache e entregue sem uma nova renderização completa pelo Magento.
- MISS: o objeto ainda não estava disponível, expirou ou foi invalidado. O backend precisou gerar a resposta.
- PASS ou BYPASS: a requisição não deve ser armazenada ou reutilizada, geralmente por envolver sessão, conteúdo privado, método inadequado ou regra da VCL.
Páginas como checkout, carrinho e conta do cliente não devem ser tratadas da mesma maneira que páginas públicas de produtos e categorias. O objetivo não é transformar toda resposta em HIT, mas garantir que o conteúdo público elegível seja armazenado sem expor informações personalizadas.
Varnish no Magento 2 não dá HIT: faça estes 9 testes
1. Confirme se a requisição realmente passa pelo Varnish
Uma instalação correta no servidor não garante que o domínio esteja encaminhando tráfego para o Varnish. CDN, balanceador, proxy reverso, servidor web e portas incorretas podem fazer a requisição chegar diretamente ao backend.
Consulte os cabeçalhos da página pública usando:
curl -I https://www.exemplo.com.br/produto.htmlProcure cabeçalhos relacionados ao Varnish, à idade do objeto ou ao cache do Magento. Como esses nomes podem ser removidos por uma CDN ou proxy, compare o resultado externo com uma consulta feita a partir da rede interna. Registre os cabeçalhos antes de alterar a configuração.
2. Verifique o mecanismo de full page cache selecionado
No Admin, confira a configuração de cache de página em Lojas > Configuração > Avançado > Sistema > Full Page Cache. Em ambientes que usam Varnish, o mecanismo selecionado deve corresponder a essa arquitetura.
A verificação também pode ser feita pela CLI:
bin/magento config:show system/full_page_cache/caching_application
bin/magento cache:statusNão altere o valor diretamente em produção sem confirmar os arquivos de configuração, o processo de deploy e eventuais variáveis do ambiente. Uma configuração administrada por pipeline pode sobrescrever uma mudança manual.
3. Teste duas ou três requisições idênticas
A primeira chamada pode produzir MISS simplesmente porque o objeto ainda não existe no cache. Faça requisições consecutivas para a mesma URL, sem cookies e sem parâmetros variáveis:
curl -sI https://www.exemplo.com.br/categoria.html
curl -sI https://www.exemplo.com.br/categoria.html
curl -sI https://www.exemplo.com.br/categoria.htmlUse uma página pública estável e evite adicionar parâmetros aleatórios. Se todas as respostas continuarem como MISS, investigue expiração imediata, invalidação frequente, variação da chave de cache ou uma regra que esteja encaminhando a requisição ao backend.
4. Repita o teste sem cookies de sessão
Cookies alteram a forma como o Varnish e o Magento classificam uma requisição. Extensões de personalização, ferramentas de marketing e customizações podem criar cookies que provocam PASS ou geram muitas variações do mesmo objeto.
Compare uma janela anônima com uma sessão autenticada. Pela linha de comando, execute o teste sem importar um arquivo de cookies. Se a URL retorna HIT sem cookies e deixa de retornar após a navegação, examine quais cookies foram adicionados e quais realmente precisam participar da decisão de cache.
Não remova cookies indiscriminadamente. Alguns são necessários para sessão, consentimento, segurança e conteúdo privado.
5. Confira os cabeçalhos enviados pelo backend
Uma resposta com diretivas restritivas pode impedir seu armazenamento. Verifique especialmente Cache-Control, Pragma, Expires, Set-Cookie e os cabeçalhos de depuração do Magento quando estiverem disponíveis.
Se uma página pública envia private, no-store ou um cookie inesperado, identifique qual módulo, bloco ou observador produziu o comportamento. Não remova a diretiva no proxy antes de entender sua origem, pois ela pode existir para impedir o cache de dados personalizados.
6. Compare a VCL ativa com a configuração esperada
A VCL exportada pelo Magento precisa ser adaptada e implantada de maneira compatível com a topologia do ambiente. Uma VCL antiga pode não refletir mudanças de domínio, backend, porta, health check ou regras introduzidas durante uma atualização.
Confirme qual arquivo está realmente carregado pelo serviço, compare-o com a versão armazenada no repositório e revise alterações locais. Observe principalmente:
- endereço e porta do backend;
- tratamento de cookies e parâmetros de URL;
- métodos HTTP encaminhados sem cache;
- rotas de checkout, cliente e APIs;
- regras de purge e ban;
- health check do servidor de origem.
Faça a validação sintática antes de recarregar o serviço e mantenha uma forma segura de retornar à configuração anterior.
7. Procure invalidações excessivas
Importações, atualizações de produtos, integrações e extensões podem invalidar páginas com frequência. Nesse cenário, o Varnish funciona, mas os objetos são removidos antes de acumularem acessos suficientes para produzir HIT.
Relacione os horários dos MISS com alterações de catálogo, execuções agendadas e deploys. Se as invalidações coincidem com tarefas recorrentes, verifique o escopo das mudanças e a frequência da integração. Caso existam atrasos ou execuções repetidas, o roteiro de diagnóstico do cron do Magento 2 ajuda a avaliar as rotinas agendadas sem apagar o histórico.
8. Monitore Varnish e backend durante o teste
Ferramentas como varnishstat e os logs do serviço ajudam a distinguir MISS legítimo, backend indisponível, objeto não armazenável e falha de conexão. Execute a observação durante uma janela controlada e filtre apenas o necessário, pois o volume de registros pode ser alto.
varnishstat -1Ao mesmo tempo, acompanhe os logs do servidor web e do PHP-FPM. Se cada acesso à página pública gera processamento no PHP, mesmo após chamadas idênticas, existe forte indicação de que o objeto não está sendo reutilizado. Se o backend retorna erro, preserve os registros; o guia de diagnóstico de erro 500 no Magento 2 mostra como investigar sem eliminar evidências.
9. Separe falha de cache de lentidão no backend
O Varnish reduz o trabalho necessário para páginas armazenáveis, mas não corrige consultas lentas, integrações bloqueantes, imagens pesadas ou JavaScript excessivo. Meça separadamente:
- tempo da resposta em HIT;
- tempo da resposta em MISS;
- tempo do backend acessado internamente;
- tempo de carregamento e execução no navegador.
Se o HIT é rápido e o MISS é lento, o próximo diagnóstico deve se concentrar na aplicação e no banco. Se ambos são lentos, investigue rede, proxy, TLS, CDN e entrega dos arquivos. Essa separação evita alterar o Varnish para tentar resolver um gargalo localizado em outra camada.
O que não fazer durante o diagnóstico
- Não limpe todos os caches a cada teste, pois isso força novos MISS e apaga parte do comportamento que precisa ser observado.
- Não transforme checkout, carrinho ou conta do cliente em conteúdo público.
- Não remova cookies e cabeçalhos de segurança sem identificar sua finalidade.
- Não substitua a VCL ativa sem backup, validação e plano de reversão.
- Não conclua que o Varnish está quebrado com base em uma única requisição.
Conclusão
Quando o Varnish no Magento 2 não dá HIT, o diagnóstico deve começar pelo caminho da requisição e avançar para configuração, cookies, cabeçalhos, VCL e invalidações. Testar páginas públicas com requisições repetidas e correlacionar o resultado com os logs costuma revelar se o problema está no cache ou no backend.
Se a loja continua encaminhando páginas elegíveis ao PHP ou apresenta lentidão após mudanças na infraestrutura, uma análise técnica controlada pode evitar alterações arriscadas em produção. A equipe do SuporteMagento.com.br pode apoiar o diagnóstico de cache, performance e configuração do ambiente.
Perguntas frequentes sobre Varnish no Magento 2
Por que a primeira requisição retorna MISS e a segunda retorna HIT?
Na primeira requisição, o objeto pode ainda não existir no cache. Depois que o backend gera uma resposta armazenável, o Varnish consegue reutilizá-la nas chamadas seguintes. Esse comportamento é esperado.
Checkout e carrinho devem retornar HIT?
Não como páginas públicas compartilhadas. Essas áreas contêm estado e informações específicas da sessão. Forçar o cache público pode exibir dados incorretos ou criar riscos de segurança.
Limpar o cache resolve a ausência de HIT?
Normalmente não. A limpeza remove objetos existentes e provoca novos MISS. Ela só deve ser usada quando houver uma razão definida, como conteúdo obsoleto ou validação de uma mudança controlada.
Redis e Varnish fazem a mesma coisa no Magento 2?
Não. O Varnish atua como cache HTTP para respostas de páginas elegíveis. O Redis costuma ser usado em outras camadas, como cache da aplicação e sessões, conforme a arquitetura configurada.
