Cacheamento Básico com Nginx: Melhore os Tempos de Resposta

O cacheamento básico com Nginx pode melhorar os tempos de resposta ao salvar uma cópia das respostas upstream e servi-las novamente sem consultar a aplicação a cada vez. Quando usado com cuidado, o cache reduz a carga no backend, suaviza picos de tráfego e faz com que requisições repetidas pareçam mais rápidas.

O cache não é apenas para sites grandes. Mesmo uma aplicação pequena pode se beneficiar quando páginas, respostas de API ou arquivos estáticos são solicitados com frequência e não mudam a cada segundo.

O que o Nginx Pode Armazenar em Cache

O Nginx pode armazenar em cache respostas de um servidor upstream quando atua como proxy reverso. Isso é diferente do cache normal do navegador. O cache do navegador armazena arquivos no dispositivo do usuário. O cache de proxy do Nginx armazena respostas no servidor para que muitos usuários possam se beneficiar da mesma cópia em cache.

Uma configuração simples de cache de proxy tem duas partes. Primeiro, defina uma zona de cache no bloco http:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
    max_size=1g inactive=60m use_temp_path=off;

Em seguida, ative esse cache em um bloco server ou location:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_valid 404 1m;
    add_header X-Cache-Status $upstream_cache_status;
}

A diretiva proxy_cache_path cria a área de armazenamento do cache. keys_zone define a memória compartilhada para chaves de cache e metadados. max_size limita o uso do disco. inactive remove itens que não foram acessados por um tempo.

As diretivas proxy_cache_valid decidem por quanto tempo certos códigos de resposta permanecem em cache. No exemplo, respostas bem-sucedidas são armazenadas em cache por 10 minutos, enquanto respostas 404 são armazenadas por 1 minuto.

O cabeçalho X-Cache-Status é útil durante os testes. Ele pode mostrar valores como MISS, HIT, BYPASS ou EXPIRED, dependendo do que aconteceu.

Para sites que também usam Nginx como proxy reverso, isso combina naturalmente com a configuração de proxy reverso.

Decidindo o Que Deve Ser Armazenado em Cache

A parte mais difícil do cache com Nginx não é escrever as diretivas. É decidir qual conteúdo é seguro reutilizar.

Bons candidatos para cache incluem:

• Páginas públicas de marketing.
• Páginas públicas de documentação.
• Páginas de listagem de produtos que atualizam em um cronograma previsível.
• Respostas de API anônimas.
• Respostas upstream caras que são idênticas para muitos usuários.

Maus candidatos para cache incluem:

• Páginas de conta.
• Carrinhos de compras.
• Telas de administração.
• Respostas que incluem dados privados do usuário.
• Páginas que mudam com base em cookies ou cabeçalhos de autorização.

Se uma resposta é diferente para cada usuário, não a armazene em cache a menos que você tenha uma estratégia de chave de cache muito clara. Servir acidentalmente a resposta privada de um usuário para outro é um bug grave.

Você pode ignorar o cache quando as requisições incluem dados de sessão ou autorização:

proxy_cache_bypass $http_authorization;
proxy_no_cache $http_authorization;

Para sessões baseadas em cookies, você pode usar um padrão semelhante:

proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;

O nome exato do cookie depende da sua aplicação. Não copie isso cegamente sem verificar como sua aplicação lida com sessões.

Um cenário prático: sua página inicial pública de blog é gerada por uma aplicação e leva 300 milissegundos em um dia movimentado. Se você armazenar essa página em cache por 5 minutos, a maioria dos visitantes receberá a cópia em cache rapidamente, e a aplicação a regenerará apenas ocasionalmente. Esse é um caso de uso forte porque a página inicial é pública e não específica do usuário.

Chaves de Cache, Cabeçalhos e Limpeza

O Nginx usa uma chave de cache para decidir se duas requisições devem compartilhar a mesma resposta em cache. A chave de cache padrão geralmente é baseada em esquema, método, host e URI. Para muitos sites, isso é suficiente.

Se strings de consulta alteram a resposta, certifique-se de que elas façam parte da chave. Se strings de consulta são apenas parâmetros de rastreamento, você pode querer normalizá-las na aplicação ou na camada de CDN em vez de permitir que cada utm_source crie uma entrada de cache separada.

Os cabeçalhos de cache upstream também importam. Sua aplicação pode enviar cabeçalhos como:

Cache-Control: public, max-age=600

ou:

Cache-Control: private, no-store

O Nginx pode ser configurado para respeitar ou substituir esses cabeçalhos, mas você deve escolher uma política clara. Se os desenvolvedores da aplicação esperam que Cache-Control: no-store impeça o cache, substituir esse comportamento no Nginx pode criar resultados confusos e arriscados.

A limpeza é outra questão operacional. O Nginx de código aberto não inclui um endpoint simples de limpeza de cache embutido da mesma forma que alguns módulos comerciais ou de terceiros. Muitas equipes lidam com isso usando durações curtas de cache, URLs versionados ou scripts de implantação que limpam o diretório de cache durante lançamentos controlados.

TTLs curtos geralmente são suficientes. Um cache de 60 segundos em um endpoint movimentado ainda pode remover uma grande quantidade de tráfego do backend enquanto mantém o conteúdo razoavelmente atualizado.

Testando o Comportamento do Cache

Após habilitar o cache, solicite a mesma URL várias vezes e inspecione os cabeçalhos de resposta:

curl -I https://example.com/

Se você adicionou X-Cache-Status, a primeira requisição pode mostrar MISS, e requisições posteriores devem mostrar HIT. Se toda requisição for MISS, verifique os cabeçalhos de resposta, as regras de bypass de cache, os cookies da requisição e se o diretório de cache pode ser gravado pelo processo de trabalho do Nginx.

Teste também o comportamento de usuário logado e não logado. É aqui que muitos erros de cache aparecem. Abra uma janela de navegador privada, faça login como usuário de teste e confirme que páginas privadas não são armazenadas em cache publicamente.

Monitore também o uso do disco. Um cache sem limite prático pode encher um sistema de arquivos. Use max_size, mantenha o armazenamento de cache separado de partições críticas do sistema quando possível e alerte sobre pressão no disco.

Quando Buscar Ajuda

Traga um engenheiro experiente em Nginx ou plataforma se o conteúdo em cache aparecer sob o usuário errado, se sua taxa de acerto de cache permanecer baixa após ajustes, ou se os arquivos de cache estiverem enchendo o disco inesperadamente. Problemas de cache podem parecer simples enquanto escondem comportamentos específicos da aplicação.

Você também deve buscar ajuda antes de armazenar em cache APIs autenticadas, painéis multi-inquilinos ou fluxos relacionados a pagamentos. Essas áreas precisam de design cuidadoso.

O cacheamento básico com Nginx funciona melhor quando você começa com respostas públicas e repetíveis e durações curtas de cache. Adicione cabeçalhos visíveis de status de cache durante os testes, respeite os limites de conteúdo privado e meça tanto o tempo de resposta quanto a carga do backend. Feito corretamente, o cache dá aos usuários páginas mais rápidas enquanto dá à sua aplicação espaço para respirar.