Come aggiungere Cloudflare a VPS, dedicato e hosting condiviso

Mettere Cloudflare davanti a un VPS, a un dedicato o a un hosting condiviso non significa “attivare la CDN e dimenticarsene”. Il punto vero è separare con precisione ciò che deve restare pubblico da ciò che deve essere esposto solo all’edge, poi verificare che DNS, certificati, header e regole firewall non si pestino i piedi. Se questa distinzione è chiara, Cloudflare riduce latenza, assorbe traffico indesiderato e semplifica un po’ la vita. Se non lo è, diventa un altro livello da diagnosticare quando il sito smette di rispondere.

La decisione architetturale non cambia molto tra VPS, server dedicato e hosting condiviso: Cloudflare si mette davanti al dominio, il traffico degli utenti passa dai PoP Cloudflare e l’origin risponde solo quando serve. Cambia invece il margine operativo. Su un VPS hai spesso accesso a firewall, web server e certificati; su un dedicato hai controllo quasi totale; su hosting condiviso dipendi dal pannello e dai limiti del provider. Questo cambia il modo in cui imposti DNS, SSL, caching e protezione dell’origin.

Prima scelta: cosa vuoi ottenere davvero

Prima di toccare i record DNS, conviene chiarire l’obiettivo. Cloudflare può servire per tre cose diverse: protezione, accelerazione e controllo del traffico. Se ti interessa solo nascondere l’IP origin e filtrare bot e attacchi banali, bastano DNS proxy, SSL corretto e qualche regola di firewall. Se vuoi caching aggressivo, devi ragionare su header, cookie, bypass delle aree dinamiche e invalidazione. Se vuoi usare solo DNS anycast senza proxy, Cloudflare resta un provider DNS molto solido, ma non stai sfruttando il suo edge.

La trappola classica è attivare il proxy arancione su tutto e poi scoprire che mail, servizi secondari o applicazioni con IP allowlist smettono di funzionare. Cloudflare non va trattato come un “metto tutto dietro e vediamo”. Va disegnato per host e per servizio: web sì, mail no; API forse; pannello amministrativo quasi sempre no, a meno di una protezione specifica e testata. Se hai servizi non HTTP sullo stesso server, il proxy Cloudflare non li copre.

VPS: il caso più flessibile

Su VPS hai il massimo controllo e quindi anche il massimo numero di punti da allineare. La sequenza corretta è: DNS, certificato origin, firewall, web server, applicazione. Prima di cambiare il record, verifica che l’origin risponda in locale e che il dominio sia già pronto per HTTPS. Se il server accetta solo HTTP e poi attivi Cloudflare in modalità Full o Full (strict), il sito può andare online ma la tratta edge-origin resta debole o mal configurata.

Un flusso pratico per VPS è questo:

1. Installa o prepara un certificato valido sull’origin. Il più semplice è usare un certificato Cloudflare Origin oppure un certificato pubblico normale, se il server è raggiungibile anche fuori da Cloudflare.
2. Metti Cloudflare come DNS autoritativo per la zona e importa i record esistenti.
3. Attiva il proxy solo sui record web necessari, di solito `A` e `AAAA` per `@` e `www`.
4. Imposta SSL/TLS su Full (strict) se l’origin ha un certificato valido.
5. Limita l’accesso diretto all’origin alle sole IP Cloudflare, se il tuo modello operativo lo consente.

Per verificare che il DNS stia puntando correttamente, un controllo minimale è questo:

dig +short example.com
curl -I https://example.com

Nel primo comando vuoi vedere un indirizzo coerente con Cloudflare, non l’IP origin. Nel secondo vuoi una risposta HTTP valida e un certificato coerente con il dominio. Se invece `curl` mostra errori di handshake, il problema non è “Cloudflare non funziona”: spesso è una modalità SSL sbagliata, un certificato origin assente o un firewall che blocca l’edge.

Se vuoi blindare l’origin, la logica giusta è consentire solo i range IP Cloudflare sul 80/443 e negare il resto. Su Linux con `nftables` o `iptables` questo si può fare, ma non va improvvisato: richiede aggiornamento periodico dei range Cloudflare e un rollback pronto. In alternativa, su alcuni ambienti è più semplice usare un firewall gestito dal provider o una security group con regole più statiche, sempre che tu abbia una lista mantenuta di IP Cloudflare aggiornata. La regola da ricordare è semplice: se l’origin resta pubblico, Cloudflare protegge il dominio; se l’origin è chiuso, proteggi anche il bypass diretto.

Server dedicato: più controllo, più responsabilità

Su un dedicato il vantaggio non è solo la potenza, ma la possibilità di mettere ordine in modo rigoroso. Puoi separare vhost, reverse proxy, applicazione e servizi ausiliari senza dipendere da un pannello limitante. Di contro, se sbagli una regola di firewall o un redirect, l’impatto è più ampio perché spesso sul dedicato convivono più siti o più ambienti.

Qui Cloudflare va pensato insieme al web server. Con Apache o Nginx devi decidere se terminare TLS direttamente sull’origin o davanti a un reverse proxy locale. Se l’origin è esposto solo a Cloudflare, il certificato va comunque curato: non basta un certificato “qualunque”. In modalità strict, Cloudflare verifica l’identità dell’origin e questo elimina una classe di errori che in produzione sono fastidiosi da inseguire.

Un caso pratico: hai un sito principale su `example.com`, un pannello su `panel.example.com` e una webmail su `webmail.example.com`. La scelta sensata è lasciare proxy Cloudflare attivo solo sul sito principale. Pannello e webmail possono restare DNS only, oppure essere protetti in altro modo, perché molti servizi non gradiscono un proxy intermedio se non sono progettati per quello. Questo riduce i casi in cui un login fallisce per cookie, redirect o IP client non preservato.

Se usi Nginx come reverse proxy, un controllo utile è verificare che il server registri l’IP reale del client e non quello di Cloudflare, altrimenti i log diventano quasi inutili. Devi fidarti degli header corretti e limitare le sorgenti che li possono iniettare. Un esempio tipico è questo:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header CF-Connecting-IP;

Questi sono solo esempi di configurazione, non una lista completa. Il punto operativo è che, se non allinei real IP, rate limit, mod_security, log e applicazione, Cloudflare ti maschera il traffico invece di semplificarlo. Ogni filtro che lavora sull’IP sorgente deve sapere che il client reale arriva tramite un intermediario fidato.

Hosting condiviso: quello che puoi fare e quello che devi evitare

Su hosting condiviso Cloudflare è spesso il modo più rapido per ottenere HTTPS, caching e protezione DDoS di base senza chiedere modifiche al provider. Il rovescio della medaglia è che hai meno controllo sull’origin e, in alcuni casi, non puoi installare certificati custom, cambiare header server o modificare regole a livello di web server. Qui conviene essere pragmatici: sfrutta quello che è esposto dal pannello e non cercare di forzare un comportamento da VPS.

La procedura tipica è: cambi i nameserver sul registrar, importi la zona, controlli i record presenti nel pannello Cloudflare e attivi il proxy solo sui record web. Se il provider di hosting usa un IP condiviso per più clienti, il vantaggio di Cloudflare è ancora più evidente: il pubblico vede Cloudflare, non l’IP del server condiviso. Questo però non significa che l’origin sia “segreto”: altri record, altri host o servizi del provider possono ancora esporre indizi utili. Va trattato come un miglioramento, non come una blindatura assoluta.

In shared hosting il punto delicato è la compatibilità con WordPress, Joomla, Magento o applicazioni che dipendono da IP client, login persistente o regole anti-abuso. Se il CMS salva l’IP per audit o sicurezza, devi verificare che il plugin o il codice usi il campo corretto. Se lavori da pannello, cerca opzioni come “trusted proxy”, “real IP”, “X-Forwarded-For” o equivalenti. Se il provider non offre nulla, resta un limite strutturale: non si risolve con una magia lato Cloudflare.

DNS, proxy e modalità SSL: il triangolo che rompe tutto

Molti problemi con Cloudflare nascono da tre errori ripetuti: record DNS sbagliati, proxy attivo sul record sbagliato e modalità SSL incoerente con l’origin. Il record può anche essere giusto, ma se il proxy è spento quando pensavi fosse acceso, oppure se il certificato origin non è valido e stai usando strict, il sito cade o mostra errori TLS. Quando succede, non partire dal CMS: guarda prima il layer edge-origin.

Un controllo rapido utile è il seguente:

curl -svI https://example.com 2>&1 | sed -n '1,20p'
dig +short example.com
dig +trace example.com

Se `curl` non arriva a una risposta HTTP, hai un problema di TLS, DNS o routing verso l’edge. Se il DNS non risolve come previsto, il problema è a monte della CDN. Se invece il dominio risponde ma il contenuto è vecchio o non cambia, devi guardare cache e header di controllo. Cloudflare è efficace quando i confini sono netti; quando non lo sono, ogni livello sembra colpevole e perdi tempo a inseguire sintomi.

Caching: utile solo se sai cosa stai lasciando fuori

La cache Cloudflare non va pensata come “accelero tutto”. Le pagine statiche, le immagini, i CSS e gli asset versionati sono candidati naturali. Le aree autenticate, i carrelli, le dashboard e i contenuti personalizzati no, a meno di regole molto precise. Il confine lo fanno cookie, query string, header di cache e URL pattern. Se sbagli qui, il problema non è solo il contenuto vecchio: puoi servire dati incoerenti a utenti diversi.

Per un sito classico, il punto di partenza è lasciare il caching di base a Cloudflare per file statici e impostare regole di bypass sulle sezioni dinamiche. Se usi WordPress, spesso conviene evitare di inventare regole troppo creative e partire da un plugin o da una configurazione compatibile con la tua architettura. Le eccezioni più frequenti sono `/wp-admin`, `/cart`, `/checkout`, `/my-account` e simili, ma la lista reale dipende dal sito. Qui non esiste una regola universale: va letta sul comportamento dell’applicazione.

Una buona pratica è osservare gli header di risposta prima e dopo la modifica. Cerca segnali come `cf-cache-status`, `cache-control`, `age` e `vary`. Se una pagina che dovrebbe essere cacheable continua a risultare `BYPASS`, la causa può essere un cookie, un header del backend o una regola troppo conservativa. Se invece una pagina dinamica entra in cache, hai un problema più serio: va esclusa subito e poi verificato il comportamento lato applicazione.

Proteggere l’origin senza complicarsi la vita

La protezione dell’origin è il punto che distingue una configurazione pulita da una configurazione solo apparente. Se il server risponde direttamente su Internet, chiunque può tentare di aggirare Cloudflare andando sull’IP origin. La soluzione più solida è restringere l’accesso ai soli range Cloudflare, ma va fatto con metodo: backup delle regole, finestra di cambio, test da rete esterna e piano di rollback. Non è un comando da lanciare “a sentimento”.

Su VPS o dedicato, il controllo si esercita a livello firewall. Su hosting condiviso, invece, spesso non puoi farlo e devi accettare il limite del modello. In quel caso Cloudflare protegge il dominio pubblico, ma non impedisce a terzi di osservare o sondare il servizio origin se riescono a risalire all’indirizzo. È importante dirlo chiaramente, perché molte aspettative errate nascono dal confondere proxy esterno e occultamento totale dell’origin.

Se il provider supporta i certificati origin o un reverse proxy interno, vale la pena usarli. Il vantaggio non è solo sicurezza: riduci anche gli errori di configurazione, perché il canale edge-origin segue una policy coerente. In produzione questo conta più di qualsiasi slogan sulla “semplicità”, perché la semplicità vera è avere pochi stati possibili e facili da verificare.

Checklist operativa che evita i casi peggiori

1. Verifica quali host devono stare dietro Cloudflare e quali no. Mail, SSH, pannelli e servizi non HTTP vanno trattati separatamente.
2. Assicurati che l’origin risponda correttamente prima del cambio DNS. Un `curl -I http://origin-ip` o un test sul vhost locale deve già avere senso.
3. Passa la zona su Cloudflare e importa tutti i record, poi abilita il proxy solo dove serve.
4. Imposta SSL/TLS coerente con il certificato dell’origin. Se puoi, usa strict.
5. Controlla header, log e IP reale del client. Se vedi tutti i visitatori come Cloudflare, la telemetria è incompleta.
6. Proteggi l’origin se hai controllo del firewall. Se non ce l’hai, documenta il limite invece di fingere che non esista.
7. Testa caching e bypass sulle pagine dinamiche prima di andare in esercizio pieno.

Un dettaglio spesso trascurato è la gestione dei redirect. Se l’applicazione forza `http` verso `https`, o `www` verso dominio nudo, devi evitare catene di redirect tra Cloudflare e origin. Un loop o un salto inutile non si vede sempre a colpo d’occhio, ma pesa su TTFB e può rompere login o callback esterne. Il controllo minimo è osservare la sequenza con `curl -I -L` e leggere gli `Location` una volta sola, non cinque.

curl -I -L https://example.com | sed -n '1,30p'

Se il risultato mostra più passaggi del necessario, cerca il redirect duplicato tra pannello hosting, web server, CMS e regole Cloudflare. Di solito il problema non è uno solo: è la somma di due livelli che cercano di fare la stessa cosa.

Quando Cloudflare aiuta davvero e quando no

Cloudflare aiuta davvero quando hai traffico pubblico, contenuti cacheabili, necessità di mitigazione base e un origin che può essere protetto bene. Aiuta meno quando l’applicazione è quasi tutta dinamica, quando il provider di hosting non ti dà controllo sui trust proxy, o quando usi servizi non compatibili con un reverse proxy esterno. In quei casi il rischio è spendere tempo a inseguire una configurazione elegante che poi non regge il comportamento reale dell’app.

La scelta sensata non è “mettere Cloudflare ovunque”, ma decidere per ogni hostname se serve proxy, solo DNS o nessun intervento. Questa granularità è la vera differenza tra un setup pulito e uno che funziona solo finché nessuno cambia una regola. VPS e dedicato ti danno spazio per fare le cose bene; hosting condiviso ti chiede di essere ancora più selettivo. In tutti i casi, la regola resta la stessa: prima osserva, poi modifica, poi verifica. Il resto è rumore operativo.