WordPress cURL error 28 indica che una richiesta HTTP effettuata dal sito non ha ricevuto una risposta completa entro il tempo disponibile. Il problema può riguardare un’API esterna, il loopback verso il sito stesso, DNS, TLS, firewall o un servizio lento.
Questa guida approfondisce WordPress cURL error 28 con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.
Che cosa significa
WordPress usa l’HTTP API per aggiornamenti, cron, Site Health, webhook e integrazioni. Il messaggio deve essere letto insieme all’URL e al numero di millisecondi indicato.
Aumentare il timeout senza controllare la destinazione può rendere il sito più lento e lasciare processi PHP occupati più a lungo.
Come riconoscere il problema
- Site Health mostra cURL error 28.
- Aggiornamenti o licenze non si verificano.
- Webhook e API falliscono.
- WP-Cron non completa alcune attività.
- La richiesta verso il sito stesso va in timeout.
Cause più frequenti
1. Servizio remoto lento
L’endpoint non risponde entro il timeout. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
2. DNS
Il dominio remoto o locale impiega troppo a risolversi o restituisce valori errati. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
3. Firewall
Connessioni in uscita o loopback vengono filtrate. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
4. TLS o certificato
La negoziazione non termina o la catena non è valida. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
5. Plugin o tema
Una richiesta viene eseguita ripetutamente o verso URL errato. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
6. Sito lento
Il loopback chiama una pagina che richiede troppe risorse. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
Diagnosi passo per passo
- Identifica l’URL. Copia la destinazione completa dal messaggio. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Misura dall’esterno e dal server. Confronta tempo DNS, connessione, TLS e risposta. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla Site Health. Verifica se il problema riguarda REST API o loopback. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Esamina log. Cerca timeout, errori DNS, SSL e plugin coinvolti. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Disattiva il componente in staging. Conferma se la richiesta è generata da un plugin. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica cron e code. Controlla attività che ripetono il tentativo. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla firewall e allowlist. Usa IP e hostname ufficiali senza creare aperture generiche. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
Metodo sicuro di intervento
Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.
Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.
Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.
Procedura di risoluzione
- Correggi URL o DNS. La destinazione deve risolvere e rispondere correttamente. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Aggiorna plugin e integrazione. Usa endpoint e metodi supportati. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Riduci il lavoro dell’endpoint. Ottimizza la pagina richiamata in loopback. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Imposta timeout ragionevole. Modifica soltanto la richiesta specifica se l’API richiede più tempo. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Correggi TLS. Aggiorna certificati e hostname. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Gestisci errori e retry. Usa backoff per non creare loop. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Richiedi verifica rete. Fornisci destinazione, orario e messaggio se la connessione è filtrata a livello server. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
Controlli finali
- La richiesta termina.
- Site Health non segnala il timeout.
- Cron e webhook funzionano.
- Nessun loop di retry.
- Il tempo di risposta è stabile.
Prevenzione
- Usa endpoint affidabili.
- Imposta timeout e retry.
- Monitora webhook.
- Aggiorna plugin.
- Ottimizza loopback.
Errori da evitare
- Non disabilitare verifica SSL.
- Non aumentare globalmente il timeout.
- Non consentire tutti gli IP.
- Non ignorare l’URL nel messaggio.
- Non rilanciare continuamente la richiesta.
Come documentare la verifica
Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.
Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.
Controllo incrociato
Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.
Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- errore completo
- URL destinazione
- orario
- plugin o funzione
- risultato del test esterno
Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.
Fonti tecniche ufficiali
Domande frequenti su WordPress cURL error 28
cURL error 28 significa che cURL è mancante?
No. cURL è attivo ma la richiesta ha superato il tempo disponibile.
Posso disattivare la verifica SSL?
No. Espone la comunicazione e non risolve DNS o lentezza.
Perché appare in Site Health?
WordPress esegue test REST e loopback tramite la propria HTTP API.
Aumentare il timeout è sicuro?
Solo per una richiesta specifica e dopo aver verificato che l’endpoint sia legittimamente lento.
Quale URL devo controllare?
Quello riportato nel messaggio completo, non soltanto il dominio del sito.