Cosa fare se il sito non si apre più dopo il cambio del DNS
Cosa fare se il sito non si apre più dopo il cambio del DNS
Il cambio di DNS è una questione insidiosa. Il sito sembra già essere stato trasferito, ma nel browser c'è vuoto, errore o indirizzo vecchio. E poi inizia il panico: prima si incolpa l'hosting, poi il registrar, poi se stessi.
Non serve rumore, ma una verifica passo dopo passo. Spesso il problema risiede in una singola registrazione, in un singolo NS o nella cache del provider, e non nel sito stesso. Se hai bisogno di capire cosa fare se il sito ha smesso di aprirsi dopo il cambio DNS, inizia dal fatto: cosa hai cambiato esattamente e in quale minuto lo hai fatto.
Verificare se il problema è effettivamente legato al DNS
Prima separa l'effetto DNS da tutto il resto. Se prima del cambio DNS il sito si apriva e dopo 5 minuti ha smesso, questo non è ancora una prova. La coincidenza temporale è ingannevole.
Guarda come si comporta il sito con diversi sintomi: non si apre affatto, va su un altro dominio, restituisce un errore SSL o semplicemente continua a caricare. Questi sono già 4 scenari diversi, e ognuno ha la sua origine. A volte il problema sembra essere DNS, ma in realtà il reindirizzamento su https è rotto o il certificato è scaduto.
C'è un test semplice: prova ad aprire il sito tramite l'IP diretto, se lo conosci, o attraverso un altro canale di comunicazione dove è già stato salvato il vecchio indirizzo. Se il server risponde all'IP, ma non al dominio, il DNS è davvero nella lista dei sospetti. Se non risponde a nulla, allora non si tratta di DNS, ma del server, dell'host virtuale o della piattaforma stessa.
Controlla anche i fattori esterni. Ad esempio, se sul sito è stato recentemente modificato l'SSL o i reindirizzamenti, il browser potrebbe mostrare un errore completamente diverso da quello che ti aspetti. È utile non basarsi su supposizioni, ma su un messaggio preciso. A volte un testo di errore può far risparmiare 30 minuti di ricerche inutili.
Associare il nuovo DNS a ciò che deve aprirsi
Dopo aver cambiato il DNS, apri l'elenco delle registrazioni e confrontalo con ciò che deve realmente essere aperto. Per la radice del dominio si controlla di solito il record A, per IPv6 - AAAA, per il sottodominio spesso è necessario il CNAME. Un errore in una lettera trasforma un sito normale in un vicolo cieco.
È necessario guardare non solo al dominio principale, ma anche al sottodominio. Ad esempio, www può puntare a un host, mentre senza www può puntare a un altro. E se uno dei punti indica un vecchio server, gli utenti vedranno risultati diversi a seconda di come inseriscono l'indirizzo.
Aiuta bene a confrontare con il piano di migrazione. Se hai trasferito il sito, il nuovo DNS deve puntare all'indirizzo dove il sito è già attivo, e non a un vuoto ambiente di test. L'errore qui è spesso semplice: la registrazione è stata creata, ma l'obiettivo è rimasto vecchio.
Se è necessario controllare il collegamento più a fondo, confronta i valori attuali con ciò che dovrebbe essere secondo il compito. Qui ci sono 3 cose importanti: il nome della registrazione, il tipo di registrazione e l'indirizzo di destinazione. Un simbolo in più in CNAME o un IP da una rete esterna — e il sito smette di aprirsi solo per alcune richieste.
Controlla se la transizione a un nuovo provider DNS è rotta
Quando un dominio viene trasferito a un nuovo provider DNS, è necessario assicurarsi che la delega sia avvenuta completamente. Il dominio deve avere i corretti NS e la zona deve essere realmente gestita dal nuovo server. Altrimenti, nel pannello tutto è bello, ma su Internet continua a vivere la vecchia configurazione.
Controlla se i NS del registrar corrispondono a quelli che hai impostato con il nuovo provider. Se è rimasto un vecchio indirizzo, il dominio potrebbe comportarsi in modo imprevedibile. Questo è particolarmente evidente quando la registrazione è stata modificata di notte, e al mattino il sito già "si apre e si chiude".
Un'altra trappola comune è che la zona è stata creata, ma non è attiva. Un nuovo provider DNS può accettare il dominio nel pannello, ma non gestire i record. In tal caso, vedi le impostazioni, ma il mondo esterno non le vede. Scomodo, vero.
Un buon modo per verificare è guardare la risposta a una richiesta NS da diverse fonti. Se parte delle risposte proviene dal vecchio fornitore, la transizione non è completata. E qui non conta solo uno screenshot, ma 2-3 verifiche indipendenti.
Tenere conto del ritardo dell'aggiornamento nel mondo e per gli utenti
Dopo il cambio del DNS, alcune persone vedranno il nuovo indirizzo, mentre altre vedranno il vecchio. È normale. Il provider, il router e il dispositivo hanno una cache, e non si azzera a tuo piacimento.
Il ritardo nell'aggiornamento globale può variare, quindi non trarre conclusioni da un solo telefono o da un solo ufficio. Controlla il sito tramite internet domestico, rete mobile e almeno uno strumento esterno. Quando diversi punti mostrano risultati diversi, è quasi sempre un segno della cache, e non un guasto del sito.
Se il dominio è stato recentemente configurato con le vecchie impostazioni, alcuni resolver potrebbero ancora ricordarle. Così, un utente vede il nuovo server, un altro vede il vecchio, e un terzo riceve un errore a causa della discrepanza nei record. Questo comportamento è particolarmente evidente quando si cambia il record A su un altro host.
Qui aiuta una semplice disciplina: non cambiare il DNS avanti e indietro 5 volte di seguito. Ogni nuova modifica disturba ulteriormente la situazione, e poi nessuno capisce più quale registrazione sia l'ultima. È meglio fissare una modifica e aspettare, piuttosto che oscillare tra tre opzioni.
Controlla il conflitto tra IPv4 e IPv6
A volte il record A è già corretto, mentre AAAA punta nel nulla. Per alcuni dispositivi non è un dettaglio, ma un vero e proprio segnale di stop. I browser moderni e le reti amano l'IPv6, e se è rotto, il sito può sembrare non disponibile anche con un IPv4 funzionante.
Controlla entrambi i record separatamente. Se il dominio deve funzionare solo su IPv4, è meglio non lasciare accidentalmente AAAA. Un indirizzo IPv6 vuoto o obsoleto crea spesso un quadro strano: da una rete il sito si apre, da un'altra no.
A volte è il contrario. L'IPv6 è già attivo, ma il record A punta a un vecchio server. Allora alcuni utenti accedono senza problemi, mentre altri ricevono un timeout. Esternamente sembra caos, ma la causa è di solito una: due record guardano in direzioni diverse.
Se hai accesso alle impostazioni DNS, confronta entrambi gli indirizzi con l'indirizzo della piattaforma di lavoro. Qui non c'è bisogno di indovinare. Servono 2 numeri: IPv4 e IPv6. E entrambi devono portare dove il sito risponde realmente.
Assicurati che il sito risponda all'indirizzo di destinazione
Anche il DNS perfetto non salverà se il server dall'altra parte tace. Dopo aver cambiato il record, è necessario controllare se l'host è attivo, se il server web è attivo e se il collegamento al dominio corretto non è andato perso. A volte il sito è fermo, ma l'host virtuale è configurato con un vecchio nome.
Se ci sono più siti sul server, il corretto virtual host risolve tutto. Lo stesso IP può gestire 10 domini, e senza un'associazione precisa il server restituirà il progetto sbagliato o un errore. Questo è particolarmente evidente dopo il trasferimento su una nuova piattaforma, quando la configurazione sembra essere stata copiata, ma il nome del dominio è stato dimenticato.
Controlla anche la risposta del server: 200, 301, 302, 404 o 500. Questi codici dicono di più di qualsiasi chat di supporto. Se l'indirizzo di destinazione restituisce 404, significa che il DNS è già arrivato, ma il sito sull'host non corrisponde alle aspettative.
A volte è utile aprire non la homepage, ma un percorso specifico, ad esempio /login o /admin. In questo modo si può vedere se il sito funziona completamente o solo la pagina iniziale. Quando si tratta di migrazione, un controllo minore è meglio di un grande e sicuro 'sembra aprirsi'.
A proposito, se hai bisogno di una pausa divertente tra i controlli, puoi dare un'occhiata barzellette sugli studenti. Barzellette gratis. Brevi — sono 1–2 minuti, non di più. A volte una pausa del genere aiuta a non confondere il vecchio server con il nuovo.
Verifica HTTPS e certificato dopo la modifica della registrazione
Il DNS potrebbe già puntare all'host corretto, ma il browser continua a lamentarsi per HTTPS. Allora il problema è nel certificato, HSTS o reindirizzamento. Una storia molto comune dopo il trasferimento a un nuovo IP.
Controlla se il certificato è stato emesso per questo dominio e sottodominio. Se il nuovo indirizzo punta a un server dove il certificato è stato emesso a un altro nome, il browser non permetterà all'utente di procedere. E qui né la cache né il riavvio aiuteranno.
HSTS aggiunge rigidità. Se il sito funzionava in precedenza tramite HTTPS e nel browser è impostata una regola, il tentativo di aprirlo con una configurazione obsoleta o errata porterà a un blocco immediato. Non è un bug del browser, ma la sua memoria, e dura più a lungo di quanto si vorrebbe.
Un'altra piccola cosa è il reindirizzamento da http a https. Se punta a un vecchio dominio, il nuovo DNS sembra corretto, ma il sito va comunque da un'altra parte. Controlla l'indirizzo finale dopo il reindirizzamento, non solo il punto di partenza.
Se dopo tutti i passaggi non è ancora chiaro se il sito si apre per gli altri, ha senso confrontare la questione con il materiale come controllare un sito per frodi. A volte le persone scambiano l'errore del certificato per un tentativo di sostituzione, anche se si tratta semplicemente di una discrepanza tra registrazioni e dominio.
Preparare cosa inviare al supporto per l'hosting o il DNS
Quando hai finito le tue verifiche, raccogli un breve pacchetto per il supporto. Servono dominio, nuovi NS, orario esatto del cambio, screenshot dell'errore e lista di ciò che è già stato verificato. Questi sono 5 punti, e risparmiano più tempo di una lunga email "non funziona nulla".
Non dimenticare di specificare da quale dispositivo e rete si vede il problema. Per il supporto, non è una formalità, ma un dettaglio utile: lo stesso dominio può aprirsi da una rete mobile e cadere da quella domestica. È anche utile allegare le attuali registrazioni A, AAAA e CNAME, se sono cambiate.
Se hai cambiato fornitore DNS, scrivi chi aveva il dominio prima e chi lo ha adesso. A volte l'aiuto si scontra con il fatto che la zona è già delegata, ma il vecchio server continua a rispondere in alcune parti dei resolver. Più precisamente descrivi il percorso, meno giri avrà la risposta.
È buona norma allegare subito il risultato della verifica da 2-3 fonti, e non solo uno screenshot dal browser. È più facile per il supporto vedere dove si discosta il quadro: nell'area, dal registratore o sul server. E meno congetture ci sono, più velocemente trovano il collo di bottiglia.
Se vuoi liberare un po' la mente dopo la routine tecnica, puoi distrarti con le esperienze più crudeli degli psicologi — il materiale non è semplice, ma aiuta a smontare la sensazione che un DNS rotto tenga il mondo fermo. E poi torna ai log e ai record NS.
Cosa controllare ancora se il problema è fluttuante
Se il sito si apre solo per alcuni utenti, non guardare a un solo fattore, ma a una combinazione di 3 cose: DNS, cache e server. Quando tutti e tre sono in disaccordo, i sintomi cambiano ogni ora. Questo è proprio il caso in cui lo stesso dominio si comporta in modo diverso al mattino e alla sera.
A volte è utile controllare tramite un servizio esterno di risoluzione e un test separato nel browser senza dati salvati. Non perché sia magia, ma perché si separa l'immagine locale da quella generale. Se localmente va male, ma all'esterno va bene, il problema è più vicino al dispositivo o al fornitore.
Se dopo il trasferimento hai anche cambiato la struttura del sito, non dimenticare i vecchi link. L'utente potrebbe finire su una pagina inesistente e decidere che il dominio è completamente rotto. Nella pratica, si rompe solo 1 percorso su 20.
E sì, a volte è utile guardare un problema come a una catena. Il DNS porta al server, il server restituisce il sito, il certificato conferma il dominio e il browser decide se far entrare l'utente o meno. Se uno dei 4 elementi manca, il sito non si apre come dovrebbe.
Quando tutto è stato verificato e l'accesso continua a oscillare, registra le ultime 2 modifiche e non apportare nuove fino alla risposta del supporto. Altrimenti, ostacoli te stesso nel vedere dove si è interrotta la catena.
