Correções para loop de redirecionamento em domínio personalizado — www, apex, cookies e TLS

O que se quebra quando você adiciona um domínio tardiamente

Adicionar um domínio personalizado depois que seu app já funciona em uma URL padrão parece simples. Na prática, o app frequentemente continua “lembrando” o endereço antigo. Seu provedor de domínio, camada de hospedagem, CDN/proxy e configurações do app podem tentar ajudar redirecionando o tráfego. Se dois lugares discordarem, usuários podem ficar presos rebatendo entre URLs.

Os primeiros sinais costumam ser óbvios:

• Páginas que recarregam sem parar
• Erros de “Muitos redirecionamentos”
• Uma página inicial que carrega só às vezes

Login é outro sintoma clássico. Um usuário faz login, é enviado de volta ao app e acaba na tela de login novamente porque o cookie de sessão não fica.

Mudanças de domínio tardias têm mais chance de quebrar porque suposições já estão embutidas. Regras de redirecionamento foram criadas para a URL original (como um domínio de preview de plataforma). Cookies estavam escopados para o host antigo. TLS e configurações de segurança foram emitidos para um hostname e não para o outro.

Uma pequena incompatibilidade pode disparar vários sintomas ao mesmo tempo. Por exemplo, forçar HTTPS na CDN enquanto o app também força HTTPS (e ambos reescrevem www para o apex de formas diferentes) pode criar um loop. Paralelamente, se seu domínio de cookie estiver definido para www.example.com mas os usuários caírem em example.com, o login pode falhar mesmo que os redirecionamentos pareçam “certos”.

Um cenário comum: seu protótipo construído por IA funcionava em uma URL de Replit. Você adiciona www.yourapp.com depois, aponta o DNS e de repente metade dos usuários vê erros de redirecionamento e a outra metade não consegue permanecer logada.

O objetivo é direto: uma URL canônica (ou www ou o apex) que permaneça estável, mantenha sessões e carregue corretamente por HTTPS.

Termos chave: www, apex, redirecionamentos, cookies e TLS

Loops de redirecionamento raramente são uma grande falha única. Geralmente são alguns ajustes pequenos em desacordo.

Domínio apex vs subdomínio www: o domínio apex é o nome raiz, como example.com. A versão www é um subdomínio, como www.example.com. Ambos podem apontar para o mesmo app, mas você deve escolher um como o endereço canônico.

Redirecionamento: um redirecionamento diz ao navegador “vá para ali”. Por exemplo, enviar example.com para www.example.com. Um loop de redirecionamento ocorre quando o navegador fica preso rebatendo entre dois endereços (ou regras), como www -> apex -> www -> apex, até desistir.

Loops geralmente acontecem quando seu app redireciona de uma forma e outra camada (hospedagem, CDN, proxy, configurações da plataforma) redireciona de volta.

TLS/SSL: TLS é o que coloca o cadeado no navegador. Ele criptografa o tráfego e prova que o site corresponde ao hostname. Se o TLS estiver faltando, emitido para o host errado (apenas www mas não o apex, ou o inverso), ou misturado com regras HTTP antigas, navegadores podem avisar usuários, bloquear requisições ou falhar silenciosamente ao carregar arquivos importantes.

Cookies e sessões de login: cookies são pequenos dados que o navegador armazena para um site, frequentemente usados para manter você logado. Cookies são rígidos sobre onde se aplicam. Os problemas mais comuns são:

• Domínio do cookie: um cookie definido para www.example.com não funcionará de forma confiável em example.com.
• Secure: muitos cookies de autenticação devem ser enviados apenas via HTTPS.
• SameSite: afeta fluxos de login, especialmente quando há redirecionamentos ou provedores de terceiros.

Se seu app “loga” e em seguida manda você de volta ao login, uma incompatibilidade de domínio de cookie é uma das primeiras coisas a checar.

Por que loops acontecem com www e apex

Um loop normalmente significa que várias regras de redirecionamento estão sendo acionadas. Uma regra diz “vá para https”, outra diz “vá para www” e uma terceira diz “volte para o apex”. Cada regra pode parecer razoável sozinha. Juntas, criam um rebote do qual o navegador não escapa.

O gatilho mais comum é ter mais de um lugar fazendo redirecionamentos ao mesmo tempo. Seu app pode forçar HTTPS, seu painel de hospedagem pode forçar www e uma configuração de CDN ou framework também pode reescrever o host.

A ordem também importa. Se HTTP -> HTTPS acontece primeiro e depois www -> apex acontece (ou o contrário), você pode acidentalmente rebatir entre duas URLs “canônicas”. Isso é fácil de introduzir quando você adiciona um domínio tardiamente e copia configurações de ambientes antigos sem checar como elas se combinam.

Confusão de proxy é outra causa frequente. Seu app pode receber tráfego por HTTP da plataforma (a conexão de origem), embora os usuários visitem por HTTPS. Se cabeçalhos proxy como X-Forwarded-Proto estiverem faltando ou forem ignorados, o app acha que deve atualizar para HTTPS, e a plataforma então reaplica suas próprias regras.

Redirecionamentos em cache podem fazer o problema parecer aleatório. Navegadores cacheiam respostas 301, e CDNs também podem cached-as. Você corrige as regras, mas sua máquina de teste continua em loop porque ainda honra um redirecionamento antigo.

Algumas formas rápidas de reduzir a causa:

• Teste em uma janela privada para reduzir efeitos de cache do navegador.
• Verifique uma requisição no DevTools Network e leia os cabeçalhos Location.
• Desative temporariamente redirecionamentos no app ou no host para encontrar a regra “extra”.
• Confirme se os cabeçalhos proxy/forwarded estão configurados como seu app espera.

Passo a passo: escolha um domínio canônico e corrija redirecionamentos

Um loop de redirecionamento geralmente significa que duas (ou mais) camadas estão discutindo onde seu site “deveria” ficar. A correção mais rápida é escolher uma URL canônica e fazer todas as outras versões apontarem para ela.

Primeiro, decida se quer o apex ou a versão www como endereço principal. Qualquer um serve. Consistência é o que importa entre DNS, TLS, configurações do app e redirecionamentos.

Uma correção simples em 5 passos

1. Escolha o host canônico: escolha https://example.com ou https://www.example.com. Anote.
2. Escolha um lugar para redirecionar: faça redirecionamentos em uma única camada sempre que possível (edge/CDN, load balancer ou app). Múltiplas camadas são a causa usual de loops.
3. Crie uma regra única: redirecione o host não canônico para o canônico, mantendo o mesmo caminho e query string. Evite regras extras de “limpeza” até que o básico funcione.
4. Faça o app gerar o host canônico: verifique configurações como base URL, public URL, site URL e auth callback URL. Se o app gerar links absolutos com o host errado, usuários irão rebotar entre domínios.
5. Teste em um estado limpo do navegador: use uma janela privada ou um perfil novo para que cookies antigos e redirecionamentos em cache não escondam o comportamento real.

Depois de aplicar o redirecionamento, confirme que você não está também forçando redirecionamentos dentro do app (por exemplo, “enforce HTTPS” junto com uma regra de edge que reescreve protocolo/host). Um redirecionamento é suficiente.

Um checape rápido: digite ambas as variantes (www e apex) na barra de endereço. Você deve chegar na mesma URL final todas as vezes, com no máximo um redirecionamento. Se alternar, algo ainda está redirecionando e precisa ser removido ou desabilitado.

Problemas de domínio de cookie que quebram login e sessões

Se o login funciona em um host (por exemplo, www.example.com) mas falha em outro (example.com), geralmente são os cookies. Sinais comuns: telas de “por favor entre” sem fim, sessões que desaparecem ao atualizar, ou usuários sendo deslogados ao mudar de host.

Um erro frequente é definir o Domain do cookie no lugar errado. Se você definir Domain=www.example.com, esse cookie não será enviado para example.com (e não cobrirá outros subdomínios). Se precisar de uma sessão compartilhada entre subdomínios, normalmente usa-se Domain=example.com (o apex). Se não precisar de compartilhamento, cookies específicos do host (sem o atributo Domain) costumam ser mais seguros porque não vazam para outros subdomínios.

Mudanças para HTTPS também podem quebrar sessões. Após uma migração tardia, apps costumam passar a forçar HTTPS. Se o cookie de sessão não tiver Secure, navegadores podem recusar enviá-lo em requisições HTTPS. Se SameSite estiver muito restritivo, etapas cross-site como login OAuth ou páginas de retorno de pagamento podem falhar silenciosamente, deixando o usuário “logado” em uma aba e anônimo em outra.

Subdomínios adicionam outra armadilha: app.example.com e api.example.com podem precisar concordar sobre escopo de cookie. Se seu frontend espera um cookie de autenticação que foi definido pela API, ambos devem usar domínios compatíveis, e suas configurações de CORS e credenciais devem permitir o envio de cookies.

Para confirmar o que acontece, abra o DevTools do navegador e cheque:

• Quais cookies são definidos após o login, e seus valores de Domain, Path, SameSite e Secure
• Se o cookie aparece tanto em www quanto no apex
• Se as requisições mostram um cabeçalho Cookie sendo enviado ou se o navegador está descartando-o

Problemas de cookie muitas vezes são confundidos com problemas de redirecionamento. Às vezes a cadeia de redirecionamentos está correta, mas a sessão não persiste, então o app continua enviando os usuários de volta para o login.

Configurações de TLS que causam avisos, bloqueios e carregamentos falhos

Problemas de TLS muitas vezes parecem “o site está fora do ar”, mas o real é que o navegador se recusa a confiar no que vê. Durante uma mudança de domínio, pode parecer inconsistente porque alguns usuários acessam www enquanto outros acessam o apex.

Comece pelo básico: seu certificado deve cobrir exatamente os hostnames que você serve. Uma incompatibilidade comum é ter um certificado para www.example.com apenas, enquanto o DNS ou os redirecionamentos ainda permitem usuários aterrissar em example.com (ou vice-versa). Navegadores tratam esses nomes como diferentes.

Saiba onde o HTTPS realmente termina

O HTTPS pode terminar em diferentes pontos: uma CDN, um load balancer, um reverse proxy ou seu servidor de aplicação. Problemas começam quando uma camada pensa que o tráfego é HTTPS mas a camada seguinte acha que é HTTP. Isso pode causar loops (o app continua “atualizando” para HTTPS) e pode quebrar cookies marcados como Secure.

Se não tiver certeza, verifique:

• Qual componente tem o certificado TLS anexado (CDN, load balancer ou servidor)
• Se o app recebe um cabeçalho original de protocolo (frequentemente X-Forwarded-Proto)
• Se o app está configurado para confiar no proxy
• Se rotas www e apex são tratadas da mesma forma

HSTS e mixed content: duas formas fáceis de ficar preso

HSTS diz ao navegador “sempre use HTTPS para este domínio”. Se você ativar HSTS antes de o HTTPS estar correto em todo lugar (incluindo redirects, APIs e subdomínios), pode prender usuários em falhas que são difíceis de reverter rapidamente.

Conteúdo misto é o outro problema silencioso. Se seu HTML carregar scripts, imagens ou CSS via http, o navegador pode bloqueá-los em uma página https. O resultado pode parecer “o botão de login não faz nada” ou “a página carrega sem estilos”.

Armadilhas de configuração do app: proxies, base URLs, callbacks de auth

Muitos problemas de “redirecionamento” não são realmente sobre DNS. São seu app e sua plataforma de hospedagem discutindo qual é a URL pública real.

Proxies e os cabeçalhos que seu app confia

Se seu app fica atrás de um reverse proxy ou CDN (comum em hosts gerenciados), a requisição que chega ao servidor pode parecer HTTP, mesmo quando o visitante usou HTTPS. Apps lidam com isso usando cabeçalhos como X-Forwarded-Proto e X-Forwarded-Host.

Se seu framework não confiar nesses cabeçalhos, pode entender cada requisição como insegura e forçar um redirecionamento para HTTPS. Se a plataforma já estiver forçando HTTPS, o usuário pode ficar rebatendo entre regras.

Também preste atenção em configurações como “force HTTPS”, “trust proxy” e “secure cookies only”. São boas configurações, mas devem bater com a forma como sua plataforma termina o TLS.

Base URLs, callbacks, CORS e integrações

Uma vez que você escolha um host canônico (www ou apex), atualize todo lugar que armazene uma URL completa. Se mesmo uma única configuração ainda apontar para o host antigo, você pode ter logins quebrados, handshakes OAuth falhando ou chamadas de API que falham sem muito feedback.

Lugares comuns que precisam atenção:

• Base URL do app (usada para construir links absolutos e redirecionamentos)
• URLs de callback/redirect de autenticação (provedores OAuth são rígidos)
• Origens permitidas para CORS (o host do frontend deve bater exatamente)
• Endpoints de webhook (pagamentos, email, CRM, etc.)
• Variáveis de ambiente como NEXTAUTH_URL, PUBLIC_URL ou similares

Exemplo: sua página de login está em https://www.example.com, mas seu provedor OAuth está configurado com https://example.com/auth/callback. O provedor redireciona de volta para o apex, seu app redireciona para www, e o provedor rejeita a resposta porque a URL de callback não bate mais.

Erros comuns que pioram o problema

A maioria dos problemas de domínio piora quando você muda configurações em três lugares ao mesmo tempo. Um redirecionamento que parece inofensivo no app pode brigar com um redirecionamento na CDN ou no painel de hospedagem, e você acaba com um loop difícil de identificar.

O padrão “funcionou por um minuto, depois quebrou de novo” geralmente significa que cache está envolvido. O navegador cacheou um redirecionamento, um proxy cacheou outro, e agora requisições seguem caminhos diferentes dependendo de onde partem.

Erros que causam mais problemas:

• Ativar redirecionamentos em múltiplas camadas (painel de hospedagem, CDN/edge e app).
• Adicionar mais redirecionamentos até que um pareça funcionar, enquanto quebra chamadas de API, callbacks ou assets.
• Esquecer que cookies de login e callbacks de autenticação ainda estão ligados ao domínio antigo.
• Habilitar HSTS cedo demais.
• Testar apenas em um perfil de navegador e não ver o que novos usuários veem.

Um hábito simples de testes evita horas de investigação: verifique em um perfil limpo (ou incógnito), depois em um segundo navegador e em mobile. Se o comportamento difere, provavelmente você está brigando contra cache, cookies ou HSTS, não contra sua última regra de redirecionamento.

Checagens rápidas antes de dar como resolvido

Antes de parar de depurar, faça checagens em uma janela normal (não incógnita) e em uma janela incógnita. Problemas de redirecionamento e cookie muitas vezes estão escondidos até você repetir um fluxo de login.

Checagens de redirecionamento (a regra do “exatamente uma vez”)

Digite cada variante na barra de endereço e observe a URL final. Você quer um salto limpo, não um rebote entre hosts ou protocolos.

• http://yourdomain.com deve ir para https:// exatamente uma vez.
• http://www.yourdomain.com deve ir para https:// exatamente uma vez.
• O host não canônico (www ou apex) deve redirecionar para seu host canônico exatamente uma vez.
• Colar a URL canônica final novamente não deve mais redirecionar.

Mesmo que um host sempre redirecione, ambos devem apresentar um certificado válido durante o handshake TLS.

Checagens de sessão e cadeado

Faça login no host canônico, depois atualize, feche a aba e reabra o site. Se você for deslogado, suspeite de incompatibilidade de domínio de cookie, SameSite ou um callback apontando para o host errado.

Também verifique os indicadores de segurança do navegador. Você deve ver o cadeado válido tanto no apex quanto no www (mesmo que um redirecione imediatamente). Abra algumas páginas-chave e confirme que não há avisos de conteúdo misto (por exemplo, um script ou imagem antiga em http://).

Um exemplo realista: adicionar um domínio após um protótipo gerado por IA

Um fundador envia um protótipo gerado por IA a partir de uma URL de preview (como um subdomínio de plataforma). Cadastros funcionam, dashboard carrega e pagamentos passam em um teste rápido. Depois adicionam um domínio personalizado na noite antes de uma demo e tudo desanda: o site rebota entre www e o apex, o login continua jogando de volta para a tela de login e o navegador mostra avisos de segurança.

O que mudou não é só uma coisa. O navegador agora vê um host diferente, então cookies podem não bater. Provedores OAuth (Google, GitHub etc.) podem rejeitar o redirect porque a callback mudou. E a camada de hospedagem pode começar a forçar HTTPS enquanto o app ainda gera URLs HTTP internamente.

Um plano de recuperação:

• Escolha um host canônico (www ou apex) e faça tudo apontar para ele.
• Faça redirecionamentos em um só lugar e vise um único salto: não-canônico -> canônico.
• Ajuste escopo de cookies para o plano canônico e marque cookies de auth como Secure quando usar HTTPS.
• Atualize configurações de auth: callback URLs, origens permitidas e qualquer base URL hardcoded.
• Reteste em uma sessão de navegador limpa para evitar cookies antigos mascarando o problema.

Se você se pega mudando três painéis ao mesmo tempo (config do app, provedor de auth, regras de hospedagem) e o comportamento continua mudando, pare e simplifique. Loops de redirecionamento e bugs de sessão podem parecer aleatórios porque um cookie antigo ou um passo extra de redirecionamento altera o resultado.

Próximos passos: consolidar uma configuração de domínio estável

Anote primeiro sua URL fonte-de-verdade. Inclua esquema e host, como https://www.example.com (ou o apex). Seja explícito sobre a única regra de redirecionamento que quer: todo outro host deve aterrissar nessa URL exata com um único 301.

Em seguida, liste todo lugar que pode redirecionar requisições ou influenciar sessões: configurações de domínio/DNS, regras de CDN/edge, load balancers ou proxies, base URL do app e callbacks de auth, e configurações de cookie/sessão. O objetivo é propriedade simples: um lugar lida com redirecionamentos, um lugar termina o TLS e um lugar define a base pública.

Se o app foi gerado por ferramentas como Lovable, Bolt, v0, Cursor ou Replit, assuma que há defaults ocultos e drift de configuração. Um protótipo pode funcionar em um host porque um framework detecta URLs automaticamente, depois falhar após uma mudança tardia quando você adiciona um proxy, uma CDN ou uma política HTTPS mais rígida.

Se você estiver preso em um loop e a base de código estiver bagunçada, a FixMyMess (fixmymess.ai) se especializa em diagnosticar e reparar apps gerados por IA, incluindo regras de redirecionamento, escopo de cookie/sessão e configurações TLS/proxy. Uma auditoria de código gratuita pode identificar rapidamente o punhado de incompatibilidades que está causando toda a reação em cadeia.