Se il traffico cresce, Cloudflare non va trattato come un semplice “ON” davanti al sito. La scelta tra regole edge mirate e Origin Shield cambia cache hit ratio, carico sull’origine e comportamento del WAF.
Qui confronto due approcci concreti. Il primo usa Cache Rules + WAF + Rate Limiting in modo chirurgico. Il secondo introduce Origin Shield per ridurre i colpi verso l’origin e stabilizzare la cache su siti con molte edge location.
Scenario tipico: e-commerce, CMS o portale con picchi, login, API e contenuti cacheabili. Il problema non è solo “bloccare gli attacchi”. Il problema vero è evitare che regole sbagliate facciano saltare la cache e trasformino il CDN in un proxy costoso.
Prerequisiti
Prima di toccare Cloudflare, servono dati minimi. Senza numeri, si decide a sensazione.
- Accesso al pannello Cloudflare con permessi su Rules, WAF e Rate Limiting.
- Log dell’origine o accesso a analytics del server web.
- Un elenco chiaro delle URL cacheabili e delle aree dinamiche.
- Header già presenti o configurabili: Cache-Control, CF-Cache-Status, Age.
- Un test client con curl o equivalente.
Note: se il sito usa cookie di sessione ovunque, la cache edge è spesso sprecata. Prima separa pubblico e autenticato.
Step 1: separa contenuti cacheabili e contenuti sensibili
Il primo errore è applicare WAF e rate limit allo stesso modo su tutto. Il secondo è creare una cache che include pagine personali o varianti inutili.
Obiettivo: definire tre gruppi. Pagine pubbliche, aree dinamiche, endpoint sensibili. La logica deve essere visibile nelle regole, non solo nella testa di chi le ha create.
# Esempio di classificazione logica delle URL da usare come base per le regole
/public/*
/blog/*
/api/cart/*
/login
/admin/*
# Output: elenco chiaro delle aree da cacheare, limitare o proteggere con regole più rigide.
Se le pagine pubbliche hanno query string innocue, valuta di ignorarle per la cache solo quando non cambiano il contenuto. Parametri come utm_* o fbclid spesso sporcano la cache senza valore.
Warning: non ignorare a caso le query string su pagine con filtri reali. Un catalogo e-commerce può cambiare molto con ?sort= o ?page=.
Step 2: approccio A — Cache Rules + WAF + Rate Limiting
Questo approccio è il più preciso. Lo scegli quando vuoi governare contenuti, sicurezza e consumo origin separatamente. È ideale per siti con logica applicativa chiara e team che sanno mantenere le regole nel tempo.
La strategia è semplice: cache aggressiva per il pubblico, WAF solo dove serve, rate limit sugli endpoint costosi o abusati.
# Esempio concettuale di policy edge
cache_rules:
- if: http.request.uri.path starts_with "/assets/"
action: cache
edge_ttl: 7d
- if: http.request.uri.path starts_with "/blog/"
action: cache
edge_ttl: 1h
- if: http.request.uri.path eq "/login"
action: bypass_cache
waf:
- if: http.request.uri.path starts_with "/wp-login.php"
action: managed_challenge
rate_limit:
- if: http.request.uri.path eq "/wp-login.php"
threshold: 10 requests per 60s
# Output: asset statici e articoli serviti dalla cache, login protetto, tentativi ripetuti rallentati.
Questo approccio funziona bene quando il collo di bottiglia è l’origine, ma il traffico è eterogeneo. Puoi anche costruire policy diverse per device, paese o percorso. Il vantaggio è il controllo fine.
Il limite è la complessità. Più regole significa più rischio di conflitti. Una regola WAF troppo ampia può colpire anche richieste legittime. Un rate limit troppo stretto può bloccare bot buoni o utenti dietro NAT.
Note: per gli endpoint di ricerca, filtraggio o checkout, spesso conviene bypassare la cache e usare solo protezione e limiti. La latenza lì conta meno della correttezza.
Quando scegliere questo approccio
- Hai molte URL pubbliche ma anche aree dinamiche ben separate.
- Vuoi proteggere login, form e API senza sacrificare cache sulle pagine pubbliche.
- Hai bisogno di cambiare regole spesso, in modo chirurgico.
- Misuri già hit ratio, 4xx/5xx e traffico per path.
Step 3: approccio B — Origin Shield per ridurre pressione sull’origine
Origin Shield non sostituisce le regole edge. Le completa. È utile quando il problema principale è la quantità di richieste che arrivano all’origin da molte zone Cloudflare, anche se il contenuto è già cacheabile.
In pratica, Cloudflare introduce un livello di caching intermedio e concentra verso un punto di shield le richieste cache miss. Così l’origine vede meno variabilità e meno fetch duplicati.
# Test rapido del comportamento cache con curl
curl -sI https://www.example.com/blog/articolo-chiave | grep -Ei 'cf-cache-status|age|cache-control|vary'
# Output: header con CF-Cache-Status, Age e Cache-Control coerenti con la politica attesa.
Origin Shield conviene quando hai:
- traffico globale distribuito su molte regioni;
- contenuti molto richiesti e relativamente stabili;
- origine con CPU o I/O sensibili ai burst;
- tante cache miss simultanee sullo stesso oggetto.
Il beneficio principale è la riduzione dei “thundering herd”. Più richieste uguali arrivano insieme, meno colpi vede il server originario.
Il limite è che Origin Shield non risolve regole sbagliate. Se una pagina non è cacheabile per cookie, header o variazioni dinamiche, lo shield può solo attenuare il danno. Non lo elimina.
Warning: se il tuo problema è un WAF troppo aggressivo o un rate limit mal tarato, Origin Shield non ti salva. Prima correggi la logica di sicurezza.
Quando scegliere Origin Shield
- L’origine è fragile durante i picchi, anche con cache già attiva.
- Hai contenuti caldi richiesti da molte aree geografiche.
- Vuoi ridurre i fetch duplicati verso l’origin.
- Le regole di sicurezza sono già corrette e stabili.
Step 4: confronta i due approcci con tre metriche reali
La scelta giusta non è ideologica. La fai guardando tre numeri.
- Cache hit ratio: quanto traffico viene servito senza toccare l’origine.
- Origin request rate: quante richieste arrivano davvero al server.
- Blocked or challenged requests: quante richieste vengono fermate dal WAF o dal rate limit.
Se il hit ratio è basso per colpa di cookie, headers o bypass errati, serve prima lavorare sulle Cache Rules. Se il hit ratio è buono ma l’origine soffre ancora, Origin Shield ha senso.
Se i blocchi WAF aumentano dopo un cambio, la causa è quasi sempre una regola troppo ampia o una condizione mancante. Non confondere protezione con indisponibilità.
Una lettura pratica:
- Cache Rules + WAF + Rate Limit = migliore per governance fine e sicurezza per percorso.
- Origin Shield = migliore per alleggerire l’origine e stabilizzare la cache globale.
Se hai un sito editoriale, spesso basta il primo approccio. Se hai un portale internazionale con picchi di traffico e origine costosa, il secondo aggiunge valore reale.
Step 5: imposta una verifica semplice con curl e header Cloudflare
Ogni modifica va verificata prima di andare in produzione piena. La prova più utile è ripetibile e leggibile. Bastano pochi header.
curl -sI https://www.example.com/ | grep -Ei 'cf-cache-status|age|server|cache-control|vary'# Output: una riga con CF-Cache-Status e header coerenti con la policy impostata.
Interpretazione rapida:
- CF-Cache-Status: HIT significa risposta servita dalla cache edge.
- CF-Cache-Status: MISS indica primo passaggio o oggetto non ancora cacheato.
- CF-Cache-Status: BYPASS segnala esclusione dalla cache.
- Age mostra da quanto tempo l’oggetto è in cache.
Fai almeno due richieste consecutive sulla stessa URL. Se la seconda resta MISS, la regola non sta funzionando come pensavi.
Verifica finale
La verifica finale deve rispondere a una domanda sola: il sito è più veloce senza diventare meno stabile?
- Le pagine pubbliche mostrano HIT dopo il primo accesso.
- Le aree dinamiche restano BYPASS o protette da challenge, senza cache involontaria.
- Il rate limit colpisce solo il percorso previsto, non tutto il dominio.
- L’origine vede meno richieste duplicate durante i picchi.
- Le metriche di 5xx e timeout non peggiorano dopo le modifiche.
Se hai accesso ai log, controlla anche la distribuzione per path. Un singolo endpoint può consumare una quota sproporzionata di risorse. Lì il rate limit è più utile di un blocco generico.
Note: quando il problema è la cache di HTML dinamico, spesso la soluzione migliore è meno ambiziosa di quanto sembri. Cachea solo ciò che è davvero pubblico. Il resto va protetto, non accelerato a forza.
Troubleshooting
1. Errore: “Error 524: A timeout occurred”
Causa: la richiesta arriva all’origine perché la cache non sta assorbendo il traffico, oppure il WAF allunga troppo il percorso.
Fix:
curl -sI https://www.example.com/pagina-lenta | grep -Ei 'cf-cache-status|cache-control'
# poi verifica la regola di cache per quel path nel pannello Cloudflare# Output: identificazione del bypass o della policy mancante.
2. Errore: “Error 1015: You are being rate limited”
Causa: soglia troppo bassa o regola applicata anche a utenti legittimi dietro IP condivisi.
Fix:
# Alza la soglia o restringi il path della regola nel pannello Cloudflare
# Poi riprova con una sequenza di richieste controllate
for i in $(seq 1 12); do curl -o /dev/null -s -w "%{http_code}\n" https://www.example.com/login; done# Output: codici 200 fino al limite previsto, senza bloccare traffico innocuo.
3. Errore: “cf-cache-status: DYNAMIC” su contenuti che dovrebbero essere cacheati
Causa: header Set-Cookie, Cache-Control: private o una regola che bypassa la cache.
Fix:
curl -sI https://www.example.com/articolo | egrep -i 'set-cookie|cache-control|vary|cf-cache-status'
# poi rimuovi il cookie non necessario o correggi la regola di bypass# Output: header che spiegano perché Cloudflare considera la risposta dinamica.
Conclusione
Se vuoi controllo fine, parti da Cache Rules, WAF e Rate Limiting. Se il problema vero è la pressione sull’origine, aggiungi Origin Shield. Non sono alternative assolute. Spesso si usano insieme, ma con priorità diverse.
Il prossimo passo concreto è testare una sola URL pubblica, una sola URL dinamica e un endpoint sensibile. Misura hit ratio, 5xx e richieste all’origine prima e dopo. Lì capisci davvero quale approccio ti conviene.
Regola pratica: prima riduci gli errori di policy, poi riduci i colpi all’origine. Invertire l’ordine fa perdere tempo e metriche.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.