WordPress cURL error 6: Could not resolve host

Questa guida analizza WordPress cURL error 6 con controlli progressivi, verifiche incrociate e modifiche reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

Il messaggio Could not resolve host viene generato prima della connessione HTTP o HTTPS: cURL non dispone ancora di un indirizzo IP al quale collegarsi. Il problema riguarda quindi il nome richiesto, la configurazione DNS del server o il percorso usato per risolverlo.

Per interpretare correttamente WordPress cURL error 6 bisogna separare tre elementi: l’hostname salvato da WordPress, la risposta dei resolver configurati sul server e lo stato della zona DNS autoritativa. Un browser sul computer locale può funzionare mentre il server fallisce, perché usa resolver, cache e rete differenti.

Come riconoscere il problema

• Site Health, un plugin o un aggiornamento mostra cURL error 6.
• Il messaggio include Could not resolve host seguito da un hostname.
• La stessa URL funziona dal computer ma non dal server.
• dig, host o getent hosts non restituiscono un indirizzo valido.
• Il problema compare dopo una migrazione, una modifica DNS o il cambio di un endpoint esterno.

Non confondere questo errore con cURL error 7, che indica un tentativo di connessione fallito dopo la risoluzione, o con cURL error 28, che indica un timeout. Nel codice 6 il blocco avviene nella fase DNS.

Cause più frequenti

1. Hostname errato o incompleto

Il plugin, il tema o il codice personalizzato prova a contattare un dominio scritto male, privo del suffisso corretto oppure costruito con una variabile vuota. Questa ipotesi deve essere confermata interrogando esattamente il nome riportato nel messaggio e confrontando il risultato con i nameserver autoritativi. Non modificare record o resolver sulla base di un solo test eseguito dal browser.

2. Resolver DNS del server non funzionante

Il sistema non riceve una risposta valida dai resolver configurati oppure incontra timeout, SERVFAIL o problemi temporanei nel percorso DNS. Questa ipotesi deve essere confermata interrogando esattamente il nome riportato nel messaggio e confrontando il risultato con i nameserver autoritativi. Non modificare record o resolver sulla base di un solo test eseguito dal browser.

3. Record A, AAAA o CNAME assente

L’hostname remoto esiste come testo nella configurazione, ma la zona autoritativa non pubblica un indirizzo utilizzabile o contiene una catena CNAME non valida. Questa ipotesi deve essere confermata interrogando esattamente il nome riportato nel messaggio e confrontando il risultato con i nameserver autoritativi. Non modificare record o resolver sulla base di un solo test eseguito dal browser.

4. DNSSEC non coerente

Una firma scaduta, un record DS errato o una catena di validazione interrotta può far fallire la risoluzione soltanto dai resolver che verificano DNSSEC. Questa ipotesi deve essere confermata interrogando esattamente il nome riportato nel messaggio e confrontando il risultato con i nameserver autoritativi. Non modificare record o resolver sulla base di un solo test eseguito dal browser.

5. Proxy, firewall o rete in uscita

Un proxy configurato in WordPress, nel sistema o nel plugin può usare un hostname non risolvibile; anche policy di rete e container possono avere DNS differenti. Questa ipotesi deve essere confermata interrogando esattamente il nome riportato nel messaggio e confrontando il risultato con i nameserver autoritativi. Non modificare record o resolver sulla base di un solo test eseguito dal browser.

6. URL salvato dopo una migrazione

Endpoint, webhook, licenze e servizi esterni possono conservare il dominio del vecchio ambiente, un hostname interno o un valore non più pubblicato. Questa ipotesi deve essere confermata interrogando esattamente il nome riportato nel messaggio e confrontando il risultato con i nameserver autoritativi. Non modificare record o resolver sulla base di un solo test eseguito dal browser.

Diagnosi passo per passo

1. Copiare l’hostname esatto dal messaggio di errore. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.
2. Interrogare A, AAAA e CNAME dal server. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.
3. Confrontare resolver locali e pubblici. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.
4. Controllare delega, nameserver e DNSSEC. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.
5. Verificare URL e opzioni del plugin coinvolto. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.
6. Controllare proxy e configurazione di rete in uscita. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.
7. Riprodurre la chiamata con WP-CLI o curl. Esegui il controllo direttamente nell’ambiente che genera l’errore e salva output, data e ora. Confronta il risultato con un resolver pubblico e con i nameserver autoritativi, quindi passa al punto successivo soltanto se il dato raccolto non spiega ancora il problema.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra il messaggio completo, la data e l’ora con fuso, l’URL o il servizio coinvolto, l’ultima modifica nota e il risultato ottenuto con un secondo strumento. Conserva Ray ID, Message-ID, request ID, transaction ID e codici applicativi quando presenti: questi identificativi collegano la schermata ai log senza richiedere password, cookie, token, chiavi private o codici di autenticazione.

Applica una sola modifica alla volta. Dopo ogni intervento ripeti la stessa operazione con gli stessi dati di test e controlla i log dello stesso intervallo temporale. Cambiare contemporaneamente DNS, cache, PHP, plugin, firewall, database e proxy impedisce di capire quale variazione abbia prodotto il risultato e rende più difficile un rollback affidabile.

Controllo incrociato dei livelli

Un errore visibile nel browser o nel client può essere generato da livelli differenti. Per il web confronta browser, curl, CDN, web server, PHP e applicazione. Per WordPress confronta frontend, wp-admin, Site Health, strumenti sviluppatore, WP-CLI e log. Per MySQL separa client, autenticazione, server, transazione e singola query. Per la posta confronta client, Webmail, coda SMTP, Track Delivery, DNS e risposta del destinatario.

Verifica sempre quale sistema ha prodotto il codice. Header, hostname, percorso del log, stack trace e testo esteso aiutano a distinguere un errore dell’edge da uno dell’origine, un rifiuto del proprio server da uno remoto e un problema PHP da uno del database. Questa distinzione evita interventi sul componente sbagliato.

Backup e reversibilità

Prima di cambiare file, record DNS, database, plugin o regole di sicurezza crea una copia leggibile e annota il valore precedente. Per i database usa backup coerenti e verifica che possano essere ripristinati. Per DNS registra TTL e nameserver autoritativi. Per firewall e proxy conserva l’espressione originale della regola. Una modifica reversibile consente di interrompere il test senza aggiungere un secondo guasto.

Non usare permessi 777, non disattivare globalmente WAF o antispam e non ridurre stabilmente la sicurezza TLS per ottenere una pagina funzionante. Le eccezioni devono essere limitate al percorso, parametro, hostname o sorgente confermati dai log.

Come raccogliere prove utili

Esporta testo e dati originali quando possibile: header HTTP, file .eml, bounce completo, output DNS, righe di log, stack trace e codici di risposta sono più utili di uno screenshot ritagliato. Oscura credenziali e dati personali, ma lascia visibili data, server, status, identificativi e descrizione tecnica dell’errore.

Ripeti il controllo con un caso minimo. Per una API usa pochi campi; per WordPress prova una funzione core; per MySQL usa una query in sola lettura o un campione; per la posta invia un messaggio di testo senza allegati. Aggiungi poi complessità progressivamente fino a individuare il punto nel quale compare il problema.

Interpretare cache, code e ritardi

Non tutti i cambiamenti diventano visibili immediatamente. DNS, cache CDN, cache LiteSpeed, sessioni PHP, connessioni persistenti, code SMTP e cron possono continuare a mostrare lo stato precedente. Verifica il TTL o la durata della cache, usa un nuovo identificativo di richiesta e controlla se il sistema sta elaborando una copia già accodata.

Un retry riuscito non annulla automaticamente l’errore precedente nei log. Confronta sempre l’identificativo della nuova richiesta con quello vecchio e verifica che il risultato sia relativo alla stessa URL, casella, query o operazione.

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Considera cache, TTL DNS, code SMTP, cron, lock, connessioni persistenti e processi pianificati.

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Se l’anomalia ricompare, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, picchi di traffico, importazioni e servizi esterni. Documenta causa, correzione e prova finale.

Procedura di risoluzione

1. Correggere l’hostname o l’URL configurato. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.
2. Ripristinare resolver DNS affidabili sul server. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.
3. Creare o correggere i record autoritativi necessari. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.
4. Allineare DNSSEC, DS e DNSKEY. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.
5. Correggere proxy, container o policy di rete. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.
6. Aggiornare endpoint rimasti dal vecchio ambiente. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.
7. Ritestare la richiesta WordPress e monitorare i log. Applica la modifica soltanto al componente confermato, conserva il valore precedente e rispetta i TTL DNS. Ripeti la stessa richiesta da WordPress e dalla riga di comando, quindi controlla che non compaiano nuovi errori di risoluzione o connessione.

Controlli finali

• La richiesta che generava WordPress cURL error 6 ora completa correttamente.
• L’hostname restituisce A o AAAA validi dal server.
• I nameserver autoritativi e gli eventuali record DNSSEC sono coerenti.
• Plugin, cron e aggiornamenti collegati all’endpoint funzionano.
• La configurazione precedente e le modifiche effettuate sono documentate.

Prevenzione

• Documenta endpoint, webhook e servizi esterni utilizzati dai plugin.
• Monitora scadenza del dominio, delega DNS e validazione DNSSEC.
• Evita hostname interni o temporanei nelle configurazioni di produzione.
• Verifica le chiamate HTTP dopo migrazioni, cambi DNS e aggiornamenti importanti.
• Mantieni resolver e configurazioni di rete gestiti in modo centralizzato.

Errori da evitare

• Non sostituire l’hostname con un IP permanente senza valutare TLS, bilanciamento e cambi futuri.
• Non disattivare DNSSEC senza aver identificato una incoerenza reale.
• Non modificare contemporaneamente nameserver, record, proxy e firewall.
• Non condividere token, licenze o URL contenenti credenziali.
• Non considerare la cache locale come prova dello stato autoritativo.

Quando contattare l’assistenza Xlogic

Apri un ticket quando l’hostname risolve dai resolver pubblici ma non dal server, quando il problema coinvolge più domini oppure quando servono controlli sulla rete in uscita. Indica:

• dominio e hostname remoto interessato;
• data e ora con fuso;
• messaggio completo di cURL;
• output DNS ottenuto dal server, senza dati sensibili;
• plugin, cron o funzione che avvia la richiesta.

Non inviare credenziali. I dati tecnici sopra indicati sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• libcurl error codes
• WordPress HTTP API

Domande frequenti su WordPress cURL error 6