L’errore 502 Bad Gateway indica che un server usato come gateway o proxy ha ricevuto una risposta non valida dal servizio a monte. Il browser raggiunge quindi un livello dell’infrastruttura, ma quel livello non riesce a ottenere una risposta utilizzabile da PHP, dall’applicazione o dal server di origine.
Questa guida approfondisce errore 502 Bad Gateway 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 codice 502 non identifica automaticamente un guasto del server hosting. Può essere generato da una CDN, da un reverse proxy, dal web server o da un’applicazione che termina la connessione in modo inatteso.
Per una diagnosi corretta bisogna stabilire quale componente ha prodotto la pagina di errore e confrontare l’orario con log applicativi, error_log, modifiche recenti e stato delle risorse.
Come riconoscere il problema
- Il sito mostra 502 su tutte le pagine o soltanto in alcune operazioni.
- Il problema compare durante importazioni, backup, aggiornamenti o richieste API.
- Bypassando Cloudflare o la CDN il comportamento cambia.
- Il 502 è intermittente e scompare ricaricando la pagina.
- Frontend e wp-admin possono avere esiti diversi.
Cause più frequenti
1. Processo PHP terminato o non raggiungibile
Il web server può non ricevere una risposta valida dal processo PHP a causa di crash, riavvio, timeout interno o errore fatale. 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. Applicazione sovraccarica
Query lente, plugin pesanti, richieste simultanee o processi bloccati possono impedire all’applicazione di rispondere correttamente. 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. Proxy o CDN
Cloudflare, un reverse proxy o un bilanciatore può ricevere una risposta vuota, interrotta o non conforme dal server di origine. 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. Plugin, tema o codice personalizzato
Un componente aggiornato di recente può chiudere la risposta, produrre output anomalo o richiedere servizi esterni non disponibili. 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. Problema DNS verso l’origine
La CDN può contattare un indirizzo IP vecchio o un server che non ospita più il sito. 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. Manutenzione o riavvio temporaneo
Aggiornamenti di sistema, riavvii di servizi o interventi sull’applicazione possono produrre un errore breve e isolato. 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 chi genera il 502. Controlla logo, intestazioni HTTP e contenuto della pagina per capire se l’errore proviene da Cloudflare, LiteSpeed, un proxy o dall’applicazione. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Registra URL e orario. Annota l’indirizzo esatto, l’operazione eseguita e l’ora al minuto per confrontare i log. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla error_log. Cerca fatal error, processi terminati, memoria esaurita, timeout, connessioni al database e percorsi di plugin o tema. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica le risorse. Controlla CPU, memoria, processi simultanei, I/O e limiti CloudLinux nell’intervallo interessato. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Prova senza cache applicativa. Svuota soltanto le cache pertinenti dopo aver conservato lo stato e ripeti il test senza disattivare globalmente la sicurezza. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Confronta origine e CDN. Quando tecnicamente possibile, verifica la risposta dell’origine con hostname corretto senza cambiare pubblicamente i DNS. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Riduci l’operazione. Ripeti con un import più piccolo, una richiesta semplice o il componente sospetto disattivato in staging. 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 l’errore applicativo. Intervieni sul file, plugin, tema o query indicati dal registro invece di aumentare limiti senza diagnosi. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Riduci il carico. Suddividi importazioni, backup e operazioni massive in batch più piccoli. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Aggiorna componenti incompatibili. Usa versioni compatibili di WordPress, plugin, tema e PHP, dopo backup e test. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Verifica l’indirizzo di origine. Assicurati che CDN e proxy contattino l’IP corretto e che il certificato dell’origine sia valido. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Controlla timeout e servizi esterni. Riduci dipendenze lente e gestisci correttamente errori delle API. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Ripristina la modifica recente. Se il problema è iniziato subito dopo un intervento, torna alla configurazione precedente verificata. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Contatta l’assistenza con dati precisi. Fornisci URL, orario, IP pubblico e messaggio del log quando il problema coinvolge servizi non gestibili dal pannello. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
Controlli finali
- Le pagine interessate restituiscono HTTP 200.
- Il test funziona sia tramite CDN sia sull’origine prevista.
- error_log non registra nuovi fatal error.
- Le risorse restano sotto soglia durante l’operazione.
- Il problema non ricompare ripetendo lo stesso flusso.
Prevenzione
- Mantieni plugin, temi e PHP compatibili.
- Programma attività pesanti in orari controllati.
- Monitora error_log e utilizzo risorse.
- Evita dipendenze esterne prive di timeout applicativo.
- Testa modifiche e importazioni in staging.
Errori da evitare
- Non aumentare indiscriminatamente tutti i timeout.
- Non disattivare CDN, firewall o WAF in modo permanente.
- Non ricaricare centinaia di volte la stessa operazione.
- Non attribuire il problema al server senza leggere i log.
- Non ripristinare un backup senza valutare dati recenti.
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:
- URL e operazione che genera il 502
- data e ora precise
- frequenza del problema
- estratto pertinente di error_log
- modifiche, plugin o importazioni recenti
Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.
Fonti tecniche ufficiali
Domande frequenti su errore 502 Bad Gateway
Un errore 502 significa che il server è offline?
Non necessariamente. Un gateway può essere raggiungibile ma ricevere una risposta non valida dall’applicazione o dall’origine.
Svuotare la cache risolve il 502?
Solo se viene servita una risposta memorizzata errata. Non corregge crash PHP, query lente o problemi dell’origine.
Cloudflare può mostrare un 502 generato dal server?
Sì. La grafica e le intestazioni aiutano a distinguere un errore Cloudflare da una risposta 502 proveniente dall’origine.
Devo aumentare max_execution_time?
Soltanto se il registro conferma che il tempo di esecuzione è la causa e l’operazione è legittimamente lunga.
Quali dati servono all’assistenza?
URL, orario, frequenza, operazione, IP pubblico ed estratto del log. Non servono password.