Errore 502 Bad Gateway - come capirne la causa e risolverlo

Capire come risolvere l’errore 502 bad gateway significa distinguere un blocco momentaneo da un problema più serio nella catena tra browser, proxy e server di origine. In questa guida trovi i controlli rapidi da fare subito, i segnali che indicano un guasto lato sito e i passaggi tecnici che aiutano chi gestisce un progetto web. Io partirei sempre dalla causa più probabile, perché nel caso dei 502 perdere tempo su ipotesi casuali è il modo migliore per non arrivare da nessuna parte.

Che cosa indica davvero un 502 Bad Gateway

MDN descrive il 502 come una risposta ricevuta da un gateway o proxy che non corrisponde a quella attesa dal server a monte. Tradotto in modo semplice: il browser ha raggiunto un intermediario, ma l’intermediario non è riuscito a parlare bene con il servizio che doveva generare la pagina.

Il punto chiave è questo: il 502 è quasi sempre un sintomo di comunicazione interrotta, non una colpa del browser in sé. Le cause più frequenti sono un backend sovraccarico, un processo caduto, un timeout, un errore di configurazione, un problema DNS o un filtro di rete troppo rigido.

Quando il messaggio compare e poi sparisce da solo, spesso siamo davanti a un picco temporaneo. Quando invece ritorna più volte, soprattutto sulla stessa pagina o sullo stesso dominio, vale la pena smettere di “provare a caso” e passare a un controllo ordinato. Ed è esattamente da lì che conviene partire.

I controlli rapidi da fare nel browser

Io inizio quasi sempre dal lato più economico da escludere: il browser. Non perché il 502 nasca lì, ma perché una cache vecchia, un’estensione o una sessione corrotta possono rendere il problema più confuso di quanto sia davvero.

1. Aspetta 30-60 secondi e ricarica una sola volta. Se il sito ha avuto un picco o un riavvio breve, spesso basta questo.
2. Apri la pagina in una finestra anonima. In questo modo isoli cookie, sessioni e gran parte delle estensioni.
3. Svuota cache e cookie solo per quel dominio, non per forza per tutto il browser. È un controllo più pulito e meno invasivo.
4. Disattiva temporaneamente ad blocker, script blocker e strumenti di sicurezza del browser. Alcuni interferiscono con CDN, login o richieste API.
5. Prova un altro browser o un altro dispositivo. Se il 502 scompare, il problema non è universale.
6. Cambia rete: Wi-Fi, dati mobili, hotspot o una connessione diversa. Se il sito funziona altrove, il sospetto si sposta su DNS, router o ISP.

Se hai appena cambiato DNS o hai ricevuto un 502 dopo un cambio di rete, svuotare la cache DNS del sistema può aiutare, ma solo quando il problema è davvero legato alla risoluzione dei nomi. Se invece non cambia nulla, il passo successivo è capire se l’anomalia dipende dal tuo ambiente o dal sito stesso.

Come capire se il problema è locale o lato server

Qui uso una regola molto semplice: se cambia il contesto e cambia anche l’errore, il problema è probabilmente locale; se l’errore resta identico ovunque, il guasto è più probabilmente server-side. È un filtro brutale, ma funziona meglio di tante prove sparse.

Quando il pattern è chiaro, la diagnosi diventa molto più rapida. Se il problema non si lascia ricondurre al browser o alla rete locale, allora il punto critico è quasi sempre la catena tecnica che sta dietro alla pagina.

Se il sito è tuo, dove cercare il guasto

Qui il discorso cambia. Un reverse proxy, cioè un server intermedio che riceve le richieste dal visitatore e le gira al backend, può restituire 502 quando il servizio a monte non risponde, risponde in modo invalido o impiega troppo a farlo.

• Proxy e CDN: verifica che raggiungano davvero l’origine. Se il problema è nella catena di passaggio, il 502 nasce prima ancora che l’applicazione veda la richiesta.
• Applicazione: controlla se il processo è vivo, se è andato in crash o se ha esaurito memoria e CPU. Un backend saturo smette di rispondere in modo pulito.
• Timeout: quando il server impiega troppo a completare la risposta, il proxy può restituire un errore anche se l’app “è ancora lì”.
• Database e servizi esterni: se il sito aspetta una query lenta, un’API terza o un servizio di autenticazione, il blocco si propaga facilmente.
• Firewall, SSL e configurazione: un certificato rotto, una porta chiusa o una regola troppo restrittiva bastano a interrompere la comunicazione.
• Log e ultime modifiche: per me restano il primo posto da guardare. Un deploy recente, un cambio di variabile o un plugin aggiornato spiegano più 502 di quanto si ammetta volentieri.

Questo è anche il punto in cui il tema tocca i motori di ricerca. Google Search Central segnala che gli errori 5xx portano i crawler a rallentare temporaneamente la scansione; se il problema persiste, la stabilità dell’indice ne risente. In pratica, un 502 che dura non è solo un disservizio tecnico: per un sito editoriale o commerciale può diventare anche un problema di visibilità.

Una volta esclusi questi punti, resta utile capire quali errori di diagnosi fanno perdere tempo a chi prova a risolvere tutto in fretta.

Gli errori più comuni che fanno perdere tempo

La parte più costosa, nei 502, non è quasi mai il bug in sé. È il tempo speso a inseguire l’ipotesi sbagliata. Io vedo ripetersi sempre gli stessi scivoloni.

Se voglio ridurre il rumore, confronto anche i codici più vicini al 502. Il 500 indica un errore interno più diretto, il 503 parla spesso di servizio indisponibile o manutenzione, il 504 segnala un timeout sul gateway. Capire questa differenza evita di inseguire la soluzione sbagliata e aiuta a leggere meglio i log.

Da qui il passo successivo è la prevenzione: non basta spegnere l’incendio, bisogna evitare che torni.

Come evitare che il 502 diventi un problema ricorrente

Se gestisci un sito, la strategia più sana è rendere i 502 rari, brevi e visibili. Non si eliminano tutti gli incidenti, ma si può fare molto per ridurre durata e frequenza.

• Imposta un monitoraggio serio: uptime check, alert e log centralizzati ti dicono subito quando il problema inizia, non quando lo scoprono gli utenti.
• Verifica i health check: un backend che non supera i controlli di salute dovrebbe uscire dal traffico prima di generare errori a catena.
• Rivedi i timeout: timeout troppo stretti producono falsi 502, timeout troppo larghi nascondono un backend lento. La via giusta sta nel mezzo, misurata sul tuo stack.
• Fai deploy più prudenti: rilasci graduali, possibilità di rollback e test su staging riducono molto gli incidenti dopo le modifiche.
• Proteggi i picchi di traffico: caching, code e scaling aiutano quando il problema nasce da saturazione, che è una delle cause più banali e più frequenti.
• Prepara una pagina di manutenzione corretta: se devi fermare il servizio, meglio un 503 dichiarato bene che un 502 confuso e intermittente.

Per un sito editoriale, questa disciplina conta più di quanto sembri: anche pochi minuti di indisponibilità durante la pubblicazione o l’aggiornamento di una pagina possono rovinare l’esperienza dell’utente e rallentare la scansione dei crawler. Se il 502 è sporadico, io resto prudente; se si ripete, lo tratto come un problema di infrastruttura fino a prova contraria. È questo approccio, più che il singolo trucco, a portare davvero alla causa giusta.