Errore Cloudflare 520: cosa significa e come risolverlo

Cosa significa l'errore 520

Cloudflare si posiziona tra il visitatore e il tuo web server come reverse proxy. Per una richiesta normale apre una connessione TCP verso la tua origine, invia la richiesta, e inoltra qualunque risposta HTTP torni indietro. L'errore 520 scatta quando quest'ultimo passaggio fallisce: la connessione TCP riesce, ma i byte che seguono non vengono interpretati come una risposta HTTP valida, oppure non arriva alcun byte prima che la connessione si chiuda.

Questo colloca il 520 in una categoria diversa dagli altri codici 5xx di Cloudflare. L'errore 521 significa che l'origine ha rifiutato la connessione del tutto. L'errore 522 significa che il tentativo di connessione è andato in timeout. L'errore 520 significa che l'origine ha detto qualcosa, e Cloudflare non è riuscita a darle senso o a inoltrarla.

Come appare l'errore 520

Nel browser, Cloudflare mostra la propria pagina di errore, "Error 520: web server returned an unknown error", insieme a un Ray ID che ti servirà se contatti il supporto Cloudflare. Una semplice richiesta curl contro il dominio mostra lo stesso codice di stato:

curl -I https://example.com
HTTP/2 520

Sul lato Cloudflare, le schede Security o Analytics della dashboard mostrano un picco di risposte 5xx, e gli account Enterprise con accesso a Logpull o Logpush possono estrarre il colo edge specifico e il Ray ID per ogni richiesta fallita. Nulla di tutto ciò ti dice però cosa ha effettivamente inviato l'origine, quindi il prossimo posto dove guardare è il tuo stesso server.

Sull'origine, controlla i log del web server e dell'applicazione allo stesso timestamp dei fallimenti. Cerca un riavvio del processo, un segmentation fault, un kill per esaurimento di memoria nel log di sistema (dmesg o journalctl -k), o un errore dell'applicazione che ha interrotto la richiesta a metà risposta. Se i log dell'app non mostrano nulla di insolito, il problema è più probabilmente una risposta che tecnicamente si è completata ma ha violato una regola HTTP, come un header sovradimensionato.

Cosa causa l'errore 520

• Il processo dell'origine è andato in crash o si è riavviato mentre gestiva la richiesta. La connessione si chiude prima che una risposta completa venga inviata. Questa è la causa più comune.
• L'origine ha resettato la connessione TCP (RST) invece di chiuderla in modo pulito. I server applicativi sotto pressione di memoria o che raggiungono un timeout del worker spesso lo fanno.
• Header di risposta oltre il limite di 16 KB di Cloudflare. Un grande header set-cookie, una pila di header di debug, o header CORS prolissi possono spingere il totale oltre quanto Cloudflare accetta.
• Un cookie o un header cookie combinato troppo grande. Dati di sessione, cookie di tracciamento, o un cookie jar mal configurato possono crescere oltre i limiti di browser e proxy nel tempo.
• Una status line mancante o malformata. Alcuni framework restituiscono una stringa di errore grezza invece di una risposta HTTP corretta quando un'eccezione non gestita raggiunge il livello del web server.
• L'origine ha restituito dati non HTTP sulla porta HTTP(S). Questo succede dopo un reverse proxy mal configurato, un mapping di porta sbagliato, o un servizio che occupa la porta prima che lo faccia il vero web server.
• Un'appliance di sicurezza o un WAF davanti all'origine ha interrotto la connessione a metà risposta. Alcuni WAF e load balancer on-premise terminano le connessioni che fanno scattare una regola, il che appare identico a un crash dal lato di Cloudflare.

Come capire di chi è la colpa

Dato che Cloudflare ha effettivamente ricevuto una risposta dall'origine, l'errore 520 è un forte segnale che il problema sia dal lato dell'origine piuttosto che nella rete di Cloudflare, a differenza dell'errore 521 o 522 dove la connessione stessa è fallita. La domanda aperta è di solito se colpisce ogni visitatore o solo alcuni.

Il modo più veloce per capirlo è eseguire un controllo HTTP da più postazioni contemporaneamente. Se un controllo contro il dominio pubblico fallisce da ogni postazione nello stesso momento in cui gli utenti segnalano l'errore, l'origine stessa è giù o in crash per tutti, non solo per un data center edge. Se fallisce solo in modo intermittente o da regioni specifiche, l'origine potrebbe essere sovraccarica sotto il carico di quella regione, oppure è coinvolto un livello di caching o load-balancing presente solo in parte della tua configurazione. Il controllo HTTP di HostTracker viene eseguito da punti di controllo in più paesi e riporta il risultato di ciascuno separatamente, un dettaglio che un singolo curl dalla tua scrivania non può darti.

Puoi anche isolare l'origine da Cloudflare del tutto contattandola direttamente con l'header Host del dominio, bypassando la rete edge in modo che qualunque errore tu veda sia indubbiamente dell'origine:

curl -v -H "Host: example.com" https://ORIGIN_IP/

Sostituisci ORIGIN_IP con l'indirizzo IP reale del tuo server. Se anche questa richiesta diretta fallisce o restituisce la stessa risposta rotta, il difetto è confermato all'origine.

Come correggere l'errore 520

Se sei un visitatore

1. Ricarica la pagina dopo un minuto o due. Molti errori 520 derivano da un crash o riavvio breve da cui il process supervisor del sito si riprende automaticamente.
2. Prova una finestra privata o in incognito, o una rete diversa. Questo esclude una cache locale obsoleta o un'estensione del browser che si comporta male, anche se un 520 raramente è causato da qualcosa dal tuo lato.
3. Controlla se il sito pubblica una propria pagina di stato, se ne ha una, per un'interruzione nota.
4. Non c'è nulla da configurare dal tuo lato per correggere un 520. Viene generato dal server stesso del sito, non dal tuo browser, dal tuo ISP, o dal tuo resolver DNS.

Se gestisci il sito

1. Controlla i log del web server e dell'applicazione dell'origine per il timestamp esatto dei fallimenti, cercando un crash, un'eccezione non gestita, o un riavvio del worker.
2. Bypassa Cloudflare e interroga l'origine direttamente con l'header Host (mostrato sopra), oppure usa l'opzione "Pause Cloudflare on Site" di Cloudflare, per confermare che la risposta è rotta indipendentemente dal proxy.
3. Misura la dimensione dei tuoi header di risposta e cookie. Un singolo grande header set-cookie o una pila di header di debug lasciati attivi in produzione possono spingere il totale oltre i 16 KB; elimina ciò che non ti serve e sposta i dati di sessione grandi lato server.
4. Controlla la presenza di risposte malformate: un reverse proxy o load balancer puntato all'upstream sbagliato, un'app che restituisce testo semplice su una porta HTTP, o una status line mancante dal gestore di errori predefinito di un framework.
5. Controlla l'esaurimento delle risorse sull'origine: limiti di memoria, limiti del pool di connessioni, o un process manager (systemd, pm2, un pool di worker Gunicorn o uWSGI) bloccato in un loop di riavvio.
6. Se un WAF, un proxy antivirus, o un load balancer si trova tra internet e il tuo server applicativo, controlla i suoi stessi log per connessioni che ha interrotto o resettato nello stesso periodo.

Come prevenirlo

L'errore 520 di solito emerge prima come ticket di supporto, non come avviso, perché nulla all'origine necessariamente registra un handshake fallito con l'edge di Cloudflare nel modo in cui registra un'eccezione applicativa. Un controllo di disponibilità esterno che gira fuori dalla tua rete cattura lo stesso fallimento che vede un visitatore, dallo stesso punto di vista, prima che qualcuno debba segnalarlo. Eseguire il controllo da più paesi mostra anche immediatamente se un 520 è globale o limitato a una regione, il dettaglio che decide da dove iniziare il debug.

Errori correlati

• Errore Cloudflare 521: il web server è giù - l'origine ha rifiutato la connessione invece di rispondere.
• Errore Cloudflare 522: connessione andata in timeout - l'handshake TCP verso l'origine non si è mai completato.
• Errori server 5xx - la famiglia generale di codici di stato.
• 502 Bad Gateway - la versione non specifica di Cloudflare di una risposta upstream non valida.

Domande frequenti

L'errore 520 è colpa di Cloudflare o mia?

Quasi sempre dell'origine. Cloudflare ha ricevuto una risposta e non è riuscita a darle senso o a inoltrarla, il che significa che è stato il server di origine, non la rete di Cloudflare, a produrre la risposta rotta.

L'errore 520 significa che il mio intero sito è giù?

Non necessariamente. Significa che la specifica richiesta che lo ha innescato è fallita. Se l'origine sta andando in crash sotto carico, potrebbe servire 520 ad alcune richieste e risposte normali ad altre finché il problema di fondo non viene corretto.

Posso correggere l'errore 520 solo dalla dashboard di Cloudflare?

Raramente. Dato che la causa è quasi sempre all'origine, le impostazioni della dashboard non correggeranno un'applicazione in crash o un header di risposta sovradimensionato. L'eccezione è verificare che la tua modalità SSL/TLS e le impostazioni dell'origine corrispondano a ciò che il tuo server fa realmente, il che almeno esclude una configurazione errata lato Cloudflare.

Qual è la differenza tra l'errore 520 e un semplice 502 Bad Gateway?

502 è lo stato HTTP generale per una risposta non valida da un server upstream, usato da qualunque reverse proxy. Cloudflare usa il 520 specificamente come propria categoria residua per una risposta così rotta da non rientrare in nessuno degli altri codici 5xx con nome di Cloudflare, ed è per questo che compaiono la pagina di errore Cloudflare e il Ray ID invece di una pagina 502 generica.

Un cookie grande può davvero causare un 520?

Sì. Cloudflare impone un limite sulla dimensione totale degli header di risposta, attualmente intorno ai 16 KB, e i cookie contano ai fini di quel limite. Un'applicazione che continua ad aggiungere dati a un cookie di sessione, o che imposta più cookie grandi contemporaneamente, può superare quel limite e innescare un 520 anche quando l'applicazione stessa non ha alcun bug.

Riprovare la richiesta lo risolverà?

A volte, se la causa era un crash o un riavvio transitorio all'origine da cui si è già ripresa. Se l'origine sta inviando costantemente risposte rotte, per esempio a causa di un header sovradimensionato su ogni richiesta, riprovare non aiuterà finché l'origine non viene corretta.