Errore Cloudflare 522: connessione in timeout - cause e soluzioni

Cosa significa l'errore 522

Ogni richiesta gestita in proxy inizia con Cloudflare che apre una connessione TCP verso la tua origine prima ancora di poter inviare la richiesta HTTP stessa. L'errore 522 scatta quando quell'handshake, il SYN TCP e l'atteso SYN-ACK di ritorno, non si completa entro la finestra di timeout di Cloudflare. L'origine potrebbe essere troppo sovraccarica per accettare nuove connessioni, un firewall potrebbe scartare silenziosamente i pacchetti invece di rifiutarli, o il percorso di rete tra Cloudflare e l'origine potrebbe essere congestionato.

Questo è diverso dall'errore 521, dove l'origine rifiuta attivamente la connessione, e dall'errore 524, dove la connessione TCP riesce ma la risposta HTTP stessa non arriva mai in tempo. L'errore 522 è specificamente un fallimento nella fase di handshake, prima ancora che venga inviata qualunque richiesta HTTP.

Come appare l'errore 522

I visitatori vedono la pagina di Cloudflare, "Error 522: connection timed out", con un Ray ID. Una richiesta curl contro il dominio mostra lo stesso stato dopo circa la finestra di timeout di Cloudflare:

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

Poiché l'handshake TCP non si è mai concluso, nessuna richiesta ha raggiunto la tua applicazione, quindi i log applicativi sono tipicamente vuoti per il periodo del fallimento. Guarda invece le metriche a livello di connessione: il carico del server e la CPU al momento degli errori, il numero di connessioni stabilite e in attesa (ss -s o netstat -an | grep SYN_RECV), e i log del firewall o del load balancer per pacchetti scartati o filtrati sulla porta rilevante.

Cosa causa l'errore 522

• Il server di origine è sovraccarico e non riesce ad accettare nuove connessioni abbastanza velocemente. CPU alta, una coda di connessioni in attesa piena, o un pool di worker esaurito producono tutti questo effetto.
• Un firewall o un security group sta scartando silenziosamente i pacchetti SYN di Cloudflare invece di inviare un reset TCP. Uno scarto appare identico a un server lento o morto dal lato di Cloudflare, mentre un reset produrrebbe invece l'errore 521.
• Il TCP keepalive è disattivato sull'origine, il che aumenta il ricambio di connessioni e le probabilità che un nuovo handshake arrivi in un momento in cui il server è troppo occupato per accettarlo.
• L'indirizzo IP dell'origine non è correttamente in allowlist dove la rete richiede una allowlist esplicita invece di una semplice regola firewall, quindi le richieste di Cloudflare vengono filtrate prima di raggiungere il socket in ascolto.
• Congestione di rete o perdita di pacchetti tra Cloudflare e l'origine, più comune su origini dietro hosting di livello consumer o pesantemente in overselling.

522 contro 524

Entrambi i codici sono timeout, ma avvengono in punti diversi della richiesta. L'errore 522 avviene prima che venga inviata qualunque richiesta HTTP: l'handshake TCP stesso non si completa mai. L'errore 524 avviene dopo: la connessione TCP riesce e Cloudflare invia la richiesta HTTP, ma l'origine non rimanda indietro una risposta completa entro 100 secondi. Un 524 di solito indica un'applicazione lenta, per esempio un endpoint di generazione report, una query di database lunga, o una richiesta innescata da cron che legittimamente impiega minuti. La correzione per un 524 è quasi sempre velocizzare l'endpoint o spostare il lavoro lento fuori dal ciclo richiesta-risposta in un job in background di cui il client interroga periodicamente il risultato; i piani Cloudflare Enterprise possono anche alzare il limite di 100 secondi per rotte specifiche, ma questo tratta il sintomo piuttosto che l'endpoint lento stesso.

Come capire di chi è la colpa

Un 522 quasi sempre ha origine all'origine stessa o nei suoi pressi, dato che la rete di Cloudflare è altamente disponibile e raramente è la fonte di un timeout di handshake. La domanda utile è se l'origine sia del tutto giù o semplicemente in difficoltà sotto il carico da certe regioni. Il modo più veloce per verificarlo è eseguire un controllo HTTP da più postazioni contemporaneamente: il controllo HTTP di HostTracker interroga il dominio da punti di controllo in più paesi e riporta ciascuno separatamente, quindi un pattern in cui alcune postazioni vanno in timeout e altre riescono indica un server sovraccarico che gestisce alcune richieste ma non tutte, mentre un timeout uniforme ovunque indica che l'origine è completamente giù o che un firewall scarta ogni connessione.

Come correggere l'errore 522

Se sei un visitatore

1. Ricarica dopo una breve attesa. Un picco momentaneo di carico o un piccolo intoppo di rete spesso si risolve da solo.
2. Controlla la pagina di stato del sito, se ne ha una, per un incidente noto.
3. Non c'è nulla da correggere dal tuo lato. Il timeout avviene tra Cloudflare e il server stesso del sito, non nel tuo browser o nella tua connessione a Cloudflare.

Se gestisci il sito

1. Controlla il carico del server e la capacità di connessione disponibile al momento dei fallimenti: CPU, memoria, e i limiti di connessione o worker configurati del web server (per esempio il worker_connections di nginx).
2. Conferma che il tuo firewall o security group permetta gli intervalli IP pubblicati di Cloudflare sulla porta rilevante, e che rifiuti con un reset invece di scartare silenziosamente i pacchetti, il che almeno trasforma un 522 in un 521 più facile da diagnosticare.
3. Attiva il TCP keepalive sul web server dell'origine e su ogni load balancer davanti a esso, e controlla che le impostazioni keepalive a livello di sistema operativo non siano rimaste ai valori predefiniti, molto più lunghi di quanto la connessione richieda davvero.
4. Se il tuo hosting o la tua rete cloud richiede una allowlist IP esplicita separata dal firewall, conferma che l'IP dell'origine ci sia.
5. Cronometra l'handshake grezzo direttamente contro l'origine, bypassando Cloudflare, per vedere se il ritardo sta nel raggiungere il tuo server affatto:

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

   Una connessione che si blocca qui conferma che l'origine stessa è lenta ad accettare connessioni, non qualcosa di specifico a Cloudflare.
6. Per singoli endpoint lenti piuttosto che un server generalmente sovraccarico, sposta il lavoro di lunga durata (report, esportazioni, job batch) fuori dal percorso della richiesta e in un job in background che il client interroga periodicamente o su cui riceve una notifica, e considera un aumento del timeout Cloudflare Enterprise solo come soluzione tampone per rotte che non puoi velocizzare rapidamente.

Come prevenirlo

Un server che fallisce l'handshake solo sotto il carico di picco supererà ogni controllo manuale che esegui tu stesso, dato che è improbabile che tu lo testi esattamente nel momento in cui è in difficoltà. Un controllo HTTP pianificato che gira fuori dalla tua rete cattura quella finestra di fallimento anche quando nessuno sta guardando, ed eseguirlo da più paesi mostra se il rallentamento è una capacità globale o un percorso di rete regionale.

Errori correlati

• Errore Cloudflare 520: errore sconosciuto - l'origine ha risposto, ma la risposta era inutilizzabile.
• Errore Cloudflare 521: web server giù - l'origine ha rifiutato la connessione invece di non rispondere.
• Errori server 5xx - la famiglia generale di codici di stato.
• 502 Bad Gateway - la versione non specifica di Cloudflare di un fallimento upstream.

Domande frequenti

Quanto aspetta Cloudflare prima di mostrare l'errore 522?

Circa 15 secondi per l'handshake TCP. Se l'origine non ha accettato la connessione entro quel momento, Cloudflare rinuncia e restituisce 522 al visitatore.

Il 522 è la stessa cosa del mio server giù?

Non sempre. Può anche significare che il server è acceso ma troppo occupato per accettare una nuova connessione in tempo, o che un firewall sta scartando il tentativo di connessione senza inviare un reset.

Perché un firewall scarta invece di rifiutare una connessione?

Alcune configurazioni predefinite di firewall o security group scartano silenziosamente i pacchetti che non corrispondono a una regola di permesso invece di inviare un reset TCP. Quello scarto silenzioso è ciò che trasforma quello che potrebbe essere un 521 veloce e chiaro in un 522 più lento e ambiguo.

Il 522 significa che devo aggiornare il mio server?

Non necessariamente. Prima di scalare, controlla se il keepalive è disattivato, se il firewall scarta silenziosamente gli intervalli di Cloudflare, e se i limiti di connessione nella configurazione del web server sono impostati più bassi di quanto il traffico effettivamente richieda.

Qual è la differenza tra 522 e 524?

522 è un fallimento nel completare del tutto l'handshake TCP. 524 è una connessione completata in cui la risposta HTTP stessa impiega troppo tempo, di solito a causa di logica applicativa lenta piuttosto che un problema di rete o capacità.

Una singola query di database lenta può causare un 522?

Non direttamente, dato che il 522 avviene prima che venga inviata qualunque richiesta. Una query lenta è più probabile che produca un 524, dove la connessione è riuscita ma la risposta ha impiegato troppo tempo ad arrivare.