O Varnish Cache é um proxy reverso de cache HTTP: ele fica na frente do servidor web, guarda na memória RAM as páginas já prontas e as entrega aos próximos visitantes sem passar pelo PHP nem pelo banco de dados. Faz sentido em sites com muito acesso, rodando em VPS ou servidor dedicado, onde você tem acesso root para instalá-lo.
Abaixo você vê como ele funciona, quando vale a pena, como ele se compara ao cache de página do WordPress e a uma CDN, quais são as limitações e o que mudou no projeto entre 2025 e 2026, quando a versão de código aberto passou a se chamar Vinyl Cache.
- O que é o Varnish Cache
- Varnish Cache e Vinyl Cache: o que mudou em 2025 e 2026
- Como funciona o cache HTTP em memória
- Quando faz sentido usar o Varnish
- Varnish × cache de página no WordPress × CDN
- Limitações: HTTPS, área logada e carrinho
- Como começar a usar o Varnish no servidor
- “Varnish cache server” na página de erro: o que significa
- Perguntas frequentes
O que é o Varnish Cache
O Varnish é um software livre, criado em 2006 para acelerar o site de um grande jornal norueguês. Ele não substitui o servidor web: fica entre o visitante e o Apache, o Nginx ou outro servidor, que passa a ser chamado de backend.
Esse papel de intermediário é o de um proxy reverso. Para o navegador, quem responde é o Varnish. Ele recebe todos os pedidos, entrega o que já tem guardado e só consulta o servidor de verdade quando não tem a página ou quando a cópia venceu.
O que diferencia o Varnish de outras soluções de cache:
- Trabalha só com HTTP. Não é um proxy genérico para FTP ou e-mail.
- Guarda os objetos em memória RAM, o que torna a entrega muito rápida.
- É configurado pela VCL (Varnish Configuration Language), uma linguagem própria em que você decide o que vai para o cache, por quanto tempo e o que sempre passa direto para o servidor.
- Pode distribuir as requisições entre vários servidores de backend, fazendo também o papel de balanceador de carga.
Varnish Cache e Vinyl Cache: o que mudou em 2025 e 2026
Sim, houve separação. Em 15 de setembro de 2025, o projeto de código aberto anunciou que mudaria de nome para Vinyl Cache, por causa da marca “Varnish”, que pertence à empresa Varnish Software. A troca foi concluída com o lançamento do Vinyl Cache 9.0, em 16 de março de 2026.
A Varnish Software, por sua vez, continuou publicando um projeto com o nome Varnish Cache, também gratuito, que o pessoal do Vinyl descreve como uma distribuição derivada. Na prática, hoje existem dois caminhos:
| Vinyl Cache | Varnish Cache | |
|---|---|---|
| Quem mantém | Os mantenedores do projeto original, reunidos na Vinyl Cache Association | A empresa Varnish Software |
| Site oficial | vinyl-cache.org | varnish.org (o antigo varnish-cache.org redireciona para lá) |
| Versão mais recente (out/2026) | 9.1.0, de 16/09/2026, que virou a nova versão de suporte longo (LTS) | 9.1.0, de 23/09/2026 |
| HTTPS nativo | Não. Precisa de um terminador TLS na frente | Sim, a partir da versão 9 |
O que isso muda para você: a lógica de funcionamento e a linguagem VCL continuam as mesmas, e o que este guia explica vale para os dois. Mas nomes de pacotes, comandos e caminhos de arquivos mudaram em algumas distribuições Linux. Antes de atualizar um servidor, confira as notas de versão do projeto que você usa. Se você ainda roda a versão 6.0 LTS, o Vinyl Cache anunciou o fim do suporte dela para 15 de abril de 2027.
Como “Varnish” continua sendo o nome que todo mundo conhece e busca, vamos usá-lo no restante do texto para falar da tecnologia em geral.
Como funciona o cache HTTP em memória
Pense numa página de produto que recebe mil visitas por minuto. Sem cache, o servidor executa o PHP e consulta o banco mil vezes para montar o mesmo HTML. Com o Varnish na frente, o ciclo fica assim:
- O visitante pede a página. O pedido chega primeiro ao Varnish.
- Se a página está na memória e ainda é válida, é um hit: o Varnish responde na hora, sem tocar no servidor.
- Se não está, ou se a cópia venceu, é um miss: o Varnish pede a página ao backend, entrega ao visitante e guarda uma cópia.
- Os próximos visitantes recebem a cópia da memória até o prazo de validade (TTL) acabar ou até alguém apagar a página do cache, o que se chama purge.

Quem define por quanto tempo uma página pode ficar guardada é, em primeiro lugar, o próprio site, pelos cabeçalhos HTTP como Cache-Control. A VCL pode respeitar ou sobrescrever essas regras. Um recurso útil é o grace: se o servidor cair ou ficar lento, o Varnish continua entregando a última cópia por um tempo extra enquanto tenta buscar a nova.
Para conferir se uma página veio do cache, peça só os cabeçalhos com o curl e repita o comando:
curl -sI https://www.seusite.com.br/ | grep -i -E "age|via|cache"
# Age: 0 -> a página acabou de ser gerada pelo servidor (miss)
# Age: 37 -> a cópia está no cache há 37 segundos (hit)
Quando faz sentido usar o Varnish
O Varnish brilha quando muita gente vê as mesmas páginas e o servidor gasta tempo para gerá-las. Ele costuma valer o trabalho nestes casos:
- Portais de notícias, blogs e revistas com picos de acesso quando uma matéria viraliza.
- Catálogos e lojas virtuais com muitas visitas nas páginas de categoria e de produto.
- Sites que rodam em VPS ou servidor dedicado, com acesso root para instalar e configurar o serviço.
- Arquiteturas com mais de um servidor de aplicação, em que o Varnish também distribui a carga.
Ele não compensa num site pequeno com poucas visitas por dia, em páginas que mudam para cada usuário ou quando você não tem acesso ao servidor. Na hospedagem compartilhada, por exemplo, não dá para instalar o Varnish; ali o caminho é o cache de página da própria plataforma ou de um plugin, como mostramos no guia de velocidade do site.
Antes de instalar: rode o PageSpeed Insights e veja se o gargalo é mesmo o tempo de resposta do servidor (TTFB). Se o problema são imagens pesadas ou JavaScript em excesso, o Varnish não resolve.
Varnish × cache de página no WordPress × CDN
As três soluções guardam cópias prontas, mas em lugares diferentes. Muitos sites usam mais de uma ao mesmo tempo.
| Varnish | Plugin de cache de página (WordPress) | CDN | |
|---|---|---|---|
| Onde fica | No seu servidor, na frente do servidor web | Dentro do WordPress, gravando HTML em disco | Em servidores espalhados por várias regiões |
| O que guarda | Páginas e arquivos, em memória RAM | Páginas HTML prontas | Principalmente imagens, CSS e JavaScript; algumas também guardam HTML |
| Precisa de acesso root? | Sim | Não | Não; basta apontar o DNS ou configurar o plugin |
| Ajuda quem acessa de longe? | Não. Continua num único lugar | Não | Sim, é o ponto forte |
| Aguenta pico de acesso? | Muito bem, porque nem chega ao PHP | Bem, mas cada pedido ainda passa pelo servidor web | Muito bem para o que estiver em cache |
| Esforço de configuração | Alto: VCL, portas e regras de exclusão | Baixo | Baixo a médio |
| Indicado para | Sites grandes em VPS ou dedicado | A maioria dos sites WordPress | Público espalhado pelo país ou pelo mundo |
Uma combinação comum em sites grandes: CDN na borda para arquivos estáticos, Varnish no servidor para o HTML e cache de objeto (Redis) para o que não pode ir para o cache, como carrinho e painel. Para entender a camada de borda, veja o que é CDN e quando usar. Se o seu site é WordPress, o guia de velocidade do WordPress mostra os plugins de cache em detalhe.
Limitações: HTTPS, área logada e carrinho
O Varnish é rápido justamente porque entrega a mesma resposta para todo mundo. Isso cria alguns limites que você precisa planejar:
HTTPS precisa de terminação TLS na frente
Por muitos anos, o Varnish só falou HTTP sem criptografia. Para atender em HTTPS, coloca-se na frente um programa que recebe a conexão segura, descriptografa e repassa ao Varnish: Hitch, HAProxy ou o próprio Nginx. O Vinyl Cache continua funcionando assim. O Varnish Cache da Varnish Software passou a aceitar TLS diretamente a partir da versão 9, mas muitos servidores seguem com o terminador separado.
Conteúdo logado e cookies
Pela configuração padrão, pedidos com cookie ou com autenticação passam direto para o servidor, sem cache. É uma proteção: sem ela, um visitante poderia ver a página montada para outra pessoa. O problema é que muitos sites gravam cookies de análise e de anúncios em todo visitante, e aí nada vai para o cache. Parte do trabalho de configurar o Varnish é ensinar a VCL a ignorar esses cookies e respeitar só os de sessão.
Carrinho, checkout e painel
Páginas como carrinho, finalizar compra, minha conta e o painel administrativo mudam para cada pessoa e precisam ficar fora do cache. Em lojas virtuais, erros aqui são graves: um carrinho em cache pode mostrar produtos de outro cliente.
Atenção também à memória e à limpeza do cache: o Varnish usa a RAM do servidor, então reserve memória para ele sem sufocar o banco e o PHP. E quando você publica ou edita um conteúdo, alguém precisa avisar o Varnish para descartar a cópia velha. No WordPress, o plugin Proxy Cache Purge faz isso automaticamente ao salvar um post.
Como começar a usar o Varnish no servidor
Os comandos de instalação dependem da distribuição Linux e de qual projeto você escolher, e mudaram com a troca de nome. Por isso, siga o guia de instalação do site oficial. O roteiro geral é este:
- Faça backup e teste primeiro numa cópia do site ou numa porta alternativa.
- Instale o pacote pelo repositório oficial do projeto escolhido.
- Mude o servidor web (Apache ou Nginx) para escutar numa porta interna, como a 8080.
- Configure o Varnish para escutar na porta 80 e apontar para esse backend.
- Coloque o terminador TLS na porta 443, repassando para o Varnish, se a sua versão não tiver HTTPS nativo.
- Escreva as regras de exclusão na VCL e valide o arquivo antes de recarregar o serviço.
- Teste com o
curl(cabeçalhoAge), navegue logado e faça uma compra de teste para garantir que nada pessoal foi para o cache.
Um ponto de partida de VCL para um site WordPress com WooCommerce, deixando painel, carrinho e checkout fora do cache:
vcl 4.1;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
# Painel, login, carrinho, checkout e conta do cliente: sempre direto ao servidor
if (req.url ~ "^/(wp-admin|wp-login\.php|carrinho|finalizar-compra|minha-conta)") {
return (pass);
}
}
Esse é só o esqueleto. Uma configuração de produção também trata cookies, tempo de cache, purge e grace, e vale a pena contar com alguém que conheça VCL.
Na SAN: o Varnish precisa de um servidor em que você tenha controle total. O Cloud Server VPS da SAN tem SSD, acesso root e opção de cPanel/WHM, com 99,9% de uptime. Se ainda está em dúvida sobre o tipo de servidor, compare VPS, cloud e servidor dedicado.
“Varnish cache server” na página de erro: o que significa
Muita gente chega ao termo “varnish cache server” depois de ver uma página de erro com essa assinatura no rodapé, geralmente com a mensagem Error 503 Backend fetch failed e um código “Guru Meditation”.
| Se você é… | O que aconteceu | O que fazer |
|---|---|---|
| Visitante | O Varnish do site está funcionando, mas o servidor por trás dele não respondeu a tempo ou está fora do ar | Aguardar alguns minutos e tentar de novo. O problema não está no seu computador |
| Dono do site | O backend caiu, demorou além do limite configurado ou devolveu uma resposta inválida | Verificar se o Apache ou Nginx e o PHP estão rodando, olhar os logs do servidor e revisar os tempos limite na VCL |
O código Guru Meditation identifica o pedido nos logs do Varnish, o que ajuda o administrador a achar a causa exata.
Perguntas frequentes
É um proxy reverso de cache HTTP. Ele fica na frente do servidor web, guarda as páginas prontas na memória RAM e as entrega aos próximos visitantes sem executar PHP nem consultar o banco de dados.
O projeto de código aberto passou a se chamar Vinyl Cache: a mudança foi anunciada em setembro de 2025 e concluída com a versão 9.0, em março de 2026. A empresa Varnish Software mantém um projeto separado que continua com o nome Varnish Cache.
O Vinyl Cache não tem HTTPS nativo e precisa de um terminador TLS na frente, como Hitch, HAProxy ou Nginx. O Varnish Cache da Varnish Software aceita TLS diretamente a partir da versão 9.
Não. O Varnish precisa ser instalado e configurado no servidor, com acesso root, o que exige um VPS ou servidor dedicado. Em hospedagem compartilhada, use o cache de página da plataforma ou de um plugin.
Significa que o Varnish está funcionando, mas o servidor por trás dele não respondeu a tempo ou está fora do ar. Para o visitante, o jeito é tentar mais tarde; o dono do site precisa verificar o servidor web, o PHP e os logs.