Link de preview funciona, mas o site ao vivo falha: o que verificar

O que “preview funciona” e “vivo falha” realmente significa

Um link de preview é uma versão temporária do seu app rodando em um ambiente controlado pelo seu builder ou host. Ele costuma usar um domínio padrão, configurações por omissão e um ambiente “amigável” onde menos regras atrapalham.

Um site ao vivo é seu domínio real com configurações de produção de verdade. Os navegadores o tratam diferente: cookies são anexados ao domínio, regras de HTTPS se aplicam, e seu app precisa conversar com o backend certo com as permissões certas.

Então quando alguém diz “o link de preview funciona mas o site ao vivo falha”, geralmente quer dizer que o app parece ok na demo e então quebra quando encontra as regras do domínio real.

A falha pode aparecer de algumas formas comuns: uma página em branco ou spinner infinito, loop de login (login e volta pra tela de login), botões que não fazem nada porque chamadas à API falham, dados faltando mesmo com a UI carregada, ou erros que só acontecem no domínio ao vivo.

Além disso, “funciona” pode enganar. Muitos apps gerados por IA “funcionam” em preview porque a UI renderiza. As partes importantes falham silenciosamente em produção: requisições à API, autenticação, uploads, pagamentos ou leituras do banco.

Um exemplo simples: no preview, seu app chama uma API usando uma URL de teste e CORS permissivo, então as requisições dão certo. No domínio ao vivo, as mesmas chamadas são bloqueadas, ou o app ainda aponta para localhost. A página carrega, mas os dados nunca aparecem.

Por isso a primeira pergunta não é “carrega?” e sim “as chamadas de rede têm sucesso no domínio ao vivo?” Se você herdou um protótipo gerado por IA, uma auditoria rápida de código (como a que a FixMyMess faz) costuma achar a discrepância rápido: uma variável de ambiente errada, um cookie atrelado ao domínio de preview ou uma regra HTTPS que o preview não exigia.

Diferenças de domínio que mudam o comportamento do app

Quando o preview funciona e o vivo falha, desconfie do hostname desde cedo. Navegadores tratam app-preview.example e example.com como lugares diferentes, mesmo com o código idêntico. Isso muda quais cookies são enviados, quais regras de segurança se aplicam e quais URLs seu app pode chamar.

Uma armadilha comum é mover de um domínio temporário de preview para um domínio real e assumir que tudo se mantém. Na prática, muitas configurações estão atreladas a uma origem exata (scheme + host + port). Uma diferença de um caractere pode transformar funcionalidades que funcionavam em recursos quebrados.

Subdomínio vs domínio raiz: pequena mudança, grande impacto

Mover de app.example.com para example.com (ou vice-versa) pode quebrar comportamentos que dependem do escopo do domínio. Cookies podem ser definidos para um host e não aparecerem no outro. Algumas configurações de autenticação também esperam um domínio específico para callbacks e origens permitidas.

O mesmo vale para www vs non-www. Se seu site ao vivo redireciona de www.example.com para example.com, seu app pode carregar mas o login falhar porque o provedor de auth vê uma URL de callback diferente da registrada.

As incompatibilidades de domínio que mais causam falhas imediatas são:

• www vs non-www (redirecionamentos mudam a URL final)
• domínio raiz vs subdomínio (escopo de cookie e origens permitidas diferem)
• hostnames de preview diferentes por deploy (URLs hardcoded deixam de bater)
• domínios de staging vs produção (configurações de auth e API apontam para o lugar errado)
• barra final ou diferenças de path em URLs de callback (alguns provedores tratam como diferentes)

Um exemplo rápido: seu preview roda num domínio temporário e o provedor de login foi configurado com esse callback. Você lança em www.yourapp.com, o provedor rejeita o callback e os usuários veem página em branco ou loop de login. Nada na UI explica o motivo.

Isso é ainda mais comum em apps gerados por IA porque domínios acabam hardcoded em vários pontos (frontend, backend, configurações de auth). A FixMyMess frequentemente encontra vários lugares onde um único hostname precisa bater exatamente para a produção se comportar como o preview.

Configurações de ambiente: o quebra-produção silencioso

Ambientes de preview frequentemente “simplesmente funcionam” porque a plataforma injeta valores padrão discretamente. Seu site ao vivo geralmente não. Essa lacuna é uma das principais razões do preview ter sucesso enquanto a produção falha, mesmo com código idêntico.

Um padrão comum é que o preview injeta uma URL de API de fallback, um banco de dados de demonstração ou um modo de auth permissivo. A produção espera valores reais. Quando faltam, o app continua rodando mas se comporta de forma estranha: botões não fazem nada, páginas mostram estados vazios ou todas as requisições falham.

Os problemas de ambiente mais comuns em produção parecem com isto:

• Falta uma variável obrigatória (base URL da API, segredo de auth, URL do banco, chaves de pagamento).
• Um valor está presente mas errado (endpoint de dev, chave de teste, domínio de staging antigo).
• Variáveis são definidas num lugar mas lidas em outro (definido no dashboard do host, mas o build espera um .env em build time).
• Nomes não coincidem exatamente (NEXT_PUBLIC_API_URL vs NEXT_PUBLIC_API_BASE).
• O valor tem um erro sutil (barra extra, região errada, client ID incorreto).

Outra armadilha é onde a variável é usada. Variáveis client-side acabam no navegador, então devem ser seguras para expor. Variáveis server-side ficam no servidor, mas só se o código realmente rodar server-side. Apps gerados por IA às vezes vazam segredos para o frontend. Isso pode “funcionar” no preview mas falhar em produção quando chaves são rotacionadas ou regras de segurança entram em vigor. É também um risco real de segurança.

Para detectar um problema de env rapidamente, verifique logs ao vivo e o console do navegador por:

• erros mencionando undefined ou null
• respostas 401/403 (chave ruim, audience/issuer errado)
• requisições indo para o host errado (domínio de dev aparecendo em produção)
• erros de build/start como “Missing required env var”

Exemplo: o login funciona no preview porque usa um callback do preview, mas a produção ainda aponta para o domínio de preview. O provedor de auth rejeita e os usuários veem 401 ou loop de login.

Se você herdou um código gerado por IA e não sabe de onde vem um valor, a FixMyMess pode rodar uma auditoria gratuita e listar o que está faltando ou mal configurado antes de você alterar qualquer coisa.

HTTPS, redirects e problemas de conteúdo misto

Um preview pode funcionar porque roda num domínio da plataforma com setup conhecido. Ao mover para seu domínio, o navegador fica mais rígido. Pequenas misconfigurações podem impedir o app de carregar, logar ou chamar APIs.

HTTPS é mais rígido do que a maioria dos setups de preview

HTTPS não é só um ícone de cadeado. Ele muda o que o navegador permite. Requisições podem ser bloqueadas, cookies se comportarem de forma diferente e redirects podem criar loops que não apareciam no preview.

Um exemplo típico: o site ao vivo carrega em https://, mas o app ainda chama a API em http://api.example.com. No preview, você pode não notar porque tudo está no mesmo domínio da plataforma ou os avisos passam despercebidos.

Conteúdo misto: o bloqueador silencioso

Conteúdo misto acontece quando uma página HTTPS carrega algo por HTTP (chamadas de API, imagens, scripts). Navegadores modernos frequentemente bloqueiam essas requisições, o que pode fazer o app parecer “quebrado” sem erro claro na tela.

Para confirmar rápido:

• Abra o site ao vivo (não o preview).
• Abra o console do navegador e recarregue.
• Procure por “Blocked mixed content” ou erros similares.
• Verifique o painel Network por requisições bloqueadas, canceladas ou presas em redirects.

Redirects, HSTS e loops

Loops de redirect surgem quando múltiplas camadas discordam. Por exemplo:

• o app força HTTPS, mas a plataforma de hospedagem já faz isso
• um CDN força www, mas o app força non-www
• HSTS está habilitado, então o navegador se recusa a tentar HTTP de novo

Quando isso acontece, a página pode piscar, recarregar sem parar ou falhar antes de qualquer código seu rodar.

Certificados também importam. Se o certificado for inválido ou não emitido ainda para o domínio customizado, alguns navegadores bloqueiam requisições ou impedem flows de sign-in de abrirem corretamente.

Se o console estiver cheio de avisos de conteúdo misto e erros de redirect, a FixMyMess normalmente começa mapeando cada requisição que o app faz no vivo e então corrige URLs HTTPS e regras de redirect para que a produção se comporte como o preview.

Cookies e autenticação: por que logins falham no vivo

Quando o preview funciona e o vivo falha, o login costuma ser a primeira coisa a quebrar. O preview parece “normal”, mas o domínio ao vivo muda como o navegador trata cookies, redirects e storage de sessão.

Cookies estão atrelados a um domínio. Se o preview roda num domínio da plataforma e o vivo roda no seu domínio customizado, o navegador pode parar de enviar o cookie de sessão mesmo sem mudança de código.

Flags de cookie que causam surpresas

Três configurações decidem se seu cookie de login sobrevive à mudança para o vivo:

• Escopo do domínio: um cookie definido para preview.example-host.com não será enviado para www.yourdomain.com. Hardcodar o domínio do cookie costuma funcionar no preview e falhar silenciosamente no vivo.
• SameSite: logins baseados em redirect (Google, GitHub, magic links) podem quebrar se SameSite=Strict bloquear o cookie no retorno. Lax é frequentemente mais seguro para fluxos básicos.
• Secure: cookies Secure são enviados apenas por HTTPS. Se seu site ao vivo tiver uma etapa HTTP (ou uma cadeia de redirects confusa), o cookie pode nunca ser persistido.

Sintomas típicos:

• o login “sucede” mas você volta para a página de login
• loop de login: login, redirect, login de novo
• funciona uma vez em uma janela anônima, depois falha
• funciona no preview e falha só no domínio real

OAuth e auth hospedada: origens permitidas e redirect URIs

Provedores de auth não confiam automaticamente no seu domínio customizado. Ambientes de preview às vezes são liberados por padrão, enquanto seu domínio real não. O provedor pode rejeitar o callback, ou seu app pode receber o callback mas falhar na troca de código porque a origem não confere.

Exemplo: o preview usa https://random-preview-host.com e o provedor está configurado para ele. Você muda para https://app.yourdomain.com, mas o provedor ainda permite só a origem do preview. O redirect parece ok, então você cai numa página em branco, num toast de erro ou na tela de login novamente.

Antes de mexer no código, faça estas verificações no devtools:

• Confirme que o site ao vivo está totalmente em HTTPS sem etapas HTTP.
• Inspecione o header Set-Cookie (Domain, SameSite, Secure, expiry).
• Verifique se o cookie aparece no storage do domínio ao vivo e é enviado na próxima requisição.
• Para OAuth, confirme que o domínio ao vivo está listado em origens permitidas e nas configurações de redirect/callback.

Auth quebrada é uma reparação comum da FixMyMess. Nós rastreamos o cookie e o caminho de redirect de ponta a ponta e ajustamos as configurações desniveladas para que o login funcione de forma confiável no domínio ao vivo.

CORS e chamadas de API bloqueadas só no vivo

Às vezes a UI carrega, mas todas as chamadas de dados falham porque o navegador se recusa a deixar seu frontend chamar sua API. Essa recusa é CORS (Cross-Origin Resource Sharing). Em termos simples: o navegador bloqueia um site de fazer requisições para um domínio diferente, a menos que o servidor permita explicitamente.

Isso aparece mais no vivo do que no preview porque hosts de preview às vezes são “especialmente permitidos”. Sua API pode permitir requisições do domínio de preview, mas não do seu domínio real.

Como falhas de CORS se manifestam

No console ou na aba Network você verá “blocked by CORS policy” ou uma requisição preflight que falha. Um preflight é uma requisição OPTIONS automática que o navegador envia primeiro para perguntar “isso é permitido?”

Preflights ocorrem mais do que se pensa. Enviar JSON com headers customizados, usar métodos como POST/PUT ou incluir credenciais (cookies) pode gerar preflights. Se o servidor não responder OPTIONS corretamente, o navegador bloqueia a chamada real, mesmo que a API responda em ferramentas como curl.

No lado da API (ou função serverless), as checagens de maior impacto são:

• permitir a origem exata do site ao vivo (scheme + domínio + porta)
• se enviar cookies/headers de auth, permitir credenciais e não usar origem coringa (*)
• permitir os headers que você realmente envia (frequentemente Content-Type, Authorization)
• permitir os métodos usados e responder corretamente a OPTIONS
• confirmar que seu proxy reverso/CDN não está removendo cabeçalhos CORS em produção

Um cenário comum: um app gerado por IA chama api.myapp.com a partir de preview.mytool.app e funciona. Após o lançamento, o frontend roda em myapp.com, mas a API ainda só permite preview.mytool.app, então login e salvamentos falham no navegador.

Se você estiver travado, a FixMyMess costuma encontrar problemas de CORS junto de bloqueadores relacionados (como cookies não sendo enviados por causa de configurações de credenciais) e verifica a correção com testes reais em navegador antes do relançamento.

Cache, service workers e deploys obsoletos

Às vezes nada está “quebrado” no código. O domínio ao vivo simplesmente está servindo uma versão antiga. Previews frequentemente ignoram camadas de cache que seu domínio real usa.

Quando caches servem a versão errada

Um CDN ou cache do navegador pode manter bundles JavaScript antigos mesmo depois de um redeploy. Se seu build gera arquivos como app.123.js, mas o HTML ainda aponta para app.122.js, os usuários carregam uma mistura de arquivos antigos e novos. O resultado parece aleatório: botões param de funcionar, páginas ficam em branco ou aparecem erros que você não reproduz localmente.

Sinais comuns de ativos obsoletos:

• a UI parece uma versão antiga após um deploy
• arquivos JavaScript ou CSS retornam 404 na aba Network
• erros mencionam chunks faltando ou “unexpected token” em um arquivo JS
• só alguns usuários veem o problema (freqüentemente mobile)
• atualizar muda o comportamento

Service workers: uma versão ruim pode persistir

Se seu app tem um service worker (comum em templates PWA), ele pode continuar servindo uma shell em cache do site. Uma release ruim pode ser instalada e continuar carregando mesmo depois da correção. Usuários podem precisar fechar todas as abas, ou o fluxo de atualização do service worker precisa ser consertado.

Outra armadilha fácil é a mudança da base URL. Se você mudou do subdomínio de preview para seu domínio real, ou alterou o caminho onde o app é hospedado, caminhos para ativos estáticos podem quebrar. Você verá 404s para arquivos que existem, só não no path que o navegador está pedindo.

Testes rápidos que evitam adivinhação:

• abra uma janela anônima e teste o site ao vivo
• faça um hard refresh (Ctrl/Cmd + Shift + R)
• no DevTools, desative o cache e recarregue
• procure por respostas 304/404 para arquivos JS e CSS
• se houver service worker, desregistre-o e recarregue

Se o site ao vivo continua servindo o build errado, a FixMyMess pode apontar se é cache, service worker ou um problema na saída do deploy antes que você perca horas perseguindo “bugs fantasmas”.

Passo a passo: diagnostique a falha em 20 minutos

Comece nomeando o sintoma exato no site ao vivo. É uma página em branco (carregamento), uma página que carrega mas dados nunca aparecem (chamada API), ou um login que funciona no preview mas falha no vivo (auth/cookies)? Se você identificar o sintoma errado, pode perder uma hora perseguindo o problema errado.

Abra o site ao vivo numa janela privada, então abra o DevTools. Mantenha duas abas abertas: Console e Network. O Console mostra as falhas mais ruidosas (erros em vermelho). O Network mostra a primeira requisição que realmente quebra.

1) Encontre a primeira falha real

No Console, procure erros mencionando requisições bloqueadas, CORS, conteúdo misto, loops de redirect ou variáveis de ambiente faltando. Ignore warnings até explicar o primeiro erro em vermelho.

Depois vá ao Network, recarregue e clique na primeira requisição que falha (frequentemente o primeiro XHR/fetch). Anote a URL da requisição, código de status e mensagem de resposta:

• 401/403 geralmente aponta para auth, cookies ou mismatch de key/issuer.
• 404 muitas vezes significa URL errada, rota ausente ou caminho de ativo quebrado.
• 500 aponta para lógica do servidor ou configuração errada.
• Requisições que nunca terminam podem ser DNS, HTTPS ou uma requisição bloqueada pelo navegador.

2) Compare preview vs vivo lado a lado

Abra preview e vivo lado a lado e repita a mesma ação (carregar página, clicar em login, buscar dados). Compare os detalhes da requisição que falha:

• diferenças de URL (domínio, path, http vs https)
• headers (faltando Authorization, Origin incorreto)
• cookies (não definidos, não enviados, domínio errado)
• corpo da resposta (mensagem de erro diferente entre preview e produção)

Se o preview chama api.preview-host.com mas o vivo chama localhost, isso costuma ser mismatch de variável de ambiente, não um bug aleatório de produção.

Por fim, verifique as variáveis de ambiente em seu provedor de hospedagem (não apenas no repositório) e faça um redeploy limpo. Muitos apps gerados por IA mantêm valores antigos até que você rebuild e reimplante.

Se ficar travado após essas checagens, a FixMyMess pode rodar uma auditoria gratuita no código e apontar se o problema é env vars, domínio/CORS, HTTPS ou auth, depois reparar com verificação humana.

Erros comuns que mais fazem perder tempo

Quando alguém diz “preview funciona mas o vivo falha”, a causa raramente é um bug profundo. Frequentemente é uma discrepância simples entre ambientes que fica esquecida.

Os repetidores mais comuns

A maior parte do tempo se perde perseguindo sintomas (tela em branco, login falho, 401s) enquanto a raiz é uma configuração básica:

• URLs de redirect de auth não atualizadas para o domínio real. O provedor ainda permite só o hostname do preview, então logins em produção rebatem ou entram em loop.
• URLs de preview hardcoded no frontend. Um https://preview-xyz... esquecido em chamadas API, callbacks OAuth ou websockets pode quebrar o vivo.
• Segredos enviados ao navegador. Apps gerados por IA às vezes colocam chaves privadas em variáveis client-side ou bundle. Isso pode quebrar em produção e é um problema de segurança.
• Preview e produção apontando para bancos diferentes. O preview pode usar dados de teste enquanto a produção está vazia ou com esquema diferente.
• Correção aplicada mas não realmente deployada. Cache de build, targets de deploy errados ou variáveis de env não atualizadas dão a impressão de que o conserto não funcionou.

Um exemplo realista: você corrige o mismatch do callback OAuth, mas o site ao vivo ainda falha porque o frontend continua chamando a base URL da API do preview. Dois erros pequenos, um resultado confuso.

Como evitar perder tempo

Antes de reescrever código, faça estas checagens:

1. Confirme que o domínio de produção está listado em todos os provedores de auth que exigem isso.
2. Busque no código pelo hostname do preview e substitua por configuração segura para produção.
3. Verifique quais variáveis de ambiente são servidor-only vs expostas ao navegador.
4. Confirme que a conexão com o banco de produção e as migrações batem com o que o preview usou.
5. Redeploy e limpe caches/CDN relevantes para que o site ao vivo sirva o novo bundle.

Na FixMyMess, esses são os primeiros pontos que checamos numa auditoria de base de código porque aparecem muito em protótipos gerados por IA e são fáceis de perder.

Checklist rápido e próximos passos

Quando o preview funciona e o site ao vivo falha, trate como uma discrepância de configuração até provar o contrário. Normalmente você não está caçando um bug misterioso, está caçando uma diferença entre dois ambientes.

Comece pelo básico no domínio ao vivo:

• Confirme que o domínio ao vivo aponta para o deploy correto (projeto certo, branch certo, build mais recente).
• Compare variáveis de produção com os valores do preview (base URL da API, chaves de auth, URLs de callback, URL do banco).
• Abra o site ao vivo com o console aberto e procure por avisos de HTTPS, loops de redirect e erros de conteúdo misto.
• Teste auth de ponta a ponta no vivo (registro, login, logout, refresh). “Funciona até atualizar” costuma indicar problemas de cookie ou escopo de domínio.
• Reteste em janela privada e em mobile. Cookies antigos, ativos em cache e service workers podem ocultar o problema real.

Um exemplo simples: no preview seu app chama http://api.myapp.local (ok para dev), mas em produção a página é HTTPS e a API é HTTP. O navegador bloqueia. A UI parece ok até você clicar num botão; então tudo falha.

Se ainda não conseguir identificar, pare de adivinhar e faça uma auditoria focada. As correções mais rápidas vêm de revisar três áreas em conjunto: auth e cookies, segredos expostos e arquitetura geral (protótipos gerados por IA frequentemente embarcam lógica emaranhada que só quebra sob configurações reais de produção).

Se seu projeto foi gerado com ferramentas como Lovable, Bolt, v0, Cursor ou Replit e agora falha num domínio real, a FixMyMess (fixmymess.ai) foi feita exatamente para isso: diagnosticar diferenças entre preview e produção e então reparar a base de código para que aguente produção.