Como funcionam os links curtos quando o cache entra na jogada
Você já tentou trocar o domínio de um encurtador e descobrir que metade dos seus usuários ainda chega na URL antiga por causa de DNS cache, proxy cache ou até cache do próprio navegador? Isso acontece com frequência suficiente para valer a pena entender o mecanismo por trás. A ideia básica é simples: você tem um link curto que redireciona para uma página mais longa, e em algum ponto dessa cadeia existe uma camada de cache que armazena o redirecionamento ou o conteúdo final. O problema é que esse cache nem sempre se comporta como todo mundo espera.
O que são curtos cacheados na prática
Quando alguém fala em curtos cacheados, normalmente está se referindo a links encurtados cujo redirecionamento foi armazenado em alguma camada intermediária — seja o servidor DNS, um CDN, um proxy corporativo ou o cache do navegador. O resultado é que a URL curta pode continuar apontando para um destino antigo mesmo depois de você ter atualizado o mapeamento no painel de controle. Isso não é bug, é exatamente o comportamento esperado de qualquer sistema de cache. O que as pessoas subestimam é a quantidade de camadas envolvidas entre o clique do usuário e a página final.
As camadas de cache que vão interferir nos seus links
DNS cache é a mais óbvia e a que mais causa confusão. Quando você resolve um domínio pela primeira vez, o sistema operacional e os resolvers intermediários guardam o IP por um tempo definido pelo TTL. Se você mudou o servidor de destino e o TTL era de 3600 segundos, os usuários com cache fresco vão continuar indo para o servidor antigo até esse tempo expirar. Reduzir o TTL para 60 segundos antes de fazer uma migração elimina esse problema na maioria dos casos. CDNs como Cloudflare ou AWS CloudFront também fazem cache de redirecionamentos HTTP. Um status 301 é particularmente traiçoeiro porque os navegadores e proxies começam a armazenar em cache permanente, na prática, mesmo que o servidor envie um TTL baixo. Já um 302 tem comportamento bem diferente e é o mais seguro quando você ainda não tem certeza se o destino final é estável.
Proxies corporativos e VPNs empresariais frequentemente mantêm caches de URLs acessadas, principalmente em ambientes Windows com NCSA proxy ou solutions de filtragem web. Isso significa que mesmo após expiração de DNS e cache de navegador, o usuário pode ainda ser redirecionado ao destino antigo pelo proxy da empresa. O cache do próprio navegador merece atenção separada. Firefox, Chrome e Safari tratam redirecionamentos de formas distintas. O Chrome armazena 301s num cache de redirecionamento persistente que só é limpo quando o usuário esvazia manualmente os dados de navegação. O Firefox segue a especificação RFC mais de perto mas ainda assim mantém entradas por um período considerável.
Um problema real que eu enfrentei
Há alguns meses precisei migrar um serviço de encurtamento de URLs para um novo domínio. O TTL do DNS estava em 300 segundos, usei redirecionamentos 302 ao invés de 301, e mesmo assim cerca de 15% dos usuários continuaram acessando o domínio antigo por mais de duas horas após a troca. Achei que fosse cache de DNS mas a resolução com dig flush e nslookup confirmava o novo IP corretamente. O problema estava nos cabeçalhos Cache-Control e nos redirect caches do Chrome. A solução foi implementar um header Vary: Accept que forçava o navegador a tratar cada requisição de forma independente, além de colocar um meta refresh de 0 segundos na página de destino do antigo domínio como fallback. O resultado foi que em cerca de 40 minutos a taxa de acesso ao domínio antigo caiu para menos de 2%. Sem o meta refresh como fallback, pelo menos 8% dos usuários nunca chegariam ao novo domínio sem intervenção manual.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Configuração prática para evitar dor de cabeça
Se você precisa controlar o comportamento de cache dos seus links curtos, existem algumas práticas que fazem diferença mensurável. Definir TTL de DNS em 60 segundos pelo menos três dias antes de qualquer mudança relevante no mapeamento dos links evita a maior parte dos problemas com cache de resolução. É um preço baixo a pagar em termos de aumento de consultas DNS, que hoje em dia é praticamente gratuito para a maioria dos provedores. Usar status 302 durante períodos de transição é outra coisa simples que resolve muitos casos. Se você realmente precisa de 301, configure Cache-Control: no-cache, no-store, must-revalidate e Pragma: no-cache no cabeçalho de resposta. Isso força navegadores e proxies a verificar a cada requisição se há uma versão atualizada disponível.
Para cenários mais complexos onde você controla tanto o encurtador quanto a página de destino, adicionar um parâmetro de versionamento na URL de destino elimina completamente o problema de cache. Uma URL como /landing?v=20240315 é tratada como entidade diferente a cada alteração de version, o que quebra qualquer mecanismo de cache baseado na URL. Se o seu encurtador permite configuração de headers personalizados, ative HSTS com max-age baixo durante o período de transição e desative após confirmar que todos os redirects estão funcionando. Isso previne que o preload list do navegador mantenha um redirecionamento permanente para o domínio antigo.
Pegadinhas comuns com curtos cacheados
A pegadinha mais comum é assumir que mudar o mapeamento no painel do encurtador é suficiente. Na maioria das plataformas, o mapeamento no banco de dados é resolvido rapidamente, mas o cache de DNS e de navegador continuam válidos. Pessoas que testam usando apenas o próprio navegador sem limpar o cache estão medindo o tempo errado e divulgando informações imprecisas para outras pessoas. A segunda pegadinha envolve ferramentas de monitoramento que fazem cache agressivo. Serviços como Uptime Robot, PageSpeed Insights e vários rastreadores de redes sociais podem ter indexado o link curto e continuar exibindo o conteúdo antigo mesmo após a migração. Se você está verificando se a mudança funcionou usando essas ferramentas, provavelmente está vendo o resultado errado.
Outro ponto que muita gente perde de vista: links compartilhados em aplicativos como WhatsApp, Telegram e LinkedIn passam por processadores de preview que fazem cache do conteúdo extraído. Mesmo que seu redirecionamento funcione perfeitamente, o preview mostrado no chat pode permanecer com o título e imagem antigos por dias. A maioria dos plataformas permite solicitar atualização do preview mas isso nem sempre funciona de forma instantânea.
Quando o cache não é o problema
Às vezes o que parece ser um problema de cache é na verdade algo completamente diferente. Links que param de funcionar podem ter sido desativados no encurtador, o domínio pode ter expirado, ou o serviço de encurtamento pode estar com problemas de indisponibilidade. Verificar isso antes de gastar tempo investigando cache evita perder horas com diagnósticos errados. Uma verificação rápida com curl -I no terminal mostra exatamente o que está acontecendo sem nenhuma interferência de cache do navegador. Se o cabeçalho Location apontar para o destino correto mas a página de destino retornar erro 404 ou 500, o problema não está no redirecionamento em si mas sim no destino final.
Para medições mais precisas, ferramentas como WebPageTest e HTTP Cache Analyzer permitem simular o comportamento de cache de diferentes navegadores e camadas de rede. Essas ferramentas revelam diferenças significativas no comportamento que passariam despercebidas em testes manuais com navegador. O básico que funciona na maioria dos cenários é reduzir TTL, usar 302 durante transições, configurar cache-control explicitamente, e adicionar versionamento nas URLs de destino quando possível. Nenhuma dessas medidas é complicada de implementar e juntas resolvem a grande maioria dos problemas que aparecem na prática com curtos cacheados.
