Comparativo: Varnish vs Redis como cache HTTP no Debian 12

Varnish e Redis diferem fundamentalmente em como reduzem o TTFB: Varnish é um cache HTTP reverso que intercepta e armazena respostas HTTP completas antes do servidor web, enquanto Redis é um armazenamento de estruturas de dados em memória usado para cache de objetos de aplicação, sessões e resultados de banco de dados — sem interceptar requisições HTTP diretamente.

Pré-requisitos para configurar Varnish e Redis no Debian 12

• Servidor com Debian 12 (Bookworm) e acesso root via SSH
• Nginx ou Apache já instalado e servindo sua aplicação web
• PHP 8.2 ou superior (se usar WordPress ou aplicação PHP)
• Pelo menos 1 GB de RAM disponível (2 GB recomendado para ambos rodando juntos)
• Portas 80, 443 e 6379 liberadas no firewall conforme necessidade
• Acesso SSH configurado — veja como acessar servidores VPS Linux da AviraHost

Comparativo Varnish vs Redis: arquitetura e casos de uso

Entender a arquitetura de cada solução é o primeiro passo para escolher a ferramenta certa de cache HTTP. Varnish Cache opera como um proxy reverso HTTP na camada 7, posicionado entre o cliente e o servidor web. Ele armazena respostas HTTP completas — incluindo cabeçalhos, corpo e metadados — diretamente na RAM. Quando uma requisição chega, o Varnish verifica se já possui aquela resposta em cache; se sim, retorna imediatamente sem tocar no Nginx, PHP ou banco de dados.

Redis, por outro lado, é um banco de dados em memória do tipo chave-valor que suporta estruturas como strings, hashes, listas e sets. Ele não intercepta requisições HTTP — a aplicação precisa chamar explicitamente o Redis para armazenar ou recuperar dados. No contexto de redução de TTFB, Redis atua eliminando consultas repetidas ao MySQL ou PostgreSQL, armazenando resultados de queries, sessões de usuário e objetos de aplicação.

• Varnish: cache de página completa, transparente para a aplicação, ideal para conteúdo estático ou semi-estático
• Redis: cache de objetos de aplicação, requer integração via código ou plugin, ideal para dados dinâmicos e sessões
• Varnish: reduz TTFB eliminando todo o processamento PHP e consultas ao banco para páginas cacheadas
• Redis: reduz TTFB acelerando consultas ao banco, mas PHP ainda processa a requisição
• Varnish: não funciona nativamente com HTTPS — requer terminador TLS (Nginx ou HAProxy)
• Redis: funciona com qualquer protocolo, pois opera na camada de aplicação

Instalando e configurando o Varnish no Debian 12

O cache HTTP reverso com Varnish é instalado diretamente dos repositórios oficiais do Debian 12. O processo envolve instalar o pacote, configurar o backend (seu Nginx ou Apache) e ajustar as portas para que o Varnish receba o tráfego na porta 80.

1. Atualize os pacotes e instale o Varnish:

apt update && apt install -y varnish

2. Verifique a versão instalada:

varnishd -V

varnishd (varnish-7.x.x revision ...)

3. Configure o Nginx para escutar na porta 8080 (o Varnish ficará na 80). Edite o bloco server do seu site:

nano /etc/nginx/sites-available/default

server {
    listen 8080;
    server_name seudominio.com;
    root /var/www/html;
    index index.php index.html;
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

4. Reinicie o Nginx:

systemctl restart nginx

5. Configure o Varnish para escutar na porta 80 e usar o Nginx como backend. Edite o arquivo de serviço:

nano /etc/varnish/default.vcl

vcl 4.1;

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

sub vcl_recv {
    if (req.method == "PURGE") {
        return(purge);
    }
    if (req.http.Cookie) {
        unset req.http.Cookie;
    }
}

sub vcl_backend_response {
    set beresp.ttl = 1h;
    set beresp.grace = 15m;
}

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

6. Ajuste a porta de escuta do Varnish no systemd:

nano /etc/systemd/system/varnish.service

Localize a linha ExecStart e ajuste para:

ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m

7. Recarregue o systemd e inicie o Varnish:

systemctl daemon-reload && systemctl enable varnish && systemctl restart varnish

8. Teste se o Varnish está servindo respostas em cache:

curl -I http://seudominio.com

HTTP/1.1 200 OK
X-Cache: HIT
X-Varnish: 32770 3
Age: 42
Via: 1.1 varnish (Varnish/7.x)

O cabeçalho X-Cache: HIT confirma que a resposta veio do cache. O campo Age indica há quantos segundos o objeto está armazenado.

Instalando e configurando o Redis no Debian 12

O armazenamento em memória com Redis é instalado via apt e integrado à aplicação por meio de extensões PHP ou plugins. No caso do WordPress, o plugin Redis Object Cache é a forma mais comum de integração.

1. Instale o Redis e a extensão PHP:

apt install -y redis-server php-redis

2. Verifique se o Redis está ativo:

systemctl status redis-server

● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled)
     Active: active (running)

3. Teste a conexão com o Redis CLI:

redis-cli ping

PONG

4. Configure o Redis para usar apenas memória local (sem persistência em disco para cache puro). Edite o arquivo de configuração:

nano /etc/redis/redis.conf

Localize e ajuste as seguintes diretivas:

maxmemory 256mb
maxmemory-policy allkeys-lru
save ""

5. Reinicie o Redis para aplicar as configurações:

systemctl restart redis-server

6. Para WordPress, adicione as seguintes linhas ao wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE', true);

7. Instale o plugin Redis Object Cache via WP-CLI:

wp plugin install redis-cache --activate --allow-root
wp redis enable --allow-root

8. Verifique o status do cache de objetos:

wp redis status --allow-root

Status: Connected
Client: PhpRedis (v5.x.x)
Hits: 142 (89.3%)
Misses: 17 (10.7%)

Uma taxa de acertos acima de 80% indica que o Redis está sendo efetivo na redução de consultas ao banco de dados.

Usando Varnish e Redis juntos para reduzir o TTFB abaixo de 200ms

A combinação de cache HTTP reverso com cache de objetos de aplicação é a arquitetura mais eficiente para sites de alto tráfego. Nesta configuração em camadas, o Varnish intercepta requisições de páginas já cacheadas e as serve sem tocar no PHP ou no banco. Para requisições que passam pelo Varnish (MISS) ou para usuários autenticados que não podem ser cacheados pelo Varnish, o Redis elimina as consultas repetidas ao MySQL.

A arquitetura completa fica assim:

Cliente → Nginx (443, TLS offload) → Varnish (80) → Nginx (8080) → PHP-FPM → Redis → MySQL

Para configurar o Nginx como terminador TLS na frente do Varnish, adicione ao bloco server HTTPS:

server {
    listen 443 ssl;
    server_name seudominio.com;
    ssl_certificate /etc/letsencrypt/live/seudominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/seudominio.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Para redirecionar HTTP para HTTPS corretamente nesta arquitetura, consulte como redirecionar um site HTTP para HTTPS.

Para monitorar o desempenho do Varnish em tempo real, use:

varnishstat -1 | grep -E "MAIN.cache_hit|MAIN.cache_miss|MAIN.client_req"

MAIN.cache_hit          4821          1.23 Cache hits
MAIN.cache_miss          312          0.08 Cache misses
MAIN.client_req         5133          1.31 Good client requests received

Uma taxa de acertos (hit rate) acima de 90% é o objetivo em produção. Para monitorar o Redis:

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

keyspace_hits:28431
keyspace_misses:3102

Quando usar Varnish, quando usar Redis e quando usar os dois

A escolha entre as ferramentas de aceleração de resposta HTTP depende do perfil da sua aplicação. Varnish é ideal para sites com alto volume de páginas idênticas servidas para usuários anônimos — portais de notícias, blogs, landing pages e e-commerces com catálogos estáticos. Redis brilha em aplicações com muitos usuários autenticados, dados personalizados e consultas complexas ao banco de dados.

• Use apenas Varnish quando: seu site tem mais de 70% de tráfego anônimo, páginas mudam raramente e você quer redução máxima de TTFB sem alterar código
• Use apenas Redis quando: todos os usuários são autenticados (impossível cachear páginas completas), mas há consultas pesadas ao banco que se repetem
• Use os dois quando: há mix de tráfego anônimo e autenticado, alta carga no banco de dados e necessidade de TTFB abaixo de 200ms para a maioria das requisições
• Não use Varnish quando: sua aplicação usa cookies extensivamente em todas as páginas, pois o Varnish por padrão não cacheia requisições com cookies
• Não use Redis como cache HTTP quando: você espera que ele substitua o Varnish — Redis não intercepta requisições HTTP e não serve páginas diretamente

Para entender melhor as diferenças de infraestrutura que suportam essas configurações, veja o artigo Dicas de Otimização de Servidores Linux.

Problemas comuns e como resolver

Sintoma: Varnish retorna sempre MISS, nunca cacheia

Causa: A aplicação está enviando cabeçalhos Set-Cookie ou Cache-Control: no-cache em todas as respostas, fazendo o Varnish ignorar o cache por padrão.
Solução: Adicione no bloco vcl_backend_response do seu default.vcl uma regra para remover cookies desnecessários e forçar TTL para conteúdo estático:

sub vcl_backend_response {
    if (bereq.url ~ "\.(css|js|png|jpg|gif|ico|woff2)$") {
        unset beresp.http.Set-Cookie;
        set beresp.ttl = 24h;
    }
}

Após editar o VCL, recarregue sem reiniciar o serviço: varnishreload

Sintoma: Redis conecta mas o WordPress não usa o cache

Causa: O arquivo object-cache.php não foi copiado para o diretório wp-content/, ou a extensão php-redis não está carregada no PHP-FPM.
Solução: Verifique se a extensão está ativa:

php -m | grep redis

redis

Se não aparecer, instale e reinicie o PHP-FPM: apt install php-redis && systemctl restart php8.2-fpm. Em seguida, execute wp redis enable --allow-root novamente para copiar o drop-in.

Sintoma: Varnish na porta 80 conflita com Nginx

Causa: O Nginx ainda está configurado para escutar na porta 80, impedindo o Varnish de iniciar.
Solução: Confirme que todos os blocos server do Nginx usam a porta 8080 e não 80:

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

Se retornar resultados, edite cada arquivo e troque listen 80 por listen 8080. Depois: systemctl restart nginx && systemctl restart varnish

Sintoma: Redis consumindo toda a memória disponível

Causa: A diretiva maxmemory não foi configurada, permitindo que o Redis cresça indefinidamente.
Solução: Defina um limite explícito em /etc/redis/redis.conf e use a política allkeys-lru para evicção automática dos dados menos usados:

maxmemory 512mb
maxmemory-policy allkeys-lru

Reinicie o Redis após a alteração: systemctl restart redis-server

Perguntas frequentes sobre Varnish e Redis para cache HTTP

Qual a diferença entre Varnish e Redis para cache de sites?

Varnish é um cache HTTP reverso que armazena respostas HTTP completas na memória RAM, operando na camada 7 da rede antes do servidor web. Redis é um armazenamento de estruturas de dados em memória usado principalmente para cache de objetos de aplicação, sessões e filas — não intercepta requisições HTTP diretamente. Para reduzir TTFB de páginas completas, Varnish é mais eficiente; para cache de dados de aplicação como consultas de banco e sessões PHP, Redis é a escolha correta.

Varnish e Redis podem ser usados juntos no mesmo servidor?

Sim, e essa combinação é comum em ambientes de alta performance. Varnish atua como cache HTTP reverso na frente do Nginx ou Apache, enquanto Redis armazena sessões PHP, resultados de consultas MySQL e objetos de aplicação. Juntos, eles eliminam tanto o processamento HTTP quanto as consultas repetidas ao banco de dados, reduzindo o TTFB de forma complementar e cobrindo tanto usuários anônimos quanto autenticados.

Varnish funciona com HTTPS?

Varnish por si só não termina conexões TLS — ele opera apenas com HTTP puro. Para usar Varnish com HTTPS, é necessário colocar um terminador TLS na frente, como Nginx ou HAProxy, que decifra o tráfego HTTPS e repassa as requisições HTTP para o Varnish. Essa arquitetura é chamada de SSL offloading e é o padrão recomendado em produção, pois mantém o Varnish focado no que faz melhor: servir cache.

Como verificar se o Varnish está servindo respostas em cache?

Execute curl -I http://seudominio.com e verifique o cabeçalho X-Varnish na resposta. Se aparecer dois números (ex: X-Varnish: 32770 3), a resposta veio do cache (HIT). Se aparecer apenas um número, foi um MISS e o Varnish buscou o conteúdo no backend. Você também pode usar varnishstat para monitorar a taxa de acertos em tempo real e identificar gargalos de configuração.

Redis reduz o TTFB de páginas WordPress?

Redis reduz o TTFB indiretamente ao eliminar consultas repetidas ao banco de dados MySQL. Com o plugin Redis Object Cache ativo no WordPress, objetos como resultados de WP_Query, opções e transients são servidos da RAM em vez do disco. A redução de TTFB depende da proporção de tempo gasto em consultas de banco — em sites com muitos plugins e consultas complexas, a melhora pode ser significativa, especialmente em páginas com usuários autenticados onde o Varnish não pode atuar.

Conclusão

• Implante Varnish primeiro se seu site tem tráfego majoritariamente anônimo — a redução de TTFB será imediata e sem necessidade de alterar código da aplicação
• Adicione Redis em seguida para cobrir usuários autenticados, acelerar consultas ao banco e armazenar sessões PHP, completando a estratégia de cache em camadas
• Monitore continuamente com varnishstat e redis-cli info stats — uma taxa de acertos abaixo de 80% indica que as regras de cache precisam de ajuste fino no VCL ou na configuração do TTL

Leia também

• Otimizar cache Redis para aplicações PHP no Ubuntu 22.04
• Otimizar PHP 8.3 no Debian 12: OPcache, JIT e pool FPM
• Dicas de Otimização de Servidores Linux

Precisa de ajuda com cache e performance no seu servidor?

Configurar Varnish e Redis corretamente exige ajuste fino de VCL, políticas de evicção e arquitetura de rede. Um VPS com recursos dedicados e suporte técnico especializado facilita muito esse processo, especialmente em ambientes de produção com alto tráfego.

Conheça os planos de VPS da AviraHost e comece a otimizar seu TTFB hoje