502 Bad Gateway: guida alla diagnosi per livelli

TL;DR — Un 502 Bad Gateway significa che un server stava chiedendo a un altro server la tua pagina e ha ricevuto una risposta errata. Di solito il server “anteriore” è una CDN o un proxy, mentre quello “posteriore” è il tuo sito reale (l’origine). L’errore riguarda hosting/infrastruttura — non Google console di ricerca — e nella pratica un 502 di breve durata comporta in genere un rischio SEO limitato, anche se Google non pubblica una durata “sicura” esatta. Diventa un problema più serio quanto più a lungo persiste.

Che cos’è un 502 Bad Gateway

Quando carichi una pagina, la richiesta spesso non arriva direttamente al tuo sito. Passa attraverso un intermediario — una CDN (come Cloudflare), un load balancer o un reverse proxy (come Nginx). L’intermediario inoltra la richiesta al tuo server reale, attende una risposta e la restituisce al visitatore.

Un 502 Bad Gateway è ciò che l’intermediario mostra quando ha chiesto la pagina al tuo server e ha ricevuto qualcosa di non valido — oppure niente. In parole semplici: il server anteriore non ha ottenuto una buona risposta dal server posteriore. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Questa è la sfumatura importante. Un 502 non significa automaticamente che il sito sia fuori uso. Il server può essere perfettamente sano e rispondere bene a una richiesta diretta, ma se il proxy davanti non riesce a raggiungerlo (per un timeout, una configurazione errata o un problema momentaneo della CDN), i visitatori vedranno comunque un 502.

In che cosa differisce dai codici cugini

Vedrai alcuni errori 5xx che sembrano simili:

• 500 — il codice del sito ha incontrato un errore mentre costruiva la pagina.
• 502 — un proxy davanti al sito ha ricevuto una risposta errata dal sito.
• 503 — il sito è deliberatamente non disponibile (manutenzione pianificata, sovraccarico).
• 504 — un proxy ha atteso il server ma è andato in timeout senza ricevere alcuna risposta.

Sono collegati, ma indicano punti diversi da esaminare.

Un 502 danneggia la SEO?

Di solito non molto, finché non dura. Il crawler di Google (Googlebot) tratta un 502 come gli altri errori 5xx: rallenta la scansione in proporzione al numero di URL che restituisce errori e poi aumenta di nuovo il ritmo quando il sito torna a rispondere con 2xx. Google non pubblica una durata “sicura” esatta, ma un 502 breve — da pochi minuti a un paio d’ore — comporta nella pratica un rischio molto inferiore rispetto a un errore che continua a ripresentarsi. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Il rischio reale compare quando un 502 continua a ripresentarsi o resta attivo per un periodo prolungato. La formulazione di Google è che rimuove gli URL che restituiscono “persistently” (traduzione) «La citazione descrive il comportamento indicato nel testo.» un errore del server: non definisce questo termine come un numero specifico di giorni. John Mueller di Google ha menzionato informalmente “diversi giorni” come indicazione approssimativa del momento in cui le pagine iniziano a scomparire e ha detto che tendono a tornare quando il sito si riprende; consideralo però il parere approssimativo di una persona su un incidente specifico, non una regola ufficiale.

Che cosa fare

• Non provare a “risolvere” il problema in console di ricerca. console di ricerca si limita a segnalare un 502 dopo che si è verificato. La correzione avviene sulla CDN, sul proxy o sul server.
• Controlla se succede solo a te o a tutti. Se tutto Internet funziona ma il tuo sito è inattivo, il problema è nella tua configurazione. Se una grande CDN sta avendo un’interruzione, potrebbe non dipendere affatto da te: sul tuo lato non c’è nulla da correggere, se non aspettare.
• Controlla la pagina di stato della CDN o dell’host e i log del server. È lì che si trova la risposta reale.

Vuoi la diagnosi livello per livello (CDN, proxy e origine), l’esatto contenuto dei documenti Google e ciò che John Mueller ha detto durante l’interruzione di Cloudflare del novembre 2025? Passa alla scheda Advanced.

TL;DR — Un 502 è un errore del livello proxy/gateway: RFC 9110 §15.6.3 lo definisce come un gateway o proxy che riceve una risposta non valida da un server a monte. È distinto da 500 (errore dell’applicazione d’origine) e 503 (origine deliberatamente non disponibile). La documentazione di Google raggruppa 500, 502 e 503 nello stesso trattamento 5xx: la frequenza di scansione diminuisce in proporzione al numero di URL in errore, i contenuti delle risposte 5xx vengono ignorati e gli errori persistenti rimuovono le pagine dall’indice. Il recupero è graduale quando tornano le risposte 2xx, anche se Google non pubblica una tempistica fissa. La durata conta, ma non esiste una soglia ufficiale: i picchi brevi comportano un rischio pratico molto inferiore, mentre gli errori che continuano a ripresentarsi sono quelli che mettono davvero a rischio le pagine — le osservazioni di Mueller del novembre 2025 lo collocano informalmente nell’ordine di più giorni, non come SLA documentato. Diagnostica per livello — CDN, reverse proxy o origine — e correla le prove tra gli hop invece di fidarti solo di una pagina di errore personalizzata.

Che cosa segnala davvero un 502

RFC 9110 §15.6.3 definisce nello specifico 502 come un gateway o proxy che riceve una risposta non valida da un server in ingresso raggiunto mentre cercava di soddisfare la richiesta. Questo confine della specifica è importante: identifica il punto in cui il gateway ha osservato il fallimento, non necessariamente l’hop che lo ha causato. Lo stato 502 è una prova di un errore di confine, non la prova che l’applicazione d’origine sia rotta. È la distinzione che la maggior parte degli articoli concorrenti sulle “13 modi per risolvere il problema” sfuma, ed è il motivo per cui la diagnosi seguente è stratificata e non piatta. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Confronta i codici 5xx che si confondono facilmente:

• 500 Internal Server Error — l’applicazione d’origine è andata in errore (bug del codice, eccezione non gestita, esaurimento delle risorse). L’origine ha risposto e la risposta è stata: “mi sono rotto”.
• 502 Bad Gateway — il proxy ha ricevuto una risposta malformata o non valida dal server a monte (RFC 9110 §15.6.3).
• 503 Service Unavailable — l’origine è deliberatamente non disponibile; è il codice intenzionale, autorizzato da Google, di “torna più tardi” per la manutenzione pianificata, idealmente con un header Retry-After.
• 504 Gateway Timeout — il proxy ha atteso il server a monte e non ha ricevuto nulla prima della scadenza del timeout (RFC 9110 §15.6.5). (502 = risposta errata; 504 = nessuna risposta in tempo.)

La conseguenza pratica è questa: 503 è il codice che scegli intenzionalmente; 502 è il codice che ti capita quando l’infrastruttura fallisce.

Come gestisce Googlebot un 502

Ecco la parte da ancorare alla documentazione reale di Google, invece della formula vaga “può danneggiare il ranking” che si legge altrove. Il documento Google sugli errori HTTP e di rete elenca 502 (bad gateway) tra i codici 5xx e assegna a tutti i codici 5xx lo stesso trattamento:

• La frequenza di scansione diminuisce proporzionalmente. Google riduce la frequenza di scansione del sito e la riduzione è proporzionale al numero di singoli URL che restituiscono un errore del server. Pochi 502 hanno un impatto minore; un 502 sull’intero sito è un chiaro “rallenta”.
• I contenuti 5xx vengono ignorati. Qualsiasi contenuto ricevuto da un URL che restituisce 5xx viene ignorato: Google non indicizzerà una pagina di errore 502 come contenuto del sito.
• La conservazione nell’indice è temporanea. Gli URL già indicizzati restano inizialmente nell’indice, ma la pipeline di indicizzazione di Google rimuove gli URL che restituiscono persistentemente un errore del server.
• Il recupero è automatico e graduale. Quando il server torna a rispondere con 2xx, Google aumenta gradualmente la frequenza di scansione. Non servono reinvio, richiesta di riconsiderazione o rituali sul pulsante “validate fix” per il recupero ordinario: quel pulsante dice solo a Google di ricontrollare prima.

La conclusione più importante è questa: 502 viene trattato come 500 e 503. Non è “meno grave” perché nasce dal livello proxy/CDN invece che dall’applicazione d’origine. Non esiste una tolleranza documentata specifica per 502. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

La durata è tutta la storia

Il fatto che un 502 ti danneggi davvero dipende da quanto dura, ma Google non pubblica una durata sicura fissa né una soglia fissa per la rimozione, quindi considera quanto segue un’indicazione pratica, non uno SLA:

• Un picco breve (da pochi minuti a qualche ora) → la riduzione della frequenza di scansione di Google cresce con il numero di URL in errore, quindi un picco breve e circoscritto ha un impatto pratico ridotto e in genere non richiede indagini in Search Console. Nulla nella documentazione Google esenta formalmente gli errori brevi: è una questione di grado, non un limite rigido.
• Un errore che continua a ripresentarsi o resta attivo → è la finestra in cui si applica la formulazione di Google “persistently return a server error” e le pagine possono iniziare a uscire dall’indice. Google non definisce “persistently” come un numero preciso di giorni. Il commento pubblico di Mueller (sotto) lo colloca informalmente nell’ordine di multiple days, con un recupero abbastanza rapido quando il sito è sano; è però la lettura di un professionista su un incidente specifico, non una regola documentata su cui fare affidamento per ogni sito o CDN.

Questo si collega in modo approssimativo all’interruzione di Cloudflare del novembre 2025, quando un’ondata di siti ha restituito errori 5xx senza colpa propria. La risposta pubblica di Mueller su Bluesky è stata che la scansione 5xx rallenta ma “ramps back up”: consulta la scheda Quotes per la formulazione esatta e le note sulla fonte, compreso un commento separato sui “diversi giorni” riportato da un riepilogo di terze parti e non verificato rispetto al thread originale. Un’interruzione breve e confermata dal provider è quasi il caso migliore: è visibile, in genere si risolve da sola e, una volta che il provider conferma il recupero e le tue risposte 2xx sono tornate, di solito conviene aspettare anziché modificare reattivamente l’infrastruttura.

Diagnosticare un 502 per livello

Poiché un 502 è un errore di comunicazione tra server, il modo più rapido per trovarlo è scendere nello stack — CDN, poi reverse proxy, poi origine — invece di eseguire una checklist piatta. (La scheda Decision Trees lo presenta come una procedura guidata.)

Un’avvertenza prima di iniziare: una pagina di errore personalizzata, il nome del provider in un header o l’aspetto dell’interruzione sono un segnale di prova, non la dimostrazione di quale hop abbia fallito. Correlali con gli header della risposta, gli ID della richiesta/trace e i log con timestamp su entrambi i lati dell’hop prima di concludere “è la CDN” o “è la mia origine”.

Livello CDN / edge

• Timeout a monte: il nodo edge non ha ricevuto in tempo una risposta dall’origine.
• L’edge non riesce a raggiungere affatto l’origine: errore di risoluzione DNS, errore di handshake SSL/TLS o firewall/sicurezza dell’origine che blocca gli intervalli IP della CDN.
• Le cause documentate variano tra provider: la documentazione di troubleshooting di Cloudflare descrive scenari di connettività e timeout dell’origine specifici della sua rete edge, mentre AWS CloudFront documenta il proprio insieme di cause TLS, DNS, porta e funzione d’origine; controlla la documentazione della tua CDN senza presumere che l’elenco di un provider valga per un altro.
• Interruzione del provider CDN (Cloudflare, Fastly, AWS ecc.): un evento di 502 di massa su siti non correlati che non ha nulla a che vedere con la salute del tuo server; verifica la pagina di stato del provider, non solo il branding della pagina di errore.

Livello reverse proxy / load balancer (Nginx, Apache mod_proxy, HAProxy)

• Timeout del backend o connessione rifiutata.
• Un proxy_pass / blocco upstream configurato male e diretto al posto sbagliato.
• Esaurimento del pool backend: ogni worker upstream è occupato.
• Mismatch SSL/TLS tra il proxy e il backend.

Livello server d’origine

• Crash o riavvio dell’applicazione/PHP-FPM, oppure terminazione OOM (limite di memoria superato).
• Esaurimento delle connessioni al database.
• Un deploy/riavvio che causa una breve indisponibilità.
• Un WAF o plugin di sicurezza che blocca IP legittimi del proxy o del crawler come se fossero aggressori: è il caso subdolo, perché i browser normali funzionano mentre il proxy (o Googlebot) riceve 502.

Vale la pena evidenziare quest’ultimo pattern: se solo Googlebot o solo le richieste passate dalla CDN ricevono 502 mentre i browser normali no, stai guardando un blocco specifico per bot o un problema di risposta variabile, non una vera interruzione. Prova direttamente verso l’origine e tramite CDN, poi verifica ciò che vede davvero Googlebot con il test live di URL Inspection in console di ricerca invece di presumere un impatto ancora in corso da un report Errore del server (5xx) che potrebbe essere già obsoleto.

Risolvere e prevenire i 502

Le correzioni dipendono dal livello e dal ruolo di chi deve applicarle:

• Visitatore — non c’è nulla da correggere. Ricarica una volta, prova una rete diversa se sospetti un problema locale e altrimenti aspetta: le modifiche lato browser non possono riparare un errore tra server.
• Proprietario del sito senza accesso all’infrastruttura — conferma l’ambito e controlla prima pagine di stato e log (vedi la checklist sotto), poi rivolgiti all’host, al supporto CDN o al team di sviluppo invece di tentare correzioni a caso.
• Proprietario dell’host/CDN/applicazione — correggi la configurazione proxy/upstream, aumenta timeout e capacità backend quando l’origine è il collo di bottiglia reale e distribuisci i deploy in modo scaglionato per evitare che i riavvii interrompano l’intero pool. Tratta allowlist WAF, modifiche firewall e modifiche alla configurazione proxy/upstream come cambiamenti che richiedono approvazione: applicali solo quando log e prove del provider mostrano davvero un errore di firewall o controllo accessi, non come ipotesi iniziale; mettere in allowlist una CDN o un crawler non è una correzione generica per i 502.

Per prevenire il problema, vincono le attività noiose: monitoraggio uptime con alert, monitoraggio dei log di errore server e proxy, controllo dell’andamento Host status e Errore del server (5xx) nelle Crawl Stats di console di ricerca e correlazione dei picchi con le pagine di stato dei provider CDN e DNS, così distingui in pochi secondi “il mio problema” da “la loro interruzione”.

I codici correlati da tenere distinti sono proprio accanto in questo cluster: l’origine 500, il codice intenzionale 503 e il timeout 504.

Riepilogo AI

Una sintesi della versione Advanced:

• 502 = errore del livello proxy/gateway. RFC 9110 §15.6.3 lo definisce come un gateway o proxy che riceve una risposta non valida da un server in ingresso: è una prova di un errore di confine, non la prova di quale hop (CDN, proxy o origine) l’abbia causato. L’origine può essere sana mentre i visitatori continuano a vedere 502.
• Cause distinte, stessa famiglia documentata. 500 (errore dell’app d’origine), 502 (il proxy riceve una risposta errata, RFC §15.6.3), 503 (origine deliberatamente non disponibile), 504 (il proxy non riceve una risposta in tempo, RFC §15.6.5). La documentazione Google raggruppa 500, 502 e 503 nello stesso trattamento 5xx: non documenta una parità specifica per codice oltre a questa regola di famiglia.
• Risposta di Googlebot: la frequenza di scansione diminuisce in proporzione al numero di URL in errore, i contenuti 5xx vengono ignorati, gli URL indicizzati sono conservati temporaneamente ma rimossi se gli errori persistono e la scansione riprende gradualmente quando tornano le risposte 2xx; Google non pubblica una durata sicura esatta né garantisce una tempistica di recupero.
• La durata conta, ma non c’è una soglia ufficiale. I picchi brevi comportano un rischio pratico molto inferiore; gli errori che continuano a ripresentarsi sono il rischio reale. Il commento informale di Mueller del novembre 2025 colloca le rimozioni dall’indice nell’ordine di “diversi giorni”, con un recupero abbastanza rapido: consideralo il parere di un professionista su un incidente, non uno SLA documentato.
• Diagnostica correlando le prove tra i livelli, non fidandoti solo del branding: CDN (timeout, errore DNS/SSL, interruzione del provider — Cloudflare e AWS CloudFront documentano cause specifiche di piattaforma diverse) → reverse proxy (proxy_pass errato, pool esaurito, connessione rifiutata) → origine (crash app/PHP-FPM, OOM, esaurimento DB, WAF che blocca IP proxy/crawler). Abbina header, trace ID e log con timestamp su entrambi i lati dell’hop prima di concludere quale livello abbia fallito.
• Non esiste una correzione unica per tutti. GSC segnala il 502 dopo il fatto e non può correggerlo. Nemmeno i visitatori possono farlo; i proprietari senza accesso all’infrastruttura devono rivolgersi al team competente invece di modificare la configurazione; e i cambiamenti distruttivi — allowlist WAF, modifiche firewall o proxy — devono seguire le prove dei log/provider, non essere un’ipotesi iniziale. Se solo Googlebot o solo le richieste via CDN ricevono 502, sospetta un blocco specifico per bot, non un’interruzione globale.

Documentazione ufficiale

Documentazione di prima mano su come i motori di ricerca gestiscono gli errori 5xx, inclusi i 502.

Google

• Come i codici di stato HTTP influenzano i crawler di Google — il documento di riferimento: elenca 502 (bad gateway) insieme a 500 e 503 e descrive il trattamento condiviso di frequenza di scansione e indicizzazione.
• Come gestire l’indisponibilità pianificata del sito — perché 503 (non 502, 404 o 200) è il codice corretto per un’indisponibilità intenzionale, con un header Retry-After. È utile per la distinzione 502-503.
• Specifica robots.txt — gestione degli errori server — come Google tratta un 5xx nel file robots.txt stesso.

Specifica

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — la definizione a livello di specifica: un gateway o proxy riceve una risposta non valida da un server in ingresso raggiunto mentre cercava di soddisfare la richiesta. Identifica il confine in cui il fallimento è stato osservato, non quale hop lo abbia causato.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — Bing mostra problemi di scansione lato server (classe 5xx), inclusi i fallimenti di connettività, nei suoi report sugli errori di scansione.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google. Ogni link porta direttamente al passaggio citato.

Google — come vengono gestiti i 5xx (inclusi i 502)

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (traduzione) «La citazione descrive il comportamento indicato nel testo.» — Google Search Central, Come i codici di stato HTTP influenzano i crawler di Google. Vai alla citazione
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (traduzione) «La citazione descrive il comportamento indicato nel testo.» — lo stesso documento, nella riga della tabella che comprende 500, 502, and 503. Vai alla citazione
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (traduzione) «La citazione descrive il comportamento indicato nel testo.» — same doc. Vai alla citazione (traduzione) Le citazioni della documentazione Google descrivono il rallentamento temporaneo della scansione, la conservazione iniziale degli URL indicizzati e la rimozione degli URL che restituiscono persistentemente errori.

John Mueller, Google (Bluesky, 18 novembre 2025 — risposta in un thread sul picco 5xx dell’interruzione Cloudflare)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (traduzione) «La citazione descrive il comportamento indicato nel testo.» Visualizza il post
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (traduzione) «La citazione descrive il comportamento indicato nel testo.» Riferito dal resoconto di Matt G. Southern su Search Engine Journal dello stesso scambio; verifica il thread originale prima di considerarlo definitivo. Read the coverage (traduzione) Queste citazioni riportano la spiegazione pubblica di Mueller sul rallentamento e sul successivo recupero della scansione, oltre al commento informale sui tempi di più giorni. Le note di fonte restano incluse.

Checklist per le risposte 502

Quando compare un 502 — nel browser, nel monitoraggio o nel report Errore del server (5xx) di console di ricerca — esegui questa lista. I ruoli sono: [Qualsiasi] funziona anche senza accesso all’infrastruttura; [Proprietario host/CDN/app] richiede quell’accesso.

• [Qualsiasi] Conferma che sia reale e attuale: riproduci ora l’URL; il report Errore del server (5xx) può essere in ritardo rispetto a un contrattempo già risolto.
• [Qualsiasi] Controlla l’ambito: è un URL, una sezione o l’intero sito? (L’impatto sulla scansione cresce con il numero di URL in errore.)
• [Qualsiasi] Controlla la pagina di stato del provider CDN/DNS per un’interruzione generale prima di modificare la tua configurazione.
• [Proprietario host/CDN/app] Prova direttamente l’origine e poi via CDN: se l’origine risponde 2xx direttamente ma la CDN restituisce 502, il problema è sull’edge o nel percorso intermedio.
• [Proprietario host/CDN/app] Controlla se solo bot/IP CDN ricevono 502 mentre i browser funzionano: potrebbe indicare un blocco WAF/firewall, non un’interruzione. Confermalo nei log firewall/WAF prima di mettere qualcosa in allowlist; l’allowlist non è una correzione generica e deve seguire le prove.
• [Proprietario host/CDN/app] Leggi i log di errore del proxy (Nginx/Apache/HAProxy) per timeout upstream o connessioni rifiutate.
• [Proprietario host/CDN/app] Leggi i log dell’origine per crash app, terminazioni OOM o esaurimento delle connessioni DB nei timestamp interessati.
• [Qualsiasi] Verifica ciò che vede Googlebot con il test live di URL Inspection in GSC.
• [Proprietario host/CDN/app] Applica la correzione specifica del livello solo dopo che le prove di log/provider la indicano: WAF, firewall, timeout e modifiche proxy sono cambiamenti infrastrutturali, non ipotesi iniziali.
• [Qualsiasi] Dopo la correzione lascia che il recupero avvenga: le risposte 2xx fanno gradualmente ripartire la scansione; Google non pubblica una tempistica precisa. Usa “Convalida correzione” solo per chiedere un nuovo controllo più rapido, non come “correzione”.
• [Proprietario host/CDN/app] Conferma che per ogni indisponibilità pianificata futura venga usato 503 (non 502).

Il mio 502 è un problema della CDN, del proxy o dell’origine?

Un 502 è un errore tra server, quindi diagnosticalo scendendo nello stack invece di indovinare. Parti dall’edge e procedi verso l’interno.

Q1. Il provider CDN o DNS segnala un’interruzione in questo momento?

• Sì → molto probabilmente è un’interruzione generale del provider (l’evento Cloudflare del novembre 2025 è il caso da manuale). Di solito non c’è nulla da correggere sul tuo lato. Conferma che l’origine sia sana, poi attendi il recupero: la frequenza di scansione di Google riparte gradualmente quando tornano le risposte 2xx, anche se non è pubblicata una tempistica esatta. Fermati qui.
• No → continua.

Q2. L’origine risponde 2xx a una richiesta diretta (bypassando CDN/proxy)?

• No — anche l’origine fallisce → il problema è al livello dell’origine. Controlla nei log crash app/PHP-FPM, terminazioni OOM, esaurimento connessioni DB o un deploy errato. Nota che, a seconda di come il proxy vede il problema, questo può apparire anche come 500 o 504. Fermati qui.
• Sì — l’origine è sana direttamente, ma CDN/proxy restituisce 502 → continua. L’origine funziona; qualcosa davanti non riesce a ottenere una risposta pulita.

Q3. I browser normali funzionano mentre solo Googlebot/IP CDN ricevono 502?

• Sì → sospetta un blocco WAF o firewall che tratta gli intervalli IP del proxy o del crawler come aggressori. Confermalo prima nei log firewall/WAF, poi metti in allowlist gli intervalli IP legittimi della CDN e dei crawler verificati: non farlo senza conferma. Fermati qui.
• No — tutti ricevono 502 via proxy → continua.

Q4. Che cosa mostrano i log del reverse proxy per il server a monte?

• Timeout / connessione rifiutata → il proxy raggiunge il backend ma non riceve una risposta valida in tempo → problema di capacità backend o timeout (pool esaurito, timeout troppo stretti). Aumenta capacità/timeout o correggi il backend lento.
• Host/DNS errato / errore di handshake SSL verso upstream → configurazione errata del proxy → correggi il blocco proxy_pass / upstream o la configurazione TLS proxy↔backend.

Qualunque sia il livello, la pulizia SEO è la stessa e richiede soprattutto di non intervenire inutilmente. Quando gli URL tornano a restituire 2xx, Google riprende automaticamente la scansione: non serve reinviarli.

Miti ed errori sui 502 da evitare

• Mito: “502 è un problema di ottimizzazione per i motori di ricerca che risolvo nella console di ricerca.” Falso. Un 502 è un errore dell’infrastruttura; la console di ricerca lo segnala dopo il fatto. La correzione è sulla CDN, sul proxy o sull’origine. «Convalida correzione» chiede solo al motore di ricerca di ricontrollare: non ripara nulla.
• Mito: “A 502 always means my server is down.” (traduzione) «Un 502 non significa sempre che il mio server sia inattivo.» No. L’origine può restituire 2xx a una richiesta diretta mentre i visitatori vedono 502 attraverso la CDN, per un timeout, una configurazione upstream errata o una stessa interruzione della CDN. Prova direttamente l’origine prima di presumere che il server sia caduto.
• Mito: “Il 502 è meno grave del 500 per la SEO.” (502 è meno grave di 500 per la SEO.) No. I documenti Google assegnano a 500, 502 e 503 la stessa riduzione della frequenza di scansione e la stessa eventuale rimozione dall’indice per gli errori persistenti. Non esiste una tolleranza documentata per 502.
• Mito: “A one-time 502 will deindex my page.” (traduzione) «Un 502 isolato non deindicizza automaticamente la pagina.» No. La scansione rallenta, poi riparte. Perché le pagine escano dall’indice l’errore deve persistere: i documenti Google usano questo concetto senza definire un numero esatto di giorni. Il commento informale di Mueller del novembre 2025 parla di multiple days (traduzione) «diversi giorni» e dice che le pagine rimosse “pop back in fairly quickly” (traduzione) «tornano rapidamente»; consideralo il parere di un professionista su un incidente, non una soglia ufficiale.
• Mito: (traduzione) «502 e 503 non significano la stessa cosa.» No. 503 è il codice intenzionale “servizio non disponibile” da usare per la manutenzione pianificata (con Retry-After); 502 è un errore proxy involontario. Confonderli nel monitoraggio nasconde gli incidenti reali dietro finestre di manutenzione attese.
• Mito: (traduzione) «Svuotare la cache del browser non risolve un 502 sull’intero sito.» È un consiglio per un visitatore che risolve la propria visualizzazione. Se CDN/proxy/origine sta davvero fallendo, nessuna azione lato browser cambia qualcosa per gli altri.
• Anti-pattern: colpire istintivamente “Convalida correzione” e aggiornare GSC. Durante un picco transitorio (o un’interruzione CDN), spesso la mossa più rapida e corretta è non fare nulla se non confermare il recupero. Google gestisce automaticamente la ripresa.

Playbook per l’incidente: il sito restituisce 502

1. Conferma l’ambito. Controlla un URL coinvolto con Website Down Checker e poi prova più URL con Bulk HTTP Status Code Checker. Se fallisce solo il tuo browser, risolvi il problema locale di rete o DNS prima di aprire un incidente sull’intero sito. Se molti URL pubblici restituiscono 502, continua.
2. Registra la risposta che fallisce. Salva ora, URL, stato, header della risposta ed eventuale request ID della CDN. Se l’errore è intermittente, ripeti la richiesta invece di considerare un retry riuscito come recupero.
3. Identifica il gateway — tratta il branding come un segnale, non come una prova. Leggi header e pagina di errore personalizzata per cercare l’impronta di CDN, reverse proxy o load balancer, ma confermala con la pagina di stato del provider e i tuoi log prima di concludere quale hop abbia fallito; pagine e header brandizzati sono specifici del provider e non dimostrano universalmente la causa. Se il provider segnala un’interruzione, segui il suo percorso dell’incidente; altrimenti continua verso l’origine.
4. Confronta edge e origine. Richiedi normalmente l’hostname pubblico, poi invia lo stesso hostname direttamente all’IP noto dell’origine con curl --resolve. Se l’origine riesce ma l’edge restituisce 502, esamina connettività CDN-origine, TLS e configurazione proxy. Se falliscono entrambi, passa ai log dell’applicazione e dell’origine.
5. Correla i log per timestamp. Una connessione rifiutata o un errore TLS indica il confine gateway/origine; una risposta upstream malformata o chiusa improvvisamente indica il servizio d’origine. Correggi il livello che fallisce, non console di ricerca.
6. Verifica il recupero. Ripeti i controlli pubblico e diretto all’origine su URL rappresentativi. Se le risposte 2xx sono stabili, monitora log e console di ricerca mentre Googlebot riprende automaticamente la scansione. Se i 502 ricompaiono, torna al passaggio 4 con i nuovi timestamp invece di aumentare i retry alla cieca.

Prompt: classifica un gruppo di errori 502 per livello

Incolla un CSV contenente URL, timestamp, stato, header della risposta, risultato pubblico-edge, risultato diretto all’origine e qualsiasi estratto di log corrispondente. Rimuovi prima segreti, cookie, header di autorizzazione e indirizzi privati dell’origine.

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

Aspettati una coda di triage, non un report definitivo della causa principale. Convalida ogni controllo suggerito rispetto agli header e ai log dal vivo.

Riprodurre il 502 pubblico

Esegui questo comando in una shell macOS/Linux. Stampa gli header della risposta senza scaricare il corpo e non segue redirect, così puoi vedere la prima risposta.

curl -sS -D - -o /dev/null https://www.example.com/affected-path

Equivalente PowerShell:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

Se l’applicazione gestisce HEAD in modo diverso, usa un normale GET e scarta il corpo:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

Confrontare il percorso CDN con l’origine nota

Sostituisci 203.0.113.10 con un IP d’origine che controlli. --resolve mantiene l’hostname pubblico per l’header HTTP Host e il nome TLS mentre si connette a quell’IP.

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

Non esporre un’origine protetta e non indebolire il suo firewall solo per eseguire questo test. Eseguilo da una rete già autorizzata. Un 502 pubblico con successo diretto all’origine restringe il problema al percorso CDN/proxy; un fallimento su entrambi i percorsi orienta verso l’origine o l’applicazione.

Strumenti per circoscrivere un 502

• Website Down Checker — conferma se l’URL è raggiungibile da un punto di osservazione Cloudflare esterno e raccoglie tempi, redirect e prove DNS limitate. Risponde alla domanda “succede solo a me?” prima che tu inizi a modificare l’infrastruttura.
• Bulk HTTP Status Code Checker — prova un insieme rappresentativo di URL, mostra tutti i percorsi di redirect e la latenza ed esporta i risultati. Usalo per distinguere un errore su un singolo percorso da un incidente 502 più ampio.
• Dashboard della CDN o del load balancer — abbina request ID e timestamp della risposta che fallisce ai log edge e allo stato del provider.
• Log dell’applicazione e del server d’origine — conferma se l’upstream ha accettato la richiesta e se ha restituito, resettato o malformato la risposta. È ciò che trasforma un’ipotesi sul livello in una causa principale.

Nessuno strumento può identificare il livello che fallisce partendo dal solo 502. Confronta le prove dell’edge pubblico con una richiesta diretta autorizzata all’origine e con log provvisti di timestamp.

Mettiti alla prova: 502 Bad Gateway

Cinque domande rapide su che cos’è un 502 e su come influisce sulla SEO. Scegli una risposta per ciascuna domanda, poi controlla.

Risorse che vale la pena consultare

I miei articoli correlati

• Guida completa ai codici di stato HTTP per la SEO — dove si collocano 502 e il resto della famiglia 5xx e che cosa segnala ogni codice ai motori di ricerca.
• Guida introduttiva alla SEO tecnica — il rapporto tra salute del server, scansione e quadro più ampio.
• Robots.txt e SEO: tutto ciò che devi sapere — utile perché un 5xx sul file robots.txt viene gestito in modo speciale.

Dal settore

• Come i codici di stato HTTP influenzano i crawler di Google (Google Search Central) — la fonte primaria: 502 (bad gateway) è raggruppato con 500/503, con la formulazione esatta su frequenza di scansione e indicizzazione.
• Come gestire l’indisponibilità pianificata del sito (Google Search Central) — la distinzione 503-502 e il motivo per cui 503 è il codice per un’indisponibilità intenzionale.
• Cloudflare Outage Triggers 5xx Spikes: What It Means For SEO (Matt G. Southern, Search Engine Journal) — l’interruzione del novembre 2025 come caso reale, con i commenti di Mueller.
• 502 Bad Gateway: MDN reference (MDN Web Docs) — la definizione neutrale del codice a livello di specifica.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — la specifica sottostante della semantica HTTP.
• Come risolvere un errore 502 Bad Gateway (Kinsta) — una guida approfondita alla diagnosi dal punto di vista dell’host, con correzioni per browser e proprietari del sito.
• 502 Bad Gateway: significato e correzioni per gli sviluppatori web (Webflow) — una panoramica orientata agli sviluppatori su cause e correzioni.

Cronologia modifiche