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, erro ou endereço antigo. E então começa o pânico: o hosting é culpado primeiro, depois o registrador, e por último, você mesmo.
Não é barulho que você precisa, mas uma verificação passo a passo. Muitas vezes, o problema está em um único registro, um único 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 mudado e em que minuto isso foi feito.
Verifique se o problema está realmente relacionado ao DNS
Primeiro, separe o efeito do DNS de tudo o mais. Se antes da mudança de DNS o site abria, e cinco minutos depois 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. Esses 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 quebrou ou o certificado expirou.
Há um teste simples: tente abrir o site pelo IP direto, se você souber, 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 responder de jeito nenhum, então isso já não é sobre DNS, mas sobre o servidor, o host virtual ou a própria plataforma.
Verifique também os fatores externos. Por exemplo, se o SSL ou os redirecionamentos do site foram alterados recentemente, 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.
Corresponder 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 frequentemente é 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 o servidor antigo, os usuários verão resultados diferentes dependendo de como digitam o endereço.
A verificação com o plano de migração ajuda bastante. Se você transferiu o site, o novo DNS deve apontar para o endereço onde o site já está ativo, e não para um ambiente de teste vazio. O erro aqui é frequentemente simples: o registro foi criado, mas o destino foi deixado antigo.
Se precisar verificar a conexão mais a fundo, compare os valores atuais com o que deve ser de acordo com a tarefa. Aqui, três coisas são importantes: nome do registro, tipo de registro e endereço de destino. Um símbolo a mais no CNAME ou um IP de uma rede estranha — e o site para de abrir apenas para parte das solicitações.
Verificar se a transição para o novo provedor de DNS não está quebrada
Quando o 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 correspondem ao que você configurou 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".
Mais uma armadilha comum é que a zona foi criada, mas não está ativa. O 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 à consulta NS de várias fontes. Se parte das respostas vai para o provedor antigo, a transição não está completa. E aqui não importa apenas uma captura de tela, mas sim 2-3 verificações independentes.
Levar em conta o atraso na atualização pelo mundo e para os 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 é zerado a seu pedido.
O atraso na atualização pelo mundo pode variar, então não tire conclusões com base em um único telefone ou em um único escritório. Verifique o site através da internet doméstica, da 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 estava nas configurações antigas, alguns resolvedores ainda se lembrarão delas. Então, 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 ainda mais, e depois ninguém entende qual registro é o mais recente. É melhor fixar uma mudança 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 verdadeiro sinal de parada. Navegadores e redes modernos preferem IPv6, e se ele estiver quebrado, o site pode parecer inacessível mesmo com IPv4 funcionando.
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 situação estranha: em uma internet o site abre, em outra — não.
Pode acontecer o contrário. O IPv6 já está ativo, mas o registro A aponta para um servidor antigo. Assim, alguns usuários acessam sem problemas, enquanto outros enfrentam timeout. Externamente, isso parece um caos, mas a causa geralmente é uma: os dois registros estão apontando para direções diferentes.
Se você tem acesso às configurações de DNS, compare ambos os endereços com o endereço do site ativo. Aqui não é necessário adivinhar. Precisamos de 2 números: IPv4 e IPv6. E ambos devem levar ao local onde o site realmente responde.
Certifique-se de que o site responde no 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á em funcionamento e se a vinculação ao domínio correto não foi perdida. Às vezes, o site está no lugar, 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 a vinculação exata, o servidor entregará o projeto errado ou um erro. Isso é especialmente perceptível após a migração para um novo local, quando a configuração aparentemente foi 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 principal, mas um caminho específico, como /login ou /admin. Assim, você pode 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 autoconfiança de "parece que está abrindo".
A propósito, se você precisar de uma pausa recreativa entre as verificações, pode dar uma olhada anecdotes sobre estudantes. Anecdotes grátis. Curtos — são 1–2 minutos, no máximo. Às vezes, essa pausa ajuda a não confundir o servidor antigo com o novo.
Verifique o HTTPS e o certificado após a mudança de registro
O DNS pode já estar apontando para o host correto, mas o navegador ainda reclama do 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 exatamente 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 funcionava anteriormente 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 o 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 o site quanto a fraudesÀs vezes, as pessoas confundem um erro de certificado com uma tentativa de falsificação, embora isso seja apenas uma incompatibilidade entre registros e domínio.
Prepare o que enviar para o suporte de hospedagem ou DNS.
Quando suas verificações estiverem concluídas, reúna um pacote curto para o suporte. Precisamos do domínio, novos NS, o horário exato da mudança, uma 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 foram alterados.
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 o caminho, menos voltas a resposta dará.
É 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 imagem diverge: na zona, no registrador ou no servidor. E quanto menos suposições, mais rápido encontram o ponto crítico.
Se você quiser aliviar um pouco a cabeça 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 no lugar. E então volte para os logs e registros NS.
O que mais verificar se o problema é intermitente
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 desordenados, 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 fazer um teste separado no navegador sem dados salvos. Não porque isso 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 mudou a estrutura do site, não se esqueça dos links antigos. O usuário pode acabar em uma página inexistente e concluir que o domínio está completamente quebrado. Na prática, apenas 1 caminho de 20 se quebra.
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 foi verificado e o acesso ainda oscila, 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 identificação de onde exatamente a cadeia se quebrou.
