1,201 26/03/2026 07/04/2026 5 min

Obiettivo

Quando un sito dietro Cloudflare inizia a consumare troppe risorse sull’origine, le strade più comuni sono due: spingere di più sulla cache oppure ridurre le richieste verso l’origine con un origin shield. Sembrano soluzioni simili, ma risolvono problemi diversi. Scegliere bene evita di complicare le regole e di mascherare un collo di bottiglia che andrebbe corretto in altro modo.

Diagnosi probabile

Se vedi picchi di CPU, query lente o molte richieste all’origin nonostante Cloudflare sia attivo, spesso il problema non è “Cloudflare che non funziona”, ma una di queste situazioni:

  • la cache non sta colpendo abbastanza, perché il contenuto è dinamico o i cookie invalidano la memorizzazione;
  • il traffico arriva da molte PoP diverse e ogni edge deve rifare il fetch all’origine;
  • il WAF o il rate limit bloccano parte degli attacchi, ma non riducono il numero di hit legittime verso il server;
  • le regole sono troppo generiche e finiscono per bypassare la cache su pagine che potrebbero essere servite più a lungo.

In pratica: cache rules agiscono sul comportamento di memorizzazione dei contenuti, mentre origin shield serve a concentrare gli accessi all’origine in un punto più controllato, riducendo i fetch duplicati.

Verifiche immediate

  1. Apri Cloudflare Dashboard e controlla Analytics > Cache: se l’hit ratio è basso, il primo sospetto è la cache, non il firewall.
  2. Verifica in Security > Events se il WAF o i Rate Limiting stanno già intercettando traffico anomalo: esito atteso, eventi visibili ma senza bloccare utenti reali.
  3. Controlla i log dell’origine: se vedi molte richieste uguali da IP diversi o header `cf-cache-status` spesso su `MISS`, il problema è la dispersione dei fetch o una cache poco efficace.

Soluzione consigliata passo-passo

Approccio 1: ottimizzare le cache rules quando il sito ha molte pagine statiche o semi-statiche, e il problema principale è il carico sull’origine dovuto a contenuti che potrebbero essere cached più a lungo.

  1. Vai in Rules > Cache Rules e crea una regola per estendere la durata della cache solo su URL sicure, ad esempio asset, pagine pubbliche o contenuti che cambiano raramente.
  2. Usa condizioni precise, come percorso, estensione o header, invece di regole globali. Esito atteso: aumento del cache hit senza servire contenuti errati.
  3. Se il sito usa cookie per area privata o carrello, escludi esplicitamente quelle sezioni dalla cache. Scopo: evitare problemi con login, checkout o pagine personalizzate.
  4. Verifica dopo il cambio il valore di `cf-cache-status`: l’esito desiderato è `HIT` o almeno `REVALIDATED` sulle risorse previste.

Approccio 2: attivare un origin shield quando la cache edge esiste già, ma l’origine continua a ricevere troppe richieste duplicate da PoP diverse o quando hai un backend fragile e vuoi ridurre i fetch diretti.

  1. Configura un punto di origine centrale coerente con la tua architettura, cioè il nodo che farà da “collante” tra Cloudflare e il server applicativo.
  2. Attiva l’origin shield solo se hai una distribuzione del traffico ampia o un origin che soffre molto i burst. Esito atteso: meno richieste ripetute verso il backend, soprattutto in caso di cache expiration simultanee.
  3. Non usare l’origin shield come sostituto di una cache mal progettata: se ogni pagina è `MISS`, il shield riduce il rumore ma non elimina il problema.
  4. Controlla lato server che il numero di connessioni e le richieste per secondo calino rispetto alla situazione precedente.

Quando scegliere l’uno o l’altro

  • Scegli le cache rules se il sito ha contenuti pubblici, ripetitivi e vuoi ridurre il TTFB e il carico applicativo.
  • Scegli l’origin shield se la cache edge è già buona ma l’origine continua a ricevere troppe richieste per la stessa risorsa da aree geografiche diverse.
  • Usali insieme se hai un e-commerce o un sito editoriale con molte pagine cacheabili e un backend sensibile ai picchi.

Dove entrano WAF e rate limit

WAF e rate limit non sono alternative alla cache: sono barriere di sicurezza e controllo traffico. Il WAF è utile per filtrare pattern malevoli, il rate limit per contenere abusi o scraping aggressivo. Se il problema è il carico legittimo su contenuti pubblici, la priorità resta la cache. Se invece il traffico è sospetto o concentrato su endpoint costosi, il WAF e il rate limit vanno attivati prima di pensare a regole più aggressive sulla cache.

Controlli finali / rollback

  1. Riesamina dopo 24 ore: hit ratio, errori 5xx, tempi di risposta e carico CPU dell’origine. Condizione di successo: meno richieste al backend senza aumento di errori o contenuti obsoleti.
  2. Se una cache rule causa problemi visivi o dati stantii, disattivala subito e torna alla configurazione precedente; è il rollback più rapido e sicuro.
  3. Se l’origin shield non porta benefici misurabili, rimuovilo e concentra il lavoro sulla cache o sulla riduzione delle richieste dinamiche.
Regola pratica: se il sito è lento perché serve troppo spesso gli stessi contenuti, lavora sulla cache; se la cache funziona ma l’origine resta sotto stress, aggiungi un origin shield.

Assunzione: il sito è già dietro Cloudflare con DNS proxy attivo e hai accesso al pannello per modificare regole e analitiche.