O que fazer se o site deixou de abrir após a mudança de DNS
O que fazer se o site deixou de abrir após a mudança de DNS
A mudança de DNS é traiçoeira. O site parece já ter sido transferido, mas no navegador está vazio, com erro ou o endereço antigo. E então começa a panique: primeiro culpam a hospedagem, depois o registrador, e por último a si mesmos.
Não é barulho que precisamos, mas uma verificação passo a passo. Muitas vezes, o problema está em uma única entrada, um NS ou no cache do provedor, e não no próprio site. Se você precisa entender o que fazer se o site parou de abrir após a mudança de DNS, comece pelo fato: o que exatamente foi alterado e em que minuto isso foi feito.
Verificar se o problema está realmente relacionado ao DNS
Primeiro, separe o efeito DNS de tudo o mais. Se antes da mudança de DNS o site abria e, após 5 minutos, parou, isso ainda não é uma prova. A coincidência de tempo é enganosa.
Veja como o site se comporta com diferentes sintomas: não abre de jeito nenhum, redireciona para outro domínio, apresenta erro SSL ou simplesmente fica carregando. Já são 4 cenários diferentes, e cada um tem sua própria origem. Às vezes, o problema parece ser DNS, mas na verdade o redirecionamento para https está quebrado ou o certificado expirou.
Há um teste simples: tente abrir o site pelo IP direto, se você o conhece, ou através de outro canal de comunicação onde o antigo endereço já está salvo. Se o servidor responde pelo IP, mas não pelo domínio, o DNS realmente está na lista de suspeitos. Se não responde por nada, então isso já não é sobre DNS, mas sobre o servidor, host virtual ou a própria plataforma.
Verifique também fatores externos. Por exemplo, se o site recentemente alterou o SSL ou redirecionamentos, o navegador pode mostrar um erro completamente diferente do que você espera. Aqui é útil olhar não para suposições, mas para a mensagem exata. Um texto de erro às vezes economiza 30 minutos de buscas desnecessárias.
Associar o novo DNS com o que deve ser aberto
Após a mudança de DNS, abra a lista de registros e compare-a com o que realmente precisa ser aberto. Para a raiz do domínio, geralmente verifica-se o registro A, para IPv6 - AAAA, para subdomínio muitas vezes é necessário CNAME. Um erro em uma letra transforma um site normal em um beco sem saída.
É preciso olhar não apenas para o próprio domínio, mas também para o subdomínio. Por exemplo, www pode apontar para um host, enquanto sem www — para outro. E se um dos pontos aponta para um servidor antigo, os usuários verão resultados diferentes dependendo de como digitam o endereço.
Ajuda bastante a verificação com o plano de migração. Se você transferiu o site, o novo DNS deve apontar para o endereço onde o site já está ativo, e não para uma plataforma de teste vazia. O erro aqui é frequentemente simples: a entrada foi criada, mas o destino foi deixado antigo.
Se precisar verificar a conexão mais a fundo, compare os valores atuais com o que deveria ser de acordo com a tarefa. Aqui, três coisas são importantes: o nome do registro, o tipo de registro e o endereço de destino. Um símbolo a mais no CNAME ou um IP de outra rede — e o site para de abrir apenas para parte das solicitações.
Verificar se a transição para o novo provedor de DNS está quebrada
Quando um domínio é transferido para um novo provedor de DNS, é necessário garantir que a delegação foi concluída completamente. O domínio deve ter os NS corretos, e a zona deve ser realmente gerenciada pelo novo servidor. Caso contrário, no painel tudo parece bonito, mas na internet ainda vive a configuração antiga.
Verifique se os NS do registrador coincidem com o que você escreveu no novo provedor. Se ainda houver um endereço antigo, o domínio pode se comportar de maneira imprevisível. Isso é especialmente notável quando o registro foi alterado à noite, e pela manhã o site já 'abre e fecha'.
Outra armadilha comum é que a zona foi criada, mas não está ativa. Um novo provedor de DNS pode aceitar o domínio no painel, mas não atender os registros. Nesse caso, você vê as configurações, mas o mundo externo não as vê. Desagradável, não é?
Uma boa maneira de verificar é olhar a resposta à solicitação NS de várias fontes. Se parte das respostas vai para o antigo provedor, a transição não está completa. E aqui não importa apenas uma captura de tela, mas 2-3 verificações independentes.
Levar em conta o atraso na atualização pelo mundo e pelos usuários
Após a mudança de DNS, algumas pessoas verão o novo endereço, enquanto outras verão o antigo. Isso é normal. O provedor, o roteador e o dispositivo têm cache, e ele não é limpo a seu pedido.
O atraso na atualização do mundo pode variar, portanto, não tire conclusões com base em um único telefone ou escritório. Verifique o site através da internet doméstica, rede móvel e pelo menos uma ferramenta externa. Quando diferentes pontos mostram resultados diferentes, isso quase sempre é um vestígio de cache, e não uma falha no site.
Se o domínio recentemente operou com as configurações antigas, alguns resolvedores ainda as lembrarão. Assim, um usuário vê o novo servidor, outro vê o antigo, e um terceiro recebe um erro devido à discrepância nos registros. Esse comportamento é especialmente notável ao mudar o registro A para outro host.
Aqui ajuda uma disciplina simples: não mude o DNS de um lado para o outro 5 vezes seguidas. Cada nova edição desestabiliza a situação mais, e depois ninguém entende qual registro é o mais recente. É melhor fixar uma alteração e esperar do que ficar pulando entre três opções.
Verificar conflito entre IPv4 e IPv6
Às vezes, o registro A já está correto, enquanto o AAAA aponta para lugar nenhum. Para alguns dispositivos, isso não é um detalhe, mas um sinal de parada completo. Navegadores e redes modernos adoram IPv6, e se ele estiver quebrado, o site pode parecer inacessível mesmo com um IPv4 funcional.
Verifique ambos os registros separadamente. Se o domínio deve funcionar apenas em IPv4, é melhor não deixar o AAAA acidentalmente. Um endereço IPv6 vazio ou antigo frequentemente cria uma imagem estranha: em uma internet o site abre, em outra — não.
Às vezes é o contrário. O IPv6 já está ativo, mas o registro A aponta para o servidor antigo. Então, alguns usuários acessam sem problemas, enquanto outros enfrentam timeout. Externamente, isso parece um caos, mas a razão geralmente é uma: dois registros apontam em direções diferentes.
Se você tiver acesso às configurações de DNS, compare ambos os endereços com o endereço do local de trabalho. Aqui não é necessário adivinhar. São necessários 2 números: IPv4 e IPv6. E ambos devem levar para onde o site realmente responde.
Certifique-se de que o site responde ao endereço de destino
Mesmo o DNS perfeito não ajudará se o servidor do outro lado estiver em silêncio. Após a alteração do registro, é necessário verificar se o host está ativo, se o servidor web está funcionando e se a vinculação ao domínio correto não foi perdida. Às vezes, o site está parado, mas o host virtual está configurado para um nome antigo.
Se houver vários sites no servidor, o host virtual correto resolve tudo. O mesmo IP pode atender a 10 domínios, e sem uma vinculação precisa, o servidor entregará o projeto errado ou um erro. Isso é especialmente perceptível após a migração para uma nova plataforma, quando a configuração parece ter sido copiada, mas o nome do domínio foi esquecido.
Verifique também a resposta do servidor: 200, 301, 302, 404 ou 500. Esses códigos dizem mais do que qualquer chat de suporte. Se o endereço de destino retornar 404, significa que o DNS já chegou, mas o site no host não corresponde às expectativas.
Às vezes, é útil abrir não a página inicial, mas um caminho específico, como /login ou /admin. Assim, é possível ver se o site está funcionando como um todo ou apenas a página inicial. Quando se trata de migração, uma verificação pequena é melhor do que uma grande confiança de que "parece que está abrindo".
A propósito, se precisar de uma pausa divertida entre as verificações, pode dar uma olhada em piadas sobre estudantes. Piadas grátis. Curtas — isso leva de 1 a 2 minutos, no máximo. Às vezes, essa pausa ajuda a não confundir o servidor antigo com o novo.
Verificar HTTPS e certificado após a mudança de registro
O DNS pode já estar apontando para o host correto, mas o navegador ainda reclama sobre HTTPS. Então, o problema está no certificado, HSTS ou redirecionamento. Uma história muito comum após a migração para um novo IP.
Verifique se o certificado foi emitido para este domínio e subdomínio. Se o novo endereço levar a um servidor onde o certificado foi emitido para outro nome, o navegador não permitirá que o usuário prossiga. E aqui nem o cache nem a reinicialização ajudarão.
HSTS adiciona rigidez. Se o site já funcionava por HTTPS e há uma regra fixada no navegador, tentar abri-lo com uma configuração antiga ou incorreta resultará em bloqueio imediato. Isso não é um bug do navegador, mas sim sua memória, e ela persiste por mais tempo do que gostaríamos.
Mais um detalhe — redirecionamento de http para https. Se ele aponta para um domínio antigo, o novo DNS parece estar correto, mas o site ainda assim não vai para o lugar certo. Verifique o endereço final após o redirecionamento, e não apenas o ponto de partida.
Se após todas as etapas ainda não estiver claro se o site está acessível para outros, faz sentido verificar a questão com o material como verificar um site quanto a fraudes. Às vezes, as pessoas confundem um erro de certificado com uma tentativa de substituição, embora isso seja apenas uma incompatibilidade entre registros e domínio.
Preparar o que passar para o suporte de hospedagem ou DNS
Quando suas verificações estiverem concluídas, reúna um pacote curto para suporte. Precisamos do domínio, novos NS, tempo exato da mudança, captura de tela do erro e uma lista do que já foi verificado. São 5 pontos, e eles economizam mais tempo do que uma longa carta dizendo 'nada está funcionando'.
Não se esqueça de indicar de qual dispositivo e rede o problema é visível. Para o suporte, isso não é uma formalidade, mas um detalhe útil: o mesmo domínio pode abrir em uma rede móvel e falhar em casa. Também é útil anexar os registros A, AAAA e CNAME atuais, se eles mudaram.
Se você mudou de provedor de DNS, informe quem tinha o domínio antes e quem o tem agora. Às vezes, a ajuda esbarra no fato de que a zona já foi delegada, mas o servidor antigo ainda responde em parte dos resolvedores. Quanto mais preciso você descrever a rota, menos círculos haverá na resposta.
É uma boa prática anexar imediatamente o resultado da verificação de 2 a 3 fontes, e não apenas uma captura de tela do navegador. Para o suporte, é mais fácil ver onde a discrepância ocorre: na zona, no registrador ou no servidor. E quanto menos suposições, mais rápido encontram o ponto crítico.
Se você quiser desestressar um pouco após a rotina técnica, pode se distrair com as experiências mais cruéis dos psicólogos — o material não é simples, mas ele ajuda a dissipar a sensação de que um DNS quebrado mantém o mundo parado. E então você pode voltar aos logs e registros NS.
O que mais verificar se o problema persiste
Se o site abre apenas para parte dos usuários, não olhe para um único fator, mas para a combinação de 3 coisas: DNS, cache e servidor. Quando os três estão desajustados, os sintomas mudam a cada hora. Este é exatamente o caso em que o mesmo domínio se comporta de maneira diferente de manhã e à noite.
Às vezes, ajuda verificar através de um serviço externo de resolução e um teste separado no navegador sem dados salvos. Não porque seja mágica, mas porque você está separando a imagem local da geral. Se localmente está ruim, mas externamente está normal, o problema está mais próximo do dispositivo ou do provedor.
Se após a migração você também alterou a estrutura do site, não se esqueça dos links antigos. O usuário pode acessar uma página inexistente e concluir que o domínio está completamente quebrado. Na prática, apenas 1 caminho de 20 é realmente quebrado.
E sim, às vezes é útil olhar para o problema como uma cadeia. O DNS leva ao servidor, o servidor entrega o site, o certificado confirma o domínio, e o navegador decide se permite ou não o acesso do usuário. Se um dos 4 elementos falhar, o site já não abre como deveria.
Quando tudo estiver verificado e o acesso ainda assim oscilar, registre as últimas 2 alterações e não faça novas até receber uma resposta do suporte. Caso contrário, você mesmo estará dificultando a visualização de onde exatamente a cadeia foi interrompida.
