Como funciona o domínio de imagem e o contradomínio na prática
O assunto parece simples num primeiro olhar, mas quem já tentou configurar isso em produção conhece a dor. Vou explicar do jeito que eu faço quando preciso resolver isso pra equipe, sem teoria de livro.dominio imagem e contradominio — o que realmente acontece
Domínio de imagem é basicamente o servidor onde seus arquivos de mídia ficam hospedados. Pode ser o mesmo domínio do site principal ou um domínio totalmente separado. O contradomínio é o segundo domínio que serve como fallback quando o principal cai ou fica lento demais. Eu tinha um projeto e-commerce que levou 3 segundos pra carregar porque todas as imagens vinham do mesmo domínio que o backend. Quando o PHP começava a suar, as imagens travavam junto. Configurei um domínio separado pro CDN de imagens e outro como contradomínio de contingência. A página ficou responsável e o tempo de carregamento caiu pra menos de 800 milissegundos em média.
O problema é que muita gente acha que só precisa trocar o DNS e pronto. Não é bem assim. Tem regras de CORS, cache que precisa ser invalidado manualmente, e se você errar o TTL pode ficar com assets antigos rodando por horas.
O método que eu uso quando preciso implementar isso
Primeiro você define qual vai ser o domínio primário de imagem. Eu sempre recomendo usar um subdomínio separado tipo img.seusite.com em vez de um domínio completamente diferente. A razão é simples: certificado SSL mais barato, política de cookies diferente (imagens não precisam de cookie de sessão) e isolamento de tráfego. Depois vem o contradomínio. Aqui tem uma pegadinha que quase ninguém conta. O contradomínio não pode ter a mesma origem que o domínio primário senão o navegador trata como mesma política de segurança. Eu configurei como img-fallback.seusite.com e usei CNAME pointing pro mesmo origin server, mas com header differente de acesso control.
O passo seguinte é configurar o DNS. TTL baixo nos primeiros testes, tipo 300 segundos, pra poder reverter rápido se algo der errado. Depois de validar que funciona, sobe pra 3600 segundos ou mais. Eu já vi gente deixar TTL alto pra sempre e reclamar que as mudanças não surtiram efeito. Para o CORS, a configuração mínima que eu uso:
Access-Control-Allow-Origin: https://seusite.com Access-Control-Allow-Methods: GET, HEAD
Só isso. Não precisa de wildcard nem de credentials habilitados a menos que você tenha um motivo muito específico pra isso. E se habilitar credentials, esquece o wildcard no origin.
O caso real que me marcou
Tive um problema recentemente num projeto onde o contradomínio simplesmente não carregava as imagens. O DNS estava certo, o certificado SSL válido, o origin server respondendo normalmente. O problema era que o servidor web do domínio primário tinha uma regra de rewrite que redirecionava qualquer requisição com headers específicos. O contradomínio herdava essa regra e acabava looping em redirects. A solução foi adicionar uma condição no arquivo de configuração do Apache que excluía requisições vindas do domínio de imagem: RewriteCond %{HTTP_HOST} !^img-fallback\.seusite\.com$. Simples, mas demorei duas horas pra identificar porque o log não mostrava erro nenhum, só redirects seguidos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outra coisa importante: verifique o cache do seu CDN. Se você usa Cloudflare ou similar, o TTL de cache do domínio de imagem pode ser diferente do domínio principal. Configurei separately e usei purge manual sempre que fazia atualização de CSS ou JS crítico.
O que funciona e o que não funciona
Funciona bem quando você tem tráfego alto de imagens estáticas e quer isolar o domínio principal. O ganho de performance é real, especialmente com HTTP/2 que não sofre mais do problema de connection limiting. Não funciona tão bem quando você tem um site pequeno com menos de 5000 visitas por dia. O overhead de gerenciar dois domínios, certificados, logs separados e configurações de cache pode não valer a pena. Num site pequeno, um bom CDN já resolve 90% do problema sem precisar de contradomínio.
Também tem limitação importante: se seu origin server tem rate limiting baseado em IP ou domínio, o contradomínio pode burlar isso. Em alguns casos isso é feature, em outros é bug que causa problema de segurança. Já vi gente usar isso pra escalar ataques DDoS porque o rate limiter só protege o domínio principal.
Configuração básica que eu recomendo
No Nginx, uma configuração que eu uso como baseline: server {
listen 443 ssl;
server_name img.seusite.com;
root /var/www/images;
add_header Access-Control-Allow-Origin https://seusite.com;
add_header Cache-Control "public, max-age=86400";
location / {
try_files $uri $uri/ =404;
}
}
E no domínio contradomínio, basicamente a mesma coisa com um subdomínio diferente. O importante é garantir que ambos sirvam os mesmos arquivos do mesmo lugar.
dominio imagem e contradominio — links e ferramentas úteis
Se você quer testar a configuração antes de colocar em produção, use ferramentas como o curl com flags de verbose pra ver os headers de resposta. O comando curl -I https://img.seusite.com/foto.jpg mostra exatamente o que o navegador vai receber. Para verificar CORS funcionando, o site browserscope.org tem um testador online simples. Basta colocar a URL do seu domínio de imagem e testar.
Se estiver usando Docker, lembre-se que o container do domínio de imagem precisa ter acesso aos mesmos arquivos do container principal. Volume mount compartilhado ou sync via rsync são as opções mais práticas. Não recomendo usar domínio de imagem se seu site ainda está em desenvolvimento. O overhead de configurar e manter dois domínios separados costuma causar mais problemas do que soluções durante a fase de testes. Espere ter tráfego real e problemas de performance identificados antes de fazer essa migração.
