Otimizar Varnish travando após reinicialização: como reverter

15 min de leitura  ·  Guia técnico

Varnish travando após reinicialização ocorre quando uma configuração VCL inválida, conflito de porta ou alocação de memória excessiva impede o daemon de subir corretamente. Para reverter e corrigir o problema, siga estes passos:

1. Verifique o status e os logs do Varnish com systemctl status varnish e journalctl -u varnish.
2. Identifique se o erro é de VCL inválida, porta ocupada ou falta de memória.
3. Restaure o arquivo VCL anterior ou substitua pelo conteúdo mínimo funcional.
4. Valide a VCL com varnishd -C -f /etc/varnish/default.vcl antes de reiniciar.
5. Ajuste parâmetros de memória no arquivo de serviço do systemd se necessário.
6. Reinicie o serviço e confirme que o cache está ativo com curl -I.

Pré-requisitos para reverter o Varnish após reinicialização

• Acesso root ou sudo ao servidor (Debian 12, Ubuntu 24.04 LTS ou Rocky Linux 9).
• Varnish Cache instalado — versão 7.x recomendada (compatível com as distribuições acima).
• Acesso SSH ao servidor; consulte Acessando servidores VPS Linux da AviraHost se precisar de ajuda para conectar.
• Backup do arquivo /etc/varnish/default.vcl (ou acesso ao histórico de versões).
• Conhecimento básico de systemd e edição de arquivos via terminal.

Diagnóstico: por que o Varnish trava após reinicialização

Antes de reverter qualquer configuração, é essencial entender a causa raiz do travamento. O Varnish pode falhar ao iniciar por três razões principais: VCL inválida, conflito de porta ou esgotamento de memória. Cada uma produz mensagens de erro distintas nos logs do systemd.

Execute os dois comandos abaixo imediatamente após perceber que o serviço não subiu:

systemctl status varnish

Output esperado (falha de VCL):
● varnish.service - Varnish Cache, a high-performance HTTP accelerator
     Loaded: loaded (/lib/systemd/system/varnish.service; enabled)
     Active: failed (Result: exit-code)
    Process: ExecStartPre=/usr/sbin/varnishd -C -f /etc/varnish/default.vcl (code=exited, status=1/FAILURE)

journalctl -u varnish --no-pager -n 50

Output esperado (erro de sintaxe VCL):
varnishd: VCL compilation failed
/etc/varnish/default.vcl:23: Expected one of
    'acl', 'backend', 'director', ...
Message from VCC-compiler:
Expected one of

Se a mensagem mencionar Address already in use, o problema é conflito de porta. Se mencionar Cannot allocate memory ou malloc, o problema é memória insuficiente. Identifique o cenário antes de prosseguir.

Para verificar qual processo está ocupando a porta 80 ou 6081:

ss -tlnp | grep -E '80|6081'

Output esperado:
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

Esse output indica que o Nginx está ocupando a porta 80, impedindo o Varnish de iniciar. Veja a seção de problemas comuns para resolver esse cenário.

Como reverter uma VCL inválida que quebrou o Varnish

A reversão de configuração VCL corrompida é a causa mais frequente de falha após reinicialização. O arquivo /etc/varnish/default.vcl é lido na inicialização e qualquer erro de sintaxe impede o daemon de compilar e subir.

Atenção: antes de sobrescrever o arquivo atual, faça uma cópia de segurança do estado problemático para análise posterior.

cp /etc/varnish/default.vcl /etc/varnish/default.vcl.broken.$(date +%Y%m%d)

Restaurar backup anterior do arquivo VCL

Se você mantém backups automáticos (via cron ou ferramentas como rsync), localize a versão anterior funcional:

ls -lht /etc/varnish/

Output esperado:
-rw-r--r-- 1 root root 1.2K Jan 15 09:00 default.vcl
-rw-r--r-- 1 root root 1.1K Jan 14 18:30 default.vcl.bak

cp /etc/varnish/default.vcl.bak /etc/varnish/default.vcl

Substituir pela VCL mínima funcional

Se não houver backup disponível, substitua o conteúdo pelo mínimo necessário para o Varnish iniciar. Este template funciona com Varnish 7.x e é compatível com Debian 12 e Ubuntu 24.04:

cat > /etc/varnish/default.vcl << 'EOF'
vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        return (synth(405, "Not allowed."));
    }
    return (hash);
}

sub vcl_backend_response {
    set beresp.ttl = 120s;
    set beresp.grace = 30s;
}

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
    return (deliver);
}
EOF

Após criar ou restaurar o arquivo, sempre valide antes de reiniciar:

varnishd -C -f /etc/varnish/default.vcl

Output esperado (VCL válida):
VCL compiled.

Se a saída for VCL compiled., a sintaxe está correta e você pode reiniciar o serviço com segurança:

systemctl restart varnish
systemctl status varnish

Output esperado:
● varnish.service - Varnish Cache, a high-performance HTTP accelerator
     Active: active (running) since ...

Corrigir travamento por falta de memória no Varnish

O pool de cache do Varnish é alocado inteiramente na inicialização. Se o parâmetro de memória configurado exceder a RAM disponível após o reboot — especialmente em servidores com outros serviços ativos — o daemon falha com erro de alocação.

Localize onde o parâmetro de memória está definido. Em sistemas com systemd, pode estar em dois lugares:

cat /etc/systemd/system/varnish.service | grep malloc

ou

cat /etc/varnish/varnish.params 2>/dev/null | grep VARNISH_STORAGE

Verifique a RAM disponível no momento:

free -h

Output esperado:
              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       2.1Gi       512Mi       128Mi       1.2Gi       1.5Gi

Com 1.5 GB disponíveis, configure o Varnish para usar no máximo 60% desse valor (aproximadamente 900 MB). Edite o arquivo de serviço:

systemctl edit varnish --force

Adicione o seguinte conteúdo no editor que abrir:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd \
    -a :80 \
    -T localhost:6082 \
    -f /etc/varnish/default.vcl \
    -s malloc,512m

Salve, recarregue o daemon e reinicie o Varnish:

systemctl daemon-reload
systemctl restart varnish

Para servidores com recursos limitados, consulte também as Dicas de Otimização de Servidores Linux para ajustar outros serviços e liberar memória antes de subir o Varnish.

Configurar Varnish com Nginx como backend após reversão

A arquitetura mais robusta para produção combina Varnish na porta 80 com Nginx como backend na porta 8080. Após reverter o Varnish, confirme que o Nginx está configurado corretamente para escutar na porta alternativa.

Verifique o arquivo de configuração do Nginx:

grep -r "listen" /etc/nginx/sites-enabled/

Output esperado:
/etc/nginx/sites-enabled/default:    listen 8080 default_server;

Se o Nginx ainda estiver na porta 80, edite o bloco server correspondente:

nano /etc/nginx/sites-enabled/default

Altere a linha listen 80 para listen 8080 e salve. Depois, teste e recarregue:

nginx -t && systemctl reload nginx

Output esperado:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Com o Nginx na porta 8080, o Varnish pode assumir a porta 80 sem conflito. Confirme que o parâmetro backend default na VCL aponta para 127.0.0.1:8080 (já incluído no template mínimo da seção anterior).

Para habilitar HTTPS, o fluxo recomendado é: cliente → Nginx (443, SSL termination) → Varnish (porta interna) → Nginx backend (8080). Veja como configurar o redirecionamento em Como redirecionar um site http para https?

Verificar se o Varnish está em cache e funcionando após a reversão

Após reiniciar o serviço com sucesso, confirme que o cache está operacional antes de considerar o problema resolvido. O método mais rápido é inspecionar os cabeçalhos HTTP da resposta:

curl -I http://seu-dominio.com

Output esperado (cache ativo):
HTTP/1.1 200 OK
X-Varnish: 32770 3
Age: 45
Via: 1.1 varnish (Varnish/7.4)
X-Cache: HIT

O cabeçalho X-Varnish confirma que a requisição passou pelo Varnish. O campo Age: 45 indica que o objeto tem 45 segundos no cache — ou seja, veio do cache e não do backend. Se Age: 0, a requisição foi um MISS (primeira vez ou cache expirado).

Para monitorar hits e misses em tempo real, use o varnishstat:

varnishstat -f MAIN.cache_hit -f MAIN.cache_miss -f MAIN.uptime

Output esperado:
MAIN.cache_hit          1234         12.34 Cache hits
MAIN.cache_miss          321          3.21 Cache misses
MAIN.uptime              600          1.00 Child process uptime

Uma proporção de hits significativamente maior que misses indica que o cache está funcionando corretamente. Se os hits permanecerem em zero por vários minutos com tráfego real, revise as regras vcl_recv — pode haver um return(pass) forçando todas as requisições para o backend.

Problemas comuns e como resolver

Sintoma: Varnish falha com "Address already in use" na porta 80

Causa: Outro processo (geralmente Nginx ou Apache) está escutando na porta 80 e não foi reconfigurado para a porta 8080 antes do reboot. O Varnish tenta assumir a porta 80 e encontra o socket ocupado.
Solução: Identifique o processo com ss -tlnp | grep :80, altere a configuração do Nginx para escutar na porta 8080 conforme descrito na seção anterior, recarregue o Nginx com systemctl reload nginx e então reinicie o Varnish com systemctl restart varnish.

Sintoma: VCL compila mas o Varnish retorna 503 para todas as requisições

Causa: O backend definido na VCL não está acessível — o Nginx pode estar parado, escutando em porta diferente, ou o firewall bloqueou a conexão local entre Varnish e backend.
Solução: Verifique se o backend responde diretamente com curl -I http://127.0.0.1:8080. Se não responder, inicie ou reconfigure o Nginx. Verifique também regras de firewall com iptables -L -n | grep 8080 ou ufw status. O Varnish registra falhas de backend em varnishlog -g request -q "RespStatus == 503".

Sintoma: Varnish inicia mas para sozinho após alguns segundos

Causa: O processo filho do Varnish (worker) está sendo encerrado por OOM killer do kernel devido à alocação de memória excessiva, ou há um panic no VCL durante o processamento da primeira requisição real.
Solução: Verifique o log do kernel com dmesg | grep -i "oom\|varnish" para confirmar se o OOM killer atuou. Se sim, reduza o parâmetro malloc conforme descrito na seção de memória. Se o problema for no VCL, use varnishlog -g raw para capturar o erro exato durante o processamento.

Sintoma: Após reversão, o site carrega mas sem cache (todos os requests são MISS)

Causa: A VCL mínima restaurada pode ter TTL muito baixo, ou o backend está enviando cabeçalhos Cache-Control: no-cache ou Set-Cookie que forçam o Varnish a não armazenar as respostas.
Solução: Inspecione os cabeçalhos do backend com varnishlog -g request -q "ReqURL eq '/'" e procure por beresp.http.Cache-Control ou beresp.http.Set-Cookie. Adicione regras na sub-rotina vcl_backend_response para remover cookies desnecessários em conteúdo estático: unset beresp.http.Set-Cookie;.

Perguntas frequentes sobre Varnish travando após reinicialização

Por que o Varnish não inicia após reinicialização do servidor?

O Varnish pode falhar ao iniciar após reinicialização por conflito de porta (geralmente a 6081 ou 80 já ocupada por outro processo), permissões incorretas no diretório de trabalho, ou configuração VCL inválida introduzida antes do reboot. Verifique o status com systemctl status varnish e os logs com journalctl -u varnish --no-pager -n 50 para identificar a causa exata. Cada cenário produz mensagens de erro distintas que direcionam para a solução correta.

Como reverter uma configuração VCL que quebrou o Varnish?

Para reverter uma VCL problemática, localize o backup do arquivo anterior (geralmente em /etc/varnish/default.vcl) e restaure-o. Se não houver backup, substitua pelo conteúdo mínimo funcional com apenas backend default e vcl_recv básico. Após restaurar, valide com varnishd -C -f /etc/varnish/default.vcl antes de reiniciar o serviço — esse comando compila a VCL sem iniciar o daemon, garantindo que a sintaxe está correta.

Como verificar se o Varnish está realmente em cache e funcionando?

Execute curl -I http://seu-dominio.com e verifique o cabeçalho X-Varnish na resposta — se presente, o Varnish está ativo. O cabeçalho Age com valor maior que zero indica que a resposta veio do cache. Você também pode usar varnishstat para monitorar hits e misses em tempo real, o que permite avaliar a eficiência do cache durante o período de aquecimento após a reinicialização.

O Varnish pode travar por falta de memória no servidor?

Sim. Se o parâmetro -s malloc,256m (ou o valor configurado) exceder a RAM disponível após o reboot, o Varnish falha ao alocar o pool de cache e não sobe. Reduza o valor de memória no arquivo de configuração do systemd (/etc/systemd/system/varnish.service ou /etc/varnish/varnish.params) para um valor seguro, geralmente 50-60% da RAM livre. Após ajustar, execute systemctl daemon-reload antes de reiniciar o serviço.

É possível usar o Varnish junto com Nginx no mesmo servidor?

Sim, a arquitetura mais comum é Varnish escutando na porta 80 (ou 443 via Nginx com SSL) e o Nginx como backend na porta 8080. O Nginx recebe as requisições que o Varnish não consegue servir do cache e processa o conteúdo dinâmico. Essa configuração exige ajuste do parâmetro backend default na VCL para apontar para 127.0.0.1:8080, e o Nginx deve ser configurado para não escutar na porta 80.

Conclusão

• Sempre valide a VCL antes de reiniciar: use varnishd -C -f /etc/varnish/default.vcl após qualquer alteração — isso evita que uma sintaxe inválida cause falha na próxima reinicialização do servidor.
• Mantenha backups versionados da VCL: configure um cron simples para copiar o arquivo com timestamp (cp /etc/varnish/default.vcl /etc/varnish/backups/default.vcl.$(date +%Y%m%d-%H%M)) antes de qualquer edição em produção.
• Monitore memória e portas após cada reboot: use free -h e ss -tlnp como checklist pós-reinicialização para garantir que o ambiente está pronto antes de subir o Varnish.

Leia também

• Comparativo: Varnish vs Redis como cache HTTP no Debian 12
• Otimizar o uso de memória RAM no MySQL em VPS Linux e servidores dedicados
• Otimizar VPS Linux: configurações avançadas que a maioria ignora

Precisa de ajuda com Varnish e performance no seu servidor?

Configurar e manter o Varnish em produção exige atenção a detalhes de VCL, memória e integração com outros serviços. Um VPS com recursos adequados e suporte técnico especializado pode fazer a diferença na estabilidade do seu ambiente de cache.

Conheça os planos de VPS da AviraHost e escolha o ambiente ideal para rodar Varnish em produção