WordPress loopback request failed significa che il sito non riesce a effettuare una richiesta HTTP verso sé stesso. Le richieste loopback vengono utilizzate da WP-Cron, Site Health e alcune operazioni in background.
Questa guida approfondisce WordPress loopback request failed con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.
Che cosa significa
Il browser può aprire il sito mentre il server non riesce a raggiungere lo stesso hostname per DNS, firewall, TLS, autenticazione o tempi di risposta.
Il test deve usare l’URL canonico e non dovrebbe dipendere da modifiche permanenti al file hosts del server.
Come riconoscere il problema
- Site Health segnala loopback failed.
- WP-Cron non esegue attività.
- Pubblicazioni pianificate saltano.
- Plugin di backup o elaborazione restano in coda.
- La richiesta interna riceve 401, 403, 500 o timeout.
Cause più frequenti
1. DNS interno errato
Il server risolve il dominio verso un IP non corretto. 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. Basic Authentication
Uno staging o sito protetto richiede credenziali. 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 o WAF
La richiesta dall’IP del server viene bloccata. 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
Certificato, hostname o catena non sono validi. 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. Sito lento
La pagina richiamata 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.
6. Redirect loop
URL WordPress e HTTPS non sono coerenti. 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
- Leggi il messaggio Site Health. Annota URL, codice e errore cURL. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla DNS dal server. Verifica che il dominio risolva all’origine prevista. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Testa HTTPS. Controlla certificato e catena. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica autenticazione. Basic Auth o manutenzione possono impedire il loopback. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla WAF. Cerca l’IP del server nei log. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla cron. Verifica eventi accumulati e trigger. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Misura il tempo. La richiesta interna deve rispondere rapidamente. 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 DNS. Allinea hostname e indirizzo origine. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Consenti il loopback in modo mirato. Configura autenticazione o WAF senza aprire l’intero sito. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Correggi SSL. Usa un certificato valido per l’hostname. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Rimuovi il redirect loop. Allinea home, siteurl e proxy. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Ottimizza la pagina. Riduci plugin e query che rallentano il loopback. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Configura un cron reale quando appropriato. Se disabiliti WP-Cron, crea il relativo cron cPanel. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Ripeti Site Health. Verifica anche eventi pianificati e REST API. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
Controlli finali
- Site Health supera il loopback.
- Cron esegue gli eventi.
- Nessun timeout cURL.
- HTTPS è valido.
- Il WAF non blocca la richiesta interna.
Prevenzione
- Mantieni DNS coerente.
- Monitora cron.
- Usa SSL valido.
- Evita redirect duplicati.
- Ottimizza il sito.
Errori da evitare
- Non disattivare SSL verify.
- Non allowlistare tutto Internet.
- Non modificare hosts senza documentazione.
- Non disabilitare WP-Cron senza cron reale.
- Non ignorare attività in coda.
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:
- messaggio Site Health
- URL
- IP origine
- orario
- codice o errore cURL
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 loopback request failed
Il sito si apre ma il loopback fallisce: è possibile?
Sì, il browser e il server possono usare DNS, rete e autenticazione differenti.
Il loopback serve a WP-Cron?
Sì, WordPress usa richieste interne per avviare attività pianificate in molte configurazioni.
Posso disattivare il test?
Non risolve la causa e può lasciare cron o operazioni in background non funzionanti.
Basic Auth può bloccarlo?
Sì, soprattutto su staging protetti.
Quale dato è più utile?
Il codice o errore cURL completo riportato da Site Health.