DNS WordPress: problemi e configurazione corretta
Cos’è il DNS di un sito WordPress e perché causa problemi
Quando un sito WordPress “non si vede” pur essendo online, la causa non è quasi mai WordPress in sé: è il DNS, il sistema che traduce il nome del dominio (es. tuosito.it) nell’indirizzo IP del server che ospita il sito. I problemi DNS WordPress più frequenti riguardano proprio questo passaggio di traduzione: se il record che punta al server è sbagliato, obsoleto o non ancora propagato, il browser non sa a quale server chiedere le pagine, indipendentemente da quanto sia configurato bene WordPress su quel server.
La causa più comune: record A rimasto sul vecchio hosting
Il caso più frequente in assoluto è un migrazione di hosting o dominio durante la quale il record A (quello che punta a un indirizzo IPv4) non viene aggiornato, o viene aggiornato ma il DNS continua a restituire temporaneamente il valore precedente. Il sito esiste ed è configurato correttamente sul nuovo server, ma chi lo visita continua a raggiungere il vecchio hosting (dove magari il sito è già stato disattivato, con conseguente errore o pagina vuota).
Seconda causa frequente: nameserver non aggiornati
Un’altra causa ricorrente riguarda i nameserver del dominio: se il dominio è stato registrato con un provider e l’hosting è un altro, e i nameserver non sono stati puntati correttamente verso chi gestisce le zone DNS (es. Cloudflare o il pannello dell’hosting), qualsiasi record A o CNAME configurato “nel posto sbagliato” non avrà mai effetto, perché il dominio continua a leggere una configurazione DNS diversa da quella che si sta modificando.
Causa meno comune: proxy Cloudflare mal configurato
Un caso più raro ma comune per chi usa Cloudflare è la nuvoletta proxy attiva su un record che invece dovrebbe restare in modalità DNS-only (es. un sottodominio usato per un pannello di gestione o un servizio email) — in questi casi la diagnosi richiede di controllare record per record quali hanno il proxy attivo e se è coerente con il servizio a cui puntano.
Come capire la causa: verificare cosa restituisce davvero il DNS
Prima di modificare qualsiasi record, va verificato cosa il DNS sta effettivamente restituendo in questo momento, distinguendo due livelli distinti del problema: il dominio risolve un indirizzo IP (raggiungibilità DNS) e quell’indirizzo risponde con il sito corretto (risposta del server). Sono due stadi diversi: un dominio può risolvere perfettamente e puntare comunque al server sbagliato, oppure può non risolvere affatto.
Step 1: verificare l’indirizzo IP a cui punta il dominio
Da terminale, dig tuosito.it +short (o nslookup tuosito.it su Windows) restituisce l’indirizzo IP a cui il dominio risolve in questo momento. Il test è a esito binario: se l’IP restituito corrisponde a quello del nuovo hosting (verificabile nel pannello dell’hosting stesso), il DNS è già aggiornato e il problema è altrove; se corrisponde ancora al vecchio hosting, la causa è confermata ed è il record A da correggere.
Step 2: distinguere “non risolve” da “risolve ma il sito non carica”
Se dig non restituisce alcun IP, o il browser mostra un errore tipo DNS_PROBE_FINISHED_NXDOMAIN, il problema è a monte: il dominio non risolve affatto, spesso per nameserver sbagliati o un dominio scaduto. Se invece un IP viene restituito ma il sito mostra un errore del server (es. pagina di default dell’hosting, errore 521 se dietro Cloudflare, o certificato SSL non valido perché il dominio punta a un server che non ha ancora quel certificato), il DNS ha già fatto il suo lavoro correttamente: il problema è la configurazione del server a quell’indirizzo, non più il DNS.
| Sintomo osservato | Causa probabile |
|---|---|
dig non restituisce nessun IP / DNS_PROBE_FINISHED_NXDOMAIN | Nameserver del dominio non puntano a chi gestisce le zone DNS, o dominio scaduto |
dig restituisce l’IP del vecchio hosting | Record A non aggiornato dopo la migrazione, oppure propagazione ancora in corso |
dig restituisce l’IP corretto ma il sito mostra la pagina di default dell’hosting | Il dominio risolve, ma sul server non è ancora configurato il virtual host per quel dominio |
| Errore 521/522 con Cloudflare attivo | Proxy Cloudflare (nuvoletta arancione) attivo ma il server di origine non risponde su quella porta |
| Sito raggiungibile ma email non arrivano | Record MX puntato al provider sbagliato o mancante, indipendente dal record A del sito |
www.tuosito.it funziona ma tuosito.it no (o viceversa) | Manca il record CNAME/A per una delle due varianti del dominio (root vs www) |
Vale anche la pena controllare se il dominio usa un multisite WordPress con sottodomini, o è gestito tramite un pannello DNS esterno a quello dell’hosting (es. Cloudflare davanti a un hosting diverso): sono le due varianti di configurazione più spesso trascurate quando si segue una guida generica.
Risolvere il problema DNS: correggere il record A e verificare la propagazione
Il percorso più semplice per il caso più comune — record A puntato al vecchio hosting — è correggere quel singolo record e poi verificare che la propagazione sia completata, senza modificare altri record che nel frattempo funzionano correttamente.
Step 1: individuare il nuovo indirizzo IP corretto
L’indirizzo IP del nuovo hosting è indicato nel pannello dell’hosting stesso (cPanel, Plesk o area clienti), solitamente nella sezione dedicata alle informazioni sull’account o alla configurazione del dominio.
Step 2: aggiornare il record A nella zona DNS corretta
Il record va modificato nel pannello DNS che gestisce effettivamente la zona del dominio — non necessariamente quello dell’hosting: se il dominio usa Cloudflare come DNS, il record va cambiato lì, anche se l’hosting è un altro. Aggiornare il record nel posto sbagliato è la ragione più comune per cui una correzione “sembra non funzionare”.
Step 3: verificare la propagazione con un TTL basso
Dopo la modifica, abbassare temporaneamente il TTL (Time To Live, la durata di cache del record) a un valore basso come 300 secondi riduce il tempo di attesa per le visite successive. La propagazione completa su tutta la rete può comunque richiedere da pochi minuti fino a 24-48 ore nei casi peggiori, a seconda dei resolver DNS intermedi che mantengono in cache il valore precedente.
Verifica finale osservabile
Ripetere dig tuosito.it +short da una rete diversa da quella abituale (es. dati mobili invece di WiFi di casa) è il modo più affidabile per confermare che la propagazione sia completata: se l’IP restituito è quello nuovo anche da una rete diversa, il problema DNS è risolto e qualsiasi errore residuo riguarda la configurazione del server, non più il dominio.
Caso particolare: DNS gestito da Cloudflare davanti all’hosting
Quando il DNS è gestito da Cloudflare mentre WordPress è ospitato altrove, la diagnosi ha un passaggio in più: bisogna verificare separatamente se il problema è nel record DNS (punto verificabile disattivando temporaneamente il proxy, l’icona nuvoletta, per vedere l’IP reale del record) o nella comunicazione tra Cloudflare e il server di origine (tipico degli errori 521/522/523). Questa distinzione evita di modificare record DNS che sono già corretti quando il problema reale è, per esempio, un firewall del server che blocca gli IP di Cloudflare.
Non riesci a sistemare il DNS del tuo sito? Intervento tecnico a distanza
La configurazione DNS coinvolge spesso più pannelli diversi (registrar del dominio, provider DNS come Cloudflare, hosting) ed è facile modificare il record giusto nel posto sbagliato, o non accorgersi che nameserver e zona DNS non coincidono. Se dopo aver verificato record A, propagazione e nameserver il sito continua a non essere raggiungibile correttamente, oppure preferisci non rischiare di toccare configurazioni che riguardano anche le email del dominio, è possibile richiedere una verifica diretta: invia l’accesso al pannello DNS (o le credenziali del registrar) e viene fatta una diagnosi mirata su tutta la catena — dominio, DNS e server — per individuare esattamente dove si interrompe la risoluzione.
Domande frequenti sui problemi DNS WordPress
Quanto tempo ci vuole perché un cambio DNS si propaghi del tutto? Dipende dal TTL impostato sul record prima della modifica: con un TTL basso (300-600 secondi) la maggior parte dei resolver aggiorna il valore entro un’ora, ma alcuni provider e reti aziendali possono impiegare fino a 24-48 ore per allineare completamente la cache.
Perché il sito funziona da un dispositivo e non da un altro? Perché ogni rete usa un resolver DNS diverso (il provider internet di casa, quello mobile, una VPN aziendale), e ciascuno aggiorna la propria cache in momenti diversi durante la propagazione: è normale vedere risultati diversi per qualche ora dopo una modifica.
Devo cambiare i nameserver o solo il record A? Solo il record A se il dominio resta gestito dallo stesso provider DNS di prima e cambia solo il server che ospita il sito. I nameserver vanno cambiati solo se si vuole spostare la gestione dell’intera zona DNS a un provider diverso (es. passare a Cloudflare).
Se sistemo il DNS del sito, rischio di rompere le email del dominio? Sì se non stai attento: il record MX che gestisce la posta è indipendente dal record A del sito, ma è nella stessa zona DNS, e una modifica fatta senza controllare gli altri record esistenti può cancellarli per errore. Prima di modificare, va sempre controllato l’elenco completo dei record già presenti.
Cosa significa l’errore 521 con Cloudflare? Indica che Cloudflare risolve correttamente il dominio ma non riesce a contattare il server di origine su quella porta: il DNS ha funzionato, il problema è la comunicazione tra Cloudflare e il server (firewall, servizio web non attivo, porta bloccata).
Vuoi risolverlo con un intervento diretto? Se preferisci non intervenire da solo su registrar, DNS e hosting insieme, → Richiedi assistenza specializzata: invia gli accessi necessari e viene verificata l’intera catena DNS fino alla causa reale, con la correzione del record giusto senza toccare configurazioni che già funzionano.