Como ver um site no novo servidor antes de alterar o DNS: todos os métodos comparados

Um servidor costuma hospedar muitos sites e escolhe um pelo nome de domínio que o navegador envia, então http://203.0.113.10/ mostra uma página padrão ou um aviso de certificado. Todos os métodos abaixo enviam a requisição ao novo IP dizendo “quero o example.com”. A diferença está em quem vê o resultado, em quais dispositivos e com que fidelidade.

O sistema operacional lê o arquivo hosts antes de consultar o DNS. Uma linha por nome de host aponta o seu domínio para o novo servidor, só neste computador:

# Windows: C:\Windows\System32\drivers\etc\hosts  (edit as Administrator)
# macOS / Linux: /etc/hosts  (edit with sudo)
203.0.113.10   example.com
203.0.113.10   www.example.com

# Then flush the DNS cache
ipconfig /flushdns                                              # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
resolvectl flush-caches                                         # Linux with systemd-resolved

• Prós: exato, gratuito e funciona para tudo: IPs privados, qualquer porta, o certificado e os cabeçalhos do próprio servidor novo. O gerador de arquivo hosts escreve as linhas para você.
• Contras: uma máquina por vez, exige permissão de administrador, pouco prático no iOS e no Android, e fácil de esquecer. Uma linha esquecida depois da migração deixa você no servidor errado.
• Ideal para: quem desenvolve e confere o próprio trabalho, e a verificação final de HTTPS, cabeçalhos de segurança e login de terceiros antes da troca.

--resolve diz ao curl qual IP usar para um nome de host, então a requisição leva o seu domínio real, inclusive no handshake TLS, e o certificado é verificado:

# Status line and headers from the new server, over HTTPS
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

# The page title, to make sure it is your site and not a default page
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i "<title>"

# No certificate yet? -k skips verification; plain HTTP works with a Host header
curl -skI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI -H "Host: example.com" http://203.0.113.10/

Use -H "Host: …" só em HTTP simples: em HTTPS o curl ainda enviaria o IP no handshake TLS e verificaria o certificado contra ele. No Windows, digite curl.exe, porque no Windows PowerShell 5.1 curl é um alias de Invoke-WebRequest.

• Prós: segundos, nada para desfazer, dá para automatizar, e mostra códigos de status, redirecionamentos e o certificado exatamente como o servidor envia.
• Contras: sem renderização: só HTML e cabeçalhos, e só para você.
• Ideal para: confirmar que o site está configurado no novo servidor antes de investir tempo em qualquer outra coisa, e checagens em scripts ou CI.

Muitas hospedagens dão a cada conta um endereço temporário no domínio delas, e servidores cPanel podem servir uma conta em http://203.0.113.10/~username/ quando a hospedagem ativou o mod_userdir. Você também pode criar um registro para um nome novo, como staging.example.com, apontando para o novo servidor: isso adiciona um nome de host sem mexer nos registros em produção.

• Prós: uma URL comum que funciona em qualquer dispositivo e pode ser enviada a qualquer pessoa, sem serviço extra.
• Contras: o site está respondendo por outro nome de host. O WordPress e a maioria dos CMSs redirecionam para o domínio salvo nas configurações, que ainda aponta para o servidor antigo, e links absolutos e cookies também seguem o domínio real. Corrigir isso exige um buscar e substituir que você precisa reverter antes do lançamento. Muitas hospedagens desativam URLs ~user, e o HTTPS vale para o nome temporário, não para o seu domínio.
• Ideal para: sites estáticos e apps com URLs relativas, ou a entrega da própria hospedagem quando não há outra opção.

O Chrome e outros navegadores baseados em Chromium aceitam uma opção de inicialização que mapeia nomes de host para um IP apenas naquela sessão do navegador. Uma pasta de perfil separada garante que uma nova instância comece com a regra:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir=%TEMP%\chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# macOS
open -na "Google Chrome" --args --user-data-dir=/tmp/chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# A resolver for your whole network (dnsmasq; also covers subdomains)
address=/example.com/203.0.113.10

A última linha é a mesma ideia um nível acima: um resolvedor local como o dnsmasq, ou um registro de DNS local no Pi-hole, responde com o novo IP para todo dispositivo que o usa, inclusive celulares nesse Wi-Fi, desde que usem o DNS da rede e não um DNS privado próprio. Extensões de navegador não conseguem editar o arquivo hosts; alguns serviços de prévia oferecem uma como atalho para os seus links (o hosts.click lista uma extensão para Chrome; o DNSPeek ainda não tem).

• Prós: nenhum arquivo do sistema editado, nada fica para trás ao fechar o navegador, e uma resposta exata com o domínio e o certificado reais.
• Contras: a opção do Chrome só existe no desktop e é fácil errar se o Chrome já estiver aberto com o mesmo perfil. Um resolvedor precisa de alguém para mantê-lo e só ajuda quem está na sua rede.
• Ideal para: quem desenvolve e quer comportamento exato sem mexer no arquivo hosts, e equipes que testam em dispositivos reais no mesmo escritório.

Um serviço de prévia dá a você um link HTTPS no domínio dele. O serviço se conecta ao IP informado, pede o seu domínio real e reescreve links, redirecionamentos e cookies para que os visitantes fiquem dentro da prévia. É o único método aqui que um cliente consegue usar sem ajuda.

O que os próprios serviços informam, em outubro de 2026 (detalhes em DNSPeek vs SkipDNS, DNSPeek vs Peek-DNS e DNSPeek vs hosts.click):

• Prós: celulares, tablets e clientes abrem como qualquer link, não há nada para instalar ou desfazer, e uma senha ou data de expiração mantém tudo sob controle.
• Contras: há um proxy no meio. O DNSPeek, por exemplo, remove Strict-Transport-Security, Content-Security-Policy e X-Frame-Options e ajusta os atributos dos cookies para que a prévia funcione no próprio endereço; login com Google e páginas de pagamento hospedadas voltam para o seu domínio real; firewalls no novo servidor podem desafiar o tráfego do proxy; e só IPs públicos podem ser alcançados. Veja o que as prévias não fazem.
• Ideal para: revisão por clientes e stakeholders, checagens no celular e qualquer pessoa a quem não se deve pedir para editar arquivos do sistema.

• Dev solo, no próprio notebook: curl --resolve, depois o arquivo hosts ou a opção do Chrome. Aqui eles são simplesmente a melhor escolha: exatos, gratuitos, sem terceiros no caminho. Use um link de prévia só para o celular.
• Agência com aprovação do cliente: um link de prévia protegido por senha. O cliente nunca mexe em arquivos do sistema; você mantém o arquivo hosts para conferir HTTPS, cabeçalhos e login, que um proxy altera. Veja aprovação do cliente antes do lançamento e DNSPeek para agências.
• Hospedagem migrando clientes: URLs temporárias quebram a maioria dos CMSs, então envie links de prévia, criados pela API ou por um link pré-preenchido /new?domain=…&ip=…. Se você precisa de um botão dentro do cPanel hoje, SkipDNS e hosts.click listam plugins de painel; o DNSPeek ainda não tem. Veja DNSPeek para provedores de hospedagem.

A maioria das migrações combina uma checagem exata para você com um link para todos os outros. Mais sobre essa dupla: arquivo hosts ou link de prévia; o resto da mudança: o checklist de migração de sites.

1. 1

   Etapa 1: Pegue o IP do novo servidor

   Use o e-mail de boas-vindas ou o painel de controle da nova hospedagem, não uma consulta ao seu domínio. Veja Encontre o IP do seu servidor.

2. 2

   Etapa 2: Confirme que o servidor responde pelo seu domínio

   Rode curl -sI --resolve example.com:443:203.0.113.10 https://example.com/. Um 200 ou um redirecionamento para o seu próprio domínio indica que o site está configurado; uma página padrão indica que ainda não está.

3. 3

   Etapa 3: Veja você mesmo no navegador

   Adicione entradas no hosts com o gerador de arquivo hosts ou inicie o Chrome com --host-resolver-rules, depois navegue pelas páginas principais, formulários e área administrativa.

4. 4

   Etapa 4: Compartilhe um link de prévia com quem aprova

   Informe o domínio e o IP no formulário de nova prévia, defina uma senha se o site for sensível e envie o link ao cliente ou à equipe.

5. 5

   Etapa 5: Desfaça seus ajustes depois da troca

   Remova as linhas do hosts ou feche o perfil do Chrome e confirme que o DNS público mudou com o verificador de propagação de DNS.