WordPress cURL error 6: Could not resolve host

In breve: WordPress cURL error 6: indica che il server non riesce a risolvere l’hostname richiesto in un indirizzo IP.

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.

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.

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.

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.

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.

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.

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.

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.

Domande frequenti

Guide Xlogic correlate

• WordPress Parse error: syntax error, unexpected
• WordPress non invia email: wp_mail e SMTP
• WordPress sessione PHP attiva in Site Health