1,964 24/03/2026 07/04/2026 8 min

Il guasto tipico arriva così: il sito risponde da una parte, ma alcuni utenti vedono 524 A timeout occurred o una pagina challenge infinita.

La tentazione è disattivare tutto Cloudflare. È una cattiva idea se non sai cosa ha cambiato davvero il comportamento.

In questo articolo usiamo uno scenario concreto: una nuova regola WAF, una cache rule troppo aggressiva e un rate limit che colpisce anche il checkout. L’obiettivo è diagnosticare in fretta, fare rollback pulito e ripristinare il traffico senza perdere il controllo sull’origine.

Warning: se l’origine è già sotto stress, ogni test ripetuto può peggiorare il timeout. Prima osserva, poi modifica.

Prerequisiti

  • Accesso al pannello Cloudflare con permessi su WAF, Cache, Rules e Rate Limiting.
  • Accesso SSH o console all’origin server.
  • Un dominio già proxyato da Cloudflare.
  • Un endpoint diagnostico stabile, per esempio /healthz o /status.
  • Strumenti locali: curl, dig, jq opzionale, e un editor per annotare i cambi.

Note: se non hai un endpoint health separato, crealo prima del resto. Ti serve per distinguere “problema CDN” da “problema applicativo”.

Step numerati

1) Conferma il sintomo e raccogli l’intestazione Cloudflare

Prima di cambiare regole, verifica se il problema è un timeout verso l’origine, un blocco WAF o un match di rate limit. L’header cf-ray ti dice che la risposta è passata da Cloudflare. Il codice 524 indica che Cloudflare ha contattato l’origine ma ha atteso troppo.

curl -svI https://www.example.com/checkout 2>&1 | sed -n '1,25p'

# Output:

HTTP/2 524
server: cloudflare
cf-ray: 8f1c2d3ab9e0f8c1-FRA
content-type: text/html; charset=UTF-8

Se invece vedi 403 con pagine challenge o blocco, il problema è più probabilmente WAF o firewall rule. Se vedi 429, controlla rate limit o un upstream che emette già quel codice.

2) Isola la cache: bypass temporaneo su URL sensibili

Una cache rule sbagliata può servire HTML vecchio, includere cookie o congelare una pagina di errore. Il checkout, il carrello e l’area login non dovrebbero quasi mai passare da una cache aggressiva. Qui l’obiettivo non è “svuotare tutto”, ma ridurre il raggio d’azione.

# Esempio logico di regola cache
if http.request.uri.path contains "/checkout" then bypass cache
if http.request.uri.path contains "/cart" then bypass cache
if http.request.uri.path contains "/wp-admin" then bypass cache

# Output:

Cache status: BYPASS
Edge response: origin generated
CF-Cache-Status: DYNAMIC

Se dopo il bypass il sito torna a rispondere, il problema è nella policy cache. Se resta lento o bloccato, la causa è altrove. Non confondere un edge veloce con un origin sano.

3) Controlla WAF e Managed Rules con un tag di evento

Le Managed Rules di Cloudflare sono utili, ma un falso positivo può colpire un parametro innocuo, un token CSRF o un JSON valido. Il punto non è disattivare tutto il WAF. Serve individuare la regola specifica e il relativo evento.

Apri il Security Events e filtra per path, IP o cf-ray. Cerca il nome della regola, il rule ID e l’azione eseguita. Se hai attivato un nuovo pacchetto di regole, sospendilo solo per il dominio interessato.

# Esempio di controllo lato origin per correlare gli orari
journalctl -u php-fpm --since "10 min ago" | tail -n 40

# Output:

[warning] request timed out while reading response header from upstream
[notice] slow request: /checkout took 18.4s

Qui il WAF non è la causa primaria. Ha solo reso visibile un collo di bottiglia già presente. Se invece l’evento mostra un blocco su un parametro preciso, crea una regola di eccezione minima, non un bypass globale.

4) Verifica rate limit e burst reale

Un rate limit troppo stretto colpisce crawler, API client, app mobile e persino utenti reali dietro NAT. Il sintomo tipico è una sequenza di 429 su richieste ravvicinate, spesso dopo login o durante il checkout.

Non ragionare solo in “richieste al minuto”. Conta anche burst, finestra e chiave di matching. Una regola che limita per IP può penalizzare interi uffici o reti mobili condivise.

# Concetto di controllo: soglia troppo bassa per un endpoint critico
path: /api/checkout
threshold: 30 requests / 60s
action: block

# Output:

429 Too Many Requests
Retry-After: 60

Se il flusso legittimo supera quella soglia, alza il limite o cambia la chiave, per esempio da IP a sessione o token applicativo. Nei casi critici, metti il rate limit solo su endpoint ad alto rischio, non su tutto il dominio.

5) Usa Origin Shield per proteggere l’origine, ma non per nascondere il danno

Origin Shield aiuta a concentrare i miss verso un unico punto intermedio. È utile quando hai molti POP che richiamano lo stesso contenuto. È meno utile se l’origine è già lenta o se una cache rule errata impedisce il refresh corretto.

Se l’origine va in timeout, Origin Shield può ridurre il carico. Non risolve query lente, lock applicativi o pool PHP-FPM saturi. Prima verifica il tempo di risposta dell’origine da una fonte controllata.

curl -sS -o /dev/null -w 'time_starttransfer=%{time_starttransfer}
time_total=%{time_total}
' https://origin.example.internal/healthz

# Output:

time_starttransfer=0.042
time_total=0.043

Se l’health risponde in pochi millisecondi ma il sito pubblico va in 524, il problema è quasi sempre cache, WAF o origin path specifico. Se anche l’health è lento, fermati e lavora sull’origine prima di toccare Cloudflare.

6) Esegui rollback mirato, non globale

Il rollback migliore è quello che annulla solo il cambiamento difettoso. Se hai introdotto una nuova cache rule, disattiva solo quella. Se hai aggiunto una regola WAF, mettila in log mode o bypass sul path interessato. Se il rate limit è stato alzato troppo, ripristina il valore precedente.

Un rollback globale del proxy può esporre l’origin a traffico non filtrato proprio durante l’incidente. Inoltre rompe la cache e rende più difficile capire quale modifica ha funzionato.

# Esempio operativo: annota prima e dopo
printf '%s
' 'cache_rule_checkout=disabled' 'waf_rule_981176=log' 'rate_limit_api=restore_60rpm' > /root/cloudflare-rollback.txt

# Output:

rollback plan saved

Note: se usi API e IaC, preferisci un commit di rollback con change note. I cambi manuali nel pannello vanno persi facilmente durante l’urgenza.

7) Pulisci la cache solo dove serve

Dopo aver corretto una regola, non sempre basta aspettare il TTL. Se una pagina errata è già stata memorizzata, serve un purge selettivo. Evita il purge totale se il sito ha molte risorse statiche e un traffico alto.

Pulisci solo gli URL colpiti, oppure usa il purge per tag se hai una strategia di cache tagging. Questo riduce il ritorno di carico sull’origine e conserva il resto del sito in edge cache.

# Esempio concettuale: purge selettivo per URL critici
printf '%s
' 'https://www.example.com/' 'https://www.example.com/checkout' > purge-list.txt

# Output:

2 URLs queued for purge

Se la home era contaminata da una pagina di errore, il purge selettivo è spesso sufficiente. Se il problema nasce da header cache errati, correggi prima la logica, poi svuota i contenuti coinvolti.

Verifica finale

La verifica deve essere breve e ripetibile. Controlla tre cose: risposta edge, risposta origin e assenza di eventi recenti nel WAF o nel rate limit.

  • Edge: curl -I restituisce 200 o 301 coerente con il sito.
  • Cache: il path pubblico mostra CF-Cache-Status atteso, mentre i path dinamici restano BYPASS o DYNAMIC.
  • Security: il Security Events non registra blocchi sulla richiesta di test.
  • Origin: i log applicativi non mostrano timeout, lock o picchi anomali.
curl -sSI https://www.example.com/ | egrep -i 'HTTP/|cf-cache-status|cf-ray|age'

# Output:

HTTP/2 200
cf-cache-status: HIT
cf-ray: 8f1c2d3ab9e0f8c1-FRA
age: 124

Se il sito torna stabile ma la cache non si comporta come previsto, lascia una nota operativa. Serve per capire se il problema è chiuso o solo mascherato.

Troubleshooting

Errore 1: 524 A timeout occurred

Causa: l’origine non risponde abbastanza in fretta su un path specifico, spesso per query lente o pool PHP saturo.

Fix:

curl -sS -o /dev/null -w '%{time_total}
' https://origin.example.internal/checkout
journalctl -u php-fpm --since "15 min ago" | tail -n 50

Se il path è lento solo dietro Cloudflare, controlla anche regole cache e header forwarding.

Errore 2: 1015 You are being rate limited

Causa: la soglia di rate limit è troppo bassa per il traffico reale o per un burst legittimo.

Fix:

# Riduci il perimetro della regola o alza la soglia
printf '%s
' 'target=/api/login' 'threshold=90/60s' 'mode=challenge'

Se il traffico arriva da rete condivisa, cambia la chiave della regola o escludi l’endpoint meno sensibile.

Errore 3: 403 Forbidden con challenge Cloudflare

Causa: una Managed Rule o una firewall rule sta bloccando un parametro, un user-agent o un pattern del body.

Fix:

# Correlazione rapida tra evento e request-id
curl -sSI https://www.example.com/checkout | grep -i cf-ray

Poi apri i Security Events, trova il rule ID e mettilo in log mode solo per quel path. Evita eccezioni ampie su tutto il dominio.

Conclusione

Cloudflare non va trattato come una scatola nera. Cache, WAF, rate limit e Origin Shield sono strumenti diversi. Quando qualcosa si rompe, devi capire quale strato ha cambiato il comportamento.

Il passo concreto dopo questo articolo è semplice: prepara una checklist di rollback con tre voci fisse, cioè regola coinvolta, path impattato e comando di verifica. La prossima volta il ripristino sarà più veloce e molto meno rumoroso.