{"id":747,"date":"2026-02-27T09:00:00","date_gmt":"2026-02-27T08:00:00","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/configurare-cloudflare-cdn-sito-web\/"},"modified":"2026-02-18T18:04:18","modified_gmt":"2026-02-18T17:04:18","slug":"configurare-cloudflare-cdn-sito-web","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/configurare-cloudflare-cdn-sito-web\/","title":{"rendered":"Configurare Cloudflare come CDN per il Tuo Sito Senza Errori: La Mia Guida"},"content":{"rendered":"<p>Cloudflare \u00e8 uno degli strumenti pi\u00f9 potenti e accessibili per migliorare le prestazioni e la sicurezza di un sito web. Funziona come <strong>CDN (Content Delivery Network)<\/strong>, reverse proxy e firewall applicativo, tutto in uno. Il piano gratuito \u00e8 gi\u00e0 sorprendentemente completo e sufficiente per la maggior parte dei siti. Eppure, nonostante la sua popolarit\u00e0, vedo continuamente siti configurati male: redirect loop infiniti, errori 521 e 522, contenuti misti HTTP\/HTTPS, cache che non funziona o che memorizza pagine che non dovrebbe. Sono Dario Iannascoli, e in questa guida ti mostro come configuro Cloudflare correttamente sui siti dei miei clienti, evitando tutti gli errori comuni che possono trasformare un miglioramento in un disastro.<\/p>\n<p>Ho configurato Cloudflare su centinaia di siti nel corso degli anni: blog personali, e-commerce WooCommerce, portali aziendali, applicazioni web personalizzate. Ogni tipo di sito ha le sue esigenze specifiche, ma la procedura di base e gli errori da evitare sono sempre gli stessi. La cosa che ripeto sempre ai miei clienti \u00e8 che <strong>Cloudflare non \u00e8 un sistema &#8220;installa e dimentica&#8221;<\/strong>. Una configurazione sbagliata pu\u00f2 peggiorare le prestazioni invece di migliorarle, o addirittura rendere il sito irraggiungibile. La buona notizia \u00e8 che, seguendo i passaggi corretti nell&#8217;ordine giusto, la configurazione \u00e8 relativamente semplice e i benefici sono immediati: tempi di caricamento ridotti, protezione DDoS, certificato SSL gratuito e risparmio di banda sul server di origine. Vediamo come fare, passo dopo passo, partendo dalla creazione dell&#8217;account fino alla risoluzione dei problemi pi\u00f9 comuni.<\/p>\n<h2>Creare l&#8217;Account Cloudflare e Aggiungere il Sito<\/h2>\n<p>Il primo passo \u00e8 creare un account Cloudflare e aggiungere il tuo dominio. Sembra banale, ma ci sono decisioni importanti da prendere gi\u00e0 in questa fase che influenzano tutto il resto della configurazione. Ecco la procedura che seguo io, con le accortezze che ho imparato nel tempo:<\/p>\n<ol>\n<li><strong>Registrazione su Cloudflare<\/strong> &#8211; Vai su <strong>cloudflare.com<\/strong> e crea un account con la tua email. Usa un&#8217;email professionale e attiva subito l&#8217;<strong>autenticazione a due fattori (2FA)<\/strong> in My Profile &gt; Authentication. Cloudflare gestir\u00e0 il DNS del tuo dominio: se qualcuno accede al tuo account, pu\u00f2 reindirizzare tutto il traffico del sito. La sicurezza dell&#8217;account \u00e8 fondamentale e non va trascurata. Usa un&#8217;app di autenticazione come Google Authenticator o Authy, non SMS.<\/li>\n<li><strong>Aggiungere il dominio<\/strong> &#8211; Dalla dashboard, clicca su <strong>Add a Site<\/strong> e inserisci il tuo dominio (esempio: miosito.it). Cloudflare eseguir\u00e0 una scansione DNS automatica per rilevare i record esistenti. Seleziona il piano <strong>Free<\/strong>: per la maggior parte dei siti \u00e8 pi\u00f9 che sufficiente. Il piano Pro aggiunge funzionalit\u00e0 come l&#8217;ottimizzazione automatica delle immagini e regole firewall avanzate, ma puoi sempre fare l&#8217;upgrade in seguito se ne hai bisogno.<\/li>\n<li><strong>Verificare i record DNS importati<\/strong> &#8211; Dopo la scansione, Cloudflare ti mostra un elenco dei record DNS rilevati. <strong>Controlla attentamente ogni record<\/strong>: a volte la scansione automatica non rileva tutti i record, specialmente quelli meno comuni come SRV, TXT per SPF\/DKIM e record MX per la posta. Confronta con i record presenti nel pannello del tuo attuale provider DNS. Aggiungi manualmente quelli mancanti. Un errore qui pu\u00f2 far smettere di funzionare la posta elettronica o altri servizi collegati al dominio. Presta attenzione particolare ai <strong>record MX<\/strong> per l&#8217;email e ai <strong>record TXT<\/strong> per SPF e DKIM.<\/li>\n<li><strong>Scegliere quali record proxare<\/strong> &#8211; Per ogni record A e CNAME, Cloudflare ti mostra un&#8217;icona nuvola arancione (proxied) o grigia (DNS only). I record <strong>proxied<\/strong> passano attraverso Cloudflare, beneficiando di CDN, firewall e SSL. I record <strong>DNS only<\/strong> puntano direttamente al server di origine. Attiva il proxy (nuvola arancione) per i record che puntano al sito web. Lascia in DNS only i record per servizi che non devono passare per Cloudflare: server di posta (MX), FTP, server di gioco, connessioni SSH dirette. Se proxi un record usato per la posta, le email smetteranno di funzionare.<\/li>\n<li><strong>Cambiare i nameserver presso il registrar<\/strong> &#8211; Cloudflare ti fornir\u00e0 due nameserver personalizzati (esempio: <strong>ada.ns.cloudflare.com<\/strong> e <strong>bob.ns.cloudflare.com<\/strong>). Accedi al pannello del tuo registrar (Aruba, Register.it, GoDaddy, Namecheap o chi gestisce il tuo dominio) e sostituisci i nameserver attuali con quelli forniti da Cloudflare. La propagazione DNS pu\u00f2 richiedere da pochi minuti a 48 ore, ma nella mia esperienza generalmente si completa in 1-4 ore. Non apportare altre modifiche durante questo periodo di attesa.<\/li>\n<\/ol>\n<h2>Configurare SSL Correttamente: Evitare i Redirect Loop<\/h2>\n<p>La configurazione SSL \u00e8 il punto dove la maggior parte degli utenti commette errori che rendono il sito irraggiungibile. Cloudflare offre diverse modalit\u00e0 SSL, e scegliere quella sbagliata causa il famigerato <strong>redirect loop<\/strong> (ERR_TOO_MANY_REDIRECTS). Ecco come funzionano le modalit\u00e0 e quale scegliere:<\/p>\n<ol>\n<li><strong>Modalit\u00e0 Off<\/strong> &#8211; Tutto il traffico passa in HTTP non crittografato. Non usarla mai. Nel 2026, un sito senza HTTPS \u00e8 inaccettabile sia per la sicurezza degli utenti sia per la SEO.<\/li>\n<li><strong>Modalit\u00e0 Flexible<\/strong> &#8211; La connessione tra il visitatore e Cloudflare \u00e8 HTTPS, ma quella tra Cloudflare e il tuo server \u00e8 HTTP. Sembra comoda perch\u00e9 non richiede un certificato SSL sul server di origine, ma \u00e8 la <strong>causa numero uno dei redirect loop<\/strong>. Ecco perch\u00e9: se il tuo sito WordPress \u00e8 configurato per forzare HTTPS (come dovrebbe), quando Cloudflare si connette al server in HTTP, WordPress lo reindirizza a HTTPS, Cloudflare si riconnette in HTTP, WordPress reindirizza di nuovo, e cos\u00ec all&#8217;infinito. Non usare Flexible a meno che tu non sappia esattamente cosa stai facendo e il tuo server non supporti assolutamente SSL.<\/li>\n<li><strong>Modalit\u00e0 Full<\/strong> &#8211; La connessione \u00e8 HTTPS sia tra visitatore e Cloudflare sia tra Cloudflare e il server di origine. Cloudflare accetta qualsiasi certificato sul server, anche autofirmato o scaduto. \u00c8 meglio di Flexible, ma non ideale perch\u00e9 non verifica l&#8217;autenticit\u00e0 del certificato del server.<\/li>\n<li><strong>Modalit\u00e0 Full (Strict)<\/strong> &#8211; Come Full, ma Cloudflare verifica che il certificato del server sia valido e firmato da una CA riconosciuta. <strong>Questa \u00e8 la modalit\u00e0 che uso sempre<\/strong>. Vai in <strong>SSL\/TLS &gt; Overview<\/strong> e seleziona <strong>Full (Strict)<\/strong>. Se il tuo hosting fornisce un certificato Let&#8217;s Encrypt (ormai quasi tutti lo fanno), Full Strict funziona perfettamente. In alternativa, puoi generare un <strong>Origin Certificate<\/strong> direttamente da Cloudflare (SSL\/TLS &gt; Origin Server &gt; Create Certificate) e installarlo sul server: \u00e8 gratuito e dura fino a 15 anni.<\/li>\n<li><strong>Forzare HTTPS ovunque<\/strong> &#8211; Dopo aver configurato Full (Strict), vai in <strong>SSL\/TLS &gt; Edge Certificates<\/strong> e attiva <strong>Always Use HTTPS<\/strong>. Questo reindirizza automaticamente tutto il traffico HTTP a HTTPS a livello di Cloudflare, prima ancora che la richiesta raggiunga il tuo server. Attiva anche <strong>Automatic HTTPS Rewrites<\/strong> per riscrivere automaticamente i link HTTP all&#8217;interno delle pagine, risolvendo molti problemi di contenuto misto (mixed content). Infine, abilita <strong>HSTS<\/strong> (HTTP Strict Transport Security) con un max-age di almeno 6 mesi per istruire i browser a usare sempre HTTPS.<\/li>\n<\/ol>\n<h2>Configurare la Cache e le Page Rules per WordPress<\/h2>\n<p>La cache \u00e8 il cuore della CDN: memorizza copie statiche delle tue pagine sui server Cloudflare sparsi nel mondo, servendo i contenuti dal nodo pi\u00f9 vicino al visitatore. Tuttavia, su siti dinamici come WordPress, la cache va configurata con attenzione per evitare di servire pagine errate agli utenti (ad esempio, il pannello di amministrazione cached con i dati di un altro utente). Ecco come configuro la cache per WordPress:<\/p>\n<ol>\n<li><strong>Impostazioni di cache di base<\/strong> &#8211; Vai in <strong>Caching &gt; Configuration<\/strong>. Imposta il <strong>Caching Level<\/strong> su <strong>Standard<\/strong>: Cloudflare memorizzer\u00e0 i file statici (immagini, CSS, JavaScript) basandosi sulle intestazioni di cache del server. Imposta il <strong>Browser Cache TTL<\/strong> su <strong>Respect Existing Headers<\/strong> se il tuo server \u00e8 gi\u00e0 configurato correttamente, oppure su un valore specifico come 4 ore o 1 giorno. Attiva <strong>Always Online<\/strong> per mostrare una versione cached del sito se il server di origine va offline.<\/li>\n<li><strong>Bypass della cache per wp-admin e wp-login<\/strong> &#8211; Questo \u00e8 il passaggio pi\u00f9 importante per WordPress. Devi assicurarti che Cloudflare <strong>non metta in cache<\/strong> le pagine di amministrazione e di login. Vai in <strong>Rules &gt; Page Rules<\/strong> (o nelle nuove Cache Rules) e crea le seguenti regole. Prima regola: URL pattern <strong>*tuodominio.it\/wp-admin\/*<\/strong>, impostazione <strong>Cache Level: Bypass<\/strong>. Seconda regola: URL pattern <strong>*tuodominio.it\/wp-login.php*<\/strong>, impostazione <strong>Cache Level: Bypass<\/strong>. Queste regole garantiscono che le aree dinamiche di WordPress non vengano mai memorizzate dalla CDN.<\/li>\n<li><strong>Cache Everything per le pagine statiche<\/strong> &#8211; Se vuoi che Cloudflare metta in cache anche le pagine HTML (non solo i file statici), puoi creare una Page Rule con <strong>Cache Level: Cache Everything<\/strong> e <strong>Edge Cache TTL<\/strong> impostato su un valore ragionevole (2-4 ore). Tuttavia, questa configurazione richiede attenzione: devi escludere le pagine con cookie di sessione (utenti loggati) usando l&#8217;opzione <strong>Bypass Cache on Cookie<\/strong> disponibile nei piani Business e superiori, oppure usando un plugin come <strong>WP Super Cache<\/strong> o <strong>W3 Total Cache<\/strong> con il modulo Cloudflare integrato. Per il piano gratuito, il mio consiglio \u00e8 di limitarsi alla cache dei file statici e usare un plugin di caching WordPress per le pagine HTML.<\/li>\n<li><strong>Configurare le Cache Rules (nuova interfaccia)<\/strong> &#8211; Cloudflare sta migrando dalle Page Rules alle <strong>Cache Rules<\/strong>, pi\u00f9 flessibili e potenti. Vai in <strong>Caching &gt; Cache Rules<\/strong> e crea una regola: condizione <strong>URI Path starts with \/wp-admin<\/strong> OR <strong>URI Path equals \/wp-login.php<\/strong>, azione <strong>Bypass Cache<\/strong>. Puoi aggiungere anche <strong>URI Path starts with \/wp-json<\/strong> per le API REST di WordPress e <strong>URI Path contains \/cart<\/strong> o <strong>\/checkout<\/strong> se usi WooCommerce. Le Cache Rules supportano fino a 5 regole nel piano gratuito, sufficienti per la maggior parte delle configurazioni WordPress.<\/li>\n<li><strong>Purge della cache<\/strong> &#8211; Quando aggiorni il sito (nuovo articolo, modifica al tema, aggiornamento CSS), potresti dover svuotare la cache di Cloudflare. Vai in <strong>Caching &gt; Configuration &gt; Purge Cache<\/strong>. Hai due opzioni: <strong>Purge Everything<\/strong> svuota tutta la cache (usa con cautela perch\u00e9 il sito sar\u00e0 temporaneamente pi\u00f9 lento mentre la cache si ricostruisce) e <strong>Custom Purge<\/strong> che ti permette di specificare URL singoli. Per WordPress, consiglio di installare il plugin ufficiale <strong>Cloudflare<\/strong> che esegue automaticamente il purge della cache quando pubblichi o aggiorni un contenuto.<\/li>\n<\/ol>\n<h2>Ottimizzazione delle Prestazioni: Compressione, Immagini e Minificazione<\/h2>\n<p>Oltre alla cache, Cloudflare offre diverse funzionalit\u00e0 per ottimizzare le prestazioni del sito. Alcune sono disponibili nel piano gratuito, altre richiedono piani superiori. Ecco quelle che attivo sempre e come le configuro per ottenere il massimo beneficio:<\/p>\n<ul>\n<li><strong>Compressione Brotli<\/strong> &#8211; Vai in <strong>Speed &gt; Optimization &gt; Content Optimization<\/strong> e attiva <strong>Brotli<\/strong>. Brotli \u00e8 un algoritmo di compressione sviluppato da Google che offre rapporti di compressione superiori del 15-25% rispetto a gzip per file HTML, CSS e JavaScript. Tutti i browser moderni lo supportano. Non c&#8217;\u00e8 nessun motivo per non attivarlo: riduce la dimensione dei file trasferiti senza alcun impatto negativo. La compressione avviene sui server edge di Cloudflare, quindi non carica il tuo server di origine.<\/li>\n<li><strong>Auto Minify<\/strong> &#8211; Nella stessa sezione, attiva <strong>Auto Minify<\/strong> per HTML, CSS e JavaScript. La minificazione rimuove spazi, commenti e caratteri non necessari dal codice, riducendone la dimensione. Se gi\u00e0 usi un plugin di minificazione su WordPress (come Autoptimize o WP Rocket), potresti voler disattivare la minificazione di Cloudflare per evitare conflitti. Nella mia esperienza, \u00e8 meglio usare <strong>una sola<\/strong> soluzione di minificazione: o Cloudflare o il plugin WordPress, non entrambi. Se il sito funziona correttamente, tieni quella di Cloudflare e disattiva quella del plugin.<\/li>\n<li><strong>Polish (ottimizzazione immagini)<\/strong> &#8211; Disponibile dal piano <strong>Pro<\/strong> in su, <strong>Polish<\/strong> comprime automaticamente le immagini servite attraverso Cloudflare. Offre due modalit\u00e0: <strong>Lossless<\/strong> (senza perdita di qualit\u00e0) e <strong>Lossy<\/strong> (con leggera perdita di qualit\u00e0 ma compressione maggiore). Per la maggior parte dei siti, Lossy \u00e8 la scelta migliore perch\u00e9 la differenza di qualit\u00e0 \u00e8 impercettibile ma il risparmio di banda \u00e8 significativo. Se sei sul piano gratuito, usa un plugin WordPress come <strong>ShortPixel<\/strong> o <strong>Imagify<\/strong> per ottimizzare le immagini prima dell&#8217;upload.<\/li>\n<li><strong>Rocket Loader<\/strong> &#8211; Questa funzionalit\u00e0 carica gli script JavaScript in modo asincrono per velocizzare il rendering della pagina. Attivala in <strong>Speed &gt; Optimization &gt; Content Optimization<\/strong>. Tuttavia, fai attenzione: Rocket Loader pu\u00f2 causare problemi con alcuni script che richiedono un ordine di caricamento specifico. Dopo l&#8217;attivazione, testa accuratamente il sito: controlla slider, form, popup, carrello e-commerce e funzionalit\u00e0 interattive. Se noti problemi, disattivala. Nella mia esperienza, funziona bene nel 70% dei casi, ma pu\u00f2 causare problemi con script inline e librerie jQuery dipendenti dall&#8217;ordine.<\/li>\n<li><strong>Early Hints<\/strong> &#8211; Attiva <strong>Early Hints<\/strong> in Speed &gt; Optimization: questa funzionalit\u00e0 usa il codice di risposta HTTP 103 per suggerire al browser quali risorse iniziare a scaricare prima ancora che il server abbia generato la pagina completa. Riduce il tempo di rendering percepito, specialmente per pagine con molte risorse CSS e font. \u00c8 una funzionalit\u00e0 relativamente nuova e non ha controindicazioni, quindi attivala sempre.<\/li>\n<li><strong>HTTP\/2 e HTTP\/3<\/strong> &#8211; Cloudflare abilita automaticamente <strong>HTTP\/2<\/strong> per tutti i siti e offre <strong>HTTP\/3 (QUIC)<\/strong> che puoi attivare in Network. HTTP\/3 \u00e8 particolarmente vantaggioso per utenti con connessioni instabili (mobile, WiFi pubblico) perch\u00e9 gestisce meglio la perdita di pacchetti. Attivalo: i browser che lo supportano lo useranno automaticamente, gli altri faranno fallback su HTTP\/2.<\/li>\n<\/ul>\n<h2>Firewall e Protezione: Bloccare Bot e Attacchi<\/h2>\n<p>Cloudflare non \u00e8 solo una CDN: \u00e8 anche un <strong>Web Application Firewall (WAF)<\/strong> potente. Anche nel piano gratuito, offre strumenti efficaci per proteggere il sito da bot malevoli, attacchi brute force e scraping. Ecco le regole firewall che configuro su ogni sito WordPress:<\/p>\n<ol>\n<li><strong>Bot Fight Mode<\/strong> &#8211; Vai in <strong>Security &gt; Bots<\/strong> e attiva <strong>Bot Fight Mode<\/strong>. Questa funzionalit\u00e0 identifica e blocca automaticamente i bot malevoli usando le firme comportamentali e il machine learning di Cloudflare. Non blocca i bot legittimi come Googlebot o Bingbot. \u00c8 la prima linea di difesa e dovrebbe essere sempre attiva. Se noti problemi con API o webhook legittimi bloccati, puoi creare eccezioni nelle WAF Custom Rules.<\/li>\n<li><strong>Regole firewall personalizzate per WordPress<\/strong> &#8211; Vai in <strong>Security &gt; WAF &gt; Custom Rules<\/strong> e crea regole specifiche. La prima regola che creo protegge <strong>xmlrpc.php<\/strong>: condizione <strong>URI Path equals \/xmlrpc.php<\/strong>, azione <strong>Block<\/strong>. XMLRPC \u00e8 usato raramente dai siti moderni ma \u00e8 uno dei vettori di attacco pi\u00f9 comuni su WordPress. Se usi Jetpack o l&#8217;app WordPress per iOS\/Android, non bloccare xmlrpc.php o questi servizi smetteranno di funzionare: in quel caso, usa l&#8217;azione <strong>Challenge (Managed)<\/strong> invece di Block.<\/li>\n<li><strong>Protezione dell&#8217;area di login<\/strong> &#8211; Crea una regola per limitare gli accessi alla pagina di login: condizione <strong>URI Path equals \/wp-login.php<\/strong>, azione <strong>Challenge (Managed)<\/strong>. Questo presenta un challenge CAPTCHA o JavaScript a chiunque tenti di accedere alla pagina di login, bloccando la maggior parte dei bot di brute force. Se vuoi essere pi\u00f9 restrittivo, puoi limitare l&#8217;accesso a wp-login.php solo da specifici paesi o indirizzi IP usando l&#8217;espressione: <strong>(http.request.uri.path eq &#8220;\/wp-login.php&#8221; and not ip.geoip.country in {&#8220;IT&#8221;})<\/strong> con azione Block, per permettere l&#8217;accesso solo dall&#8217;Italia.<\/li>\n<li><strong>Rate Limiting<\/strong> &#8211; Nel piano gratuito, puoi usare le <strong>Rate Limiting Rules<\/strong> per limitare il numero di richieste da un singolo IP. Crea una regola per l&#8217;endpoint di login: se un IP fa pi\u00f9 di <strong>5 richieste al minuto<\/strong> a \/wp-login.php, bloccalo per 10 minuti. Questo previene efficacemente gli attacchi brute force senza impattare gli utenti legittimi. Il rate limiting \u00e8 disponibile anche in <strong>Security &gt; WAF &gt; Rate Limiting Rules<\/strong> con una configurazione molto granulare.<\/li>\n<li><strong>Bloccare specifici User-Agent e paesi<\/strong> &#8211; Se il tuo sito serve solo utenti italiani, puoi bloccare il traffico da paesi che sono fonte comune di attacchi. Crea una regola con condizione <strong>ip.geoip.country in {&#8220;CN&#8221; &#8220;RU&#8221; &#8220;KP&#8221;}<\/strong> e azione <strong>Challenge (Managed)<\/strong>. Non consiglio di bloccare completamente, perch\u00e9 potresti bloccare anche utenti legittimi che usano VPN. Il challenge \u00e8 un buon compromesso. Per i User-Agent, blocca quelli notoriamente associati a scraper e bot malevoli: <strong>http.user_agent contains &#8220;MJ12bot&#8221;<\/strong> OR <strong>http.user_agent contains &#8220;AhrefsBot&#8221;<\/strong> OR <strong>http.user_agent contains &#8220;SemrushBot&#8221;<\/strong> con azione Block, se non hai bisogno dei dati di questi crawler SEO.<\/li>\n<\/ol>\n<h2>Troubleshooting: Risolvere gli Errori Comuni di Cloudflare<\/h2>\n<p>Anche con una configurazione perfetta, possono verificarsi problemi. Cloudflare ha una serie di <strong>errori specifici<\/strong> (serie 5xx) che indicano problemi di comunicazione tra Cloudflare e il server di origine. Sapere cosa significano e come risolverli ti far\u00e0 risparmiare ore di debugging. Ecco i pi\u00f9 comuni e come li risolvo:<\/p>\n<ul>\n<li><strong>Error 521 &#8211; Web Server Is Down<\/strong> &#8211; Questo errore significa che Cloudflare non riesce a stabilire una connessione TCP con il tuo server di origine. Le cause pi\u00f9 comuni: il server web (Apache\/Nginx) \u00e8 spento o crashato, il firewall del server blocca gli IP di Cloudflare, il server \u00e8 sovraccarico. <strong>Soluzione<\/strong>: verifica che il server web sia attivo (systemctl status nginx o apache2), controlla che gli <strong>IP di Cloudflare<\/strong> siano nella whitelist del firewall (trovi la lista aggiornata su cloudflare.com\/ips), controlla i log di errore del server per capire perch\u00e9 non risponde. Se usi CSF o iptables, aggiungi tutti i range IP di Cloudflare alle regole di allow.<\/li>\n<li><strong>Error 522 &#8211; Connection Timed Out<\/strong> &#8211; Cloudflare \u00e8 riuscito a connettersi al server ma la connessione \u00e8 andata in timeout prima di ricevere una risposta. Le cause: il server \u00e8 sovraccarico e impiega troppo tempo a rispondere, problemi di rete tra Cloudflare e il server, il keep-alive TCP \u00e8 disabilitato sul server. <strong>Soluzione<\/strong>: controlla il carico del server (top, htop, vmstat), verifica che il <strong>keep-alive<\/strong> sia abilitato nella configurazione del web server, aumenta i timeout del server. Se il problema \u00e8 intermittente, potrebbe essere un picco di traffico: considera di aggiornare le risorse del server o di attivare il caching aggressivo su Cloudflare per ridurre le richieste al server di origine.<\/li>\n<li><strong>Error 524 &#8211; A Timeout Occurred<\/strong> &#8211; Simile al 522, ma qui la connessione TCP \u00e8 stata stabilita e Cloudflare sta attendendo una risposta HTTP che non arriva entro 100 secondi (il timeout di default). Questo errore si verifica spesso su pagine che eseguono operazioni lunghe: import, export, processi di sincronizzazione. <strong>Soluzione<\/strong>: ottimizza le operazioni lente sul server, usa processi in background per le operazioni lunghe, oppure escludi gli URL problematici dal proxy di Cloudflare impostando il record DNS su <strong>DNS Only<\/strong> (nuvola grigia) per un sottodominio dedicato (esempio: backend.tuodominio.it).<\/li>\n<li><strong>Error 526 &#8211; Invalid SSL Certificate<\/strong> &#8211; Questo errore appare quando usi la modalit\u00e0 <strong>Full (Strict)<\/strong> ma il certificato SSL sul server di origine non \u00e8 valido, \u00e8 scaduto o \u00e8 autofirmato. <strong>Soluzione<\/strong>: installa un certificato valido sul server (Let&#8217;s Encrypt \u00e8 gratuito e si rinnova automaticamente con certbot) oppure genera un <strong>Origin Certificate<\/strong> dalla dashboard Cloudflare e installalo sul server. Se il certificato \u00e8 scaduto, rinnova con: <strong>certbot renew &#8211;force-renewal<\/strong> e riavvia il web server.<\/li>\n<li><strong>Redirect Loop (ERR_TOO_MANY_REDIRECTS)<\/strong> &#8211; Come spiegato nella sezione SSL, questo \u00e8 causato quasi sempre dalla modalit\u00e0 SSL <strong>Flexible<\/strong> combinata con un sito configurato per forzare HTTPS. <strong>Soluzione<\/strong>: cambia la modalit\u00e0 SSL a <strong>Full (Strict)<\/strong>, assicurati che il server abbia un certificato SSL valido, e rimuovi eventuali regole di redirect HTTP &gt; HTTPS nel file .htaccess del server (lasciale fare a Cloudflare con Always Use HTTPS). Se il problema persiste, svuota la cache del browser e di Cloudflare.<\/li>\n<li><strong>Mixed Content Warnings<\/strong> &#8211; Dopo l&#8217;attivazione di SSL tramite Cloudflare, potresti vedere avvisi di <strong>contenuto misto<\/strong> nel browser: la pagina \u00e8 HTTPS ma carica risorse (immagini, script, CSS) via HTTP. <strong>Soluzione<\/strong>: attiva <strong>Automatic HTTPS Rewrites<\/strong> in SSL\/TLS &gt; Edge Certificates per riscrivere automaticamente i link HTTP in HTTPS. Per risolvere alla radice, aggiorna gli URL nel database WordPress da http:\/\/ a https:\/\/ usando il plugin <strong>Better Search Replace<\/strong> o il comando WP-CLI: <strong>wp search-replace &#8216;http:\/\/tuodominio.it&#8217; &#8216;https:\/\/tuodominio.it&#8217; &#8211;all-tables<\/strong>.<\/li>\n<\/ul>\n<h2>FAQ &#8211; Domande Frequenti su Cloudflare<\/h2>\n<h3>Cloudflare rallenta il sito se il server \u00e8 in Italia e i visitatori sono italiani?<\/h3>\n<p>No, Cloudflare non rallenta il sito neanche in questo scenario. Cloudflare ha <strong>data center in Italia<\/strong> (a Milano e Roma), quindi i visitatori italiani vengono serviti dal nodo pi\u00f9 vicino. Anche se il server di origine \u00e8 in Italia, Cloudflare aggiunge comunque valore: serve i file statici dalla cache senza interrogare il server, applica la compressione Brotli e ottimizza la connessione con HTTP\/2 e HTTP\/3. L&#8217;unico scenario in cui potresti notare una leggera latenza aggiuntiva \u00e8 per contenuti non cacheable (pagine dinamiche), perch\u00e9 la richiesta passa attraverso il nodo Cloudflare prima di raggiungere il server. Ma parliamo di pochi millisecondi, ampiamente compensati dai benefici della cache e della protezione.<\/p>\n<h3>Posso usare Cloudflare insieme a un plugin di caching WordPress?<\/h3>\n<p>Assolutamente s\u00ec, e anzi lo consiglio. Cloudflare e un plugin come <strong>WP Super Cache<\/strong>, <strong>W3 Total Cache<\/strong> o <strong>WP Rocket<\/strong> operano a livelli diversi e si complementano. Il plugin di caching genera pagine HTML statiche sul server, riducendo il carico di PHP e MySQL. Cloudflare memorizza queste pagine statiche sui suoi edge server e le serve ai visitatori senza interrogare il tuo server. Il risultato \u00e8 una catena di caching a due livelli che massimizza le prestazioni. L&#8217;importante \u00e8 coordinare il purge della cache: quando aggiorni un contenuto, svuota sia la cache del plugin sia quella di Cloudflare. Il plugin ufficiale Cloudflare per WordPress gestisce automaticamente questa sincronizzazione.<\/p>\n<h3>Il piano gratuito di Cloudflare \u00e8 sufficiente per un e-commerce?<\/h3>\n<p>Per un e-commerce di piccole e medie dimensioni, il piano gratuito \u00e8 sufficiente. Offre CDN, SSL, protezione DDoS di base, 5 Page Rules e firewall con regole personalizzate. Tuttavia, per e-commerce pi\u00f9 grandi o con esigenze specifiche, il piano <strong>Pro<\/strong> (20 dollari al mese) aggiunge l&#8217;ottimizzazione delle immagini con Polish, il WAF con regole gestite, e 20 Page Rules. Se il tuo e-commerce gestisce dati sensibili (carte di credito, dati personali), il piano Pro o Business offre protezioni aggiuntive che possono essere importanti per la compliance PCI-DSS. Valuta in base al volume di traffico e alla criticit\u00e0 del servizio.<\/p>\n<h3>Come verifico che Cloudflare stia effettivamente servendo dalla cache?<\/h3>\n<p>Controlla gli <strong>header HTTP<\/strong> della risposta. Apri gli strumenti sviluppatore del browser (F12), vai nella scheda Network, clicca su una risorsa e cerca l&#8217;header <strong>cf-cache-status<\/strong>. I valori possibili sono: <strong>HIT<\/strong> (servito dalla cache di Cloudflare), <strong>MISS<\/strong> (non in cache, richiesta inoltrata al server), <strong>DYNAMIC<\/strong> (contenuto non cacheable), <strong>EXPIRED<\/strong> (la cache era scaduta). Se vedi molti MISS, la cache non \u00e8 configurata correttamente o il TTL \u00e8 troppo basso. Puoi anche usare il comando da terminale: <strong>curl -I https:\/\/tuodominio.it\/immagine.jpg<\/strong> e cercare cf-cache-status nell&#8217;output.<\/p>\n<h3>Cloudflare nasconde il vero indirizzo IP del server?<\/h3>\n<p>S\u00ec, quando il proxy \u00e8 attivo (nuvola arancione), Cloudflare nasconde l&#8217;IP reale del tuo server. Tutte le richieste mostrano gli IP di Cloudflare invece di quello del server. Tuttavia, l&#8217;IP originale potrebbe essere ancora visibile in record DNS non proxati, nella cronologia DNS (siti come SecurityTrails), o negli header email se il server invia email direttamente. Per una protezione completa, assicurati che <strong>tutti<\/strong> i record A e AAAA che puntano al server siano proxati, usa un servizio email separato (non lo stesso server) e configura il firewall del server per accettare connessioni HTTP\/HTTPS <strong>solo<\/strong> dagli IP di Cloudflare.<\/p>\n<h3>Cosa succede se Cloudflare va offline?<\/h3>\n<p>Cloudflare ha un&#8217;infrastruttura estremamente resiliente e i downtime completi sono rarissimi. Tuttavia, se un nodo specifico ha problemi, il traffico viene automaticamente reindirizzato ad altri nodi. In caso di problemi gravi, puoi disabilitare temporaneamente il proxy Cloudflare cambiando i record DNS da proxied (nuvola arancione) a <strong>DNS Only<\/strong> (nuvola grigia): il traffico andr\u00e0 direttamente al tuo server. Questa \u00e8 la soluzione di emergenza che uso quando sospetto un problema lato Cloudflare. La funzione <strong>Always Online<\/strong>, se attivata, serve una versione cached del sito anche se il server di origine non risponde, garantendo continuit\u00e0 del servizio.<\/p>\n<h2>La Mia Soluzione Definitiva<\/h2>\n<p>Configurare Cloudflare correttamente non \u00e8 difficile, ma richiede attenzione ai dettagli. Gli errori pi\u00f9 comuni che vedo &#8211; redirect loop, errori 521\/522, cache che memorizza il pannello di amministrazione &#8211; sono tutti evitabili seguendo la procedura corretta. I punti chiave della mia configurazione standard sono: <strong>SSL sempre in Full (Strict)<\/strong> con un certificato valido sul server, <strong>bypass della cache per wp-admin e wp-login<\/strong>, <strong>Bot Fight Mode attivo<\/strong>, <strong>Brotli abilitato<\/strong>, <strong>firewall rules per xmlrpc.php e protezione login<\/strong>. Con questa base, ogni sito che configuro ottiene immediatamente tempi di caricamento migliori, protezione DDoS, certificato SSL gratuito e risparmio di banda sul server di origine. Il piano gratuito \u00e8 sorprendentemente completo e sufficiente per la stragrande maggioranza dei siti. Cloudflare \u00e8 uno strumento potentissimo, ma come tutti gli strumenti potenti, va usato con cognizione di causa. Se hai bisogno di aiuto per configurare Cloudflare sul tuo sito, risolvere errori o ottimizzare le prestazioni, <a href=\"https:\/\/darioiannascoli.it\/#contatti\">contattami dalla mia pagina contatti<\/a>: posso fornirti una configurazione personalizzata per le esigenze specifiche del tuo progetto.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Scopri come configurare Cloudflare come CDN per velocizzare il tuo sito web. Guida completa con DNS, SSL, cache rules e risoluzione problemi comuni.<\/p>\n","protected":false},"author":1,"featured_media":824,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Configurare Cloudflare come CDN per il Tuo Sito Web Senza Errori","_seopress_titles_desc":"Scopri come configurare Cloudflare come CDN per velocizzare il tuo sito web. Guida completa con DNS, SSL, cache rules e risoluzione problemi comuni.","_seopress_robots_index":"","footnotes":""},"categories":[3],"tags":[42,27,38,28,47],"class_list":["post-747","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-configurare-hosting","tag-dns-dominio","tag-hosting-web","tag-record-dns","tag-ssl"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=747"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/747\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/824"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}