Collegare un sito web a Cloudflare

Come collegare un sito web a Cloudflare

Cloudflare può affiancarsi a un sito web in due modi molto diversi. Puoi spostare l’intero dominio su DNS e proxy di Cloudflare, oppure mantenere una configurazione più limitata e attivare una sola funzione alla volta. Questa scelta cambia i passaggi, i rischi e il piano di rollback, soprattutto quando devi configurare DNS Cloudflare dominio in modo corretto fin dall’inizio.

Da qui bisogna partire. Un sito promozionale con poche pagine ha esigenze diverse rispetto a un dominio aziendale molto usato per la posta, e un dominio che già ospita un sito corporate richiede una gestione dei record molto più attenta rispetto a un lancio da zero. Se stai pensando anche alla sicurezza del sito, Cloudflare entra spesso in gioco proprio per questo motivo.

1. Decidi se ti serve il controllo completo del DNS o solo una funzione di Cloudflare

Cloudflare non è un solo interruttore. Può gestire il DNS, fare da proxy al traffico web, memorizzare contenuti in cache, filtrare le richieste e posizionarsi tra i visitatori e il server di origine. Se ti serve una sola funzione, per esempio la gestione del DNS o un livello di protezione, devi comunque sapere che di solito sono i nameserver del dominio il punto in cui Cloudflare prende il controllo.

Per un sito vetrina semplice, il controllo completo spesso va benissimo. Per una configurazione con instradamento della posta, servizi di verifica e diversi sottodomini, la decisione è più delicata. Un’infrastruttura di rete privata, ad esempio, può richiedere che alcuni hostname restino fuori dal percorso proxy, mentre le pagine web possono passare da Cloudflare senza problemi.

Fatti una domanda pratica: cosa deve funzionare assolutamente dal primo giorno? Se la risposta include email, callback API o il flusso dei pagamenti, non stai solo “collegando un sito a Cloudflare”; stai cambiando il modo in cui il dominio si risolve. La differenza conta.

Una regola semplice aiuta: non andare a intuito. Se il sito dipende da qualsiasi servizio esterno al server web, elencalo prima di toccare i nameserver. Quell’elenco diventa la tua rete di sicurezza.

2. Controlla la configurazione attuale del dominio prima di cambiare i nameserver

Prima di spostare qualcosa, verifica dove viene gestito il DNS adesso. Il registrar e l’host DNS non sono sempre la stessa azienda, e questa discrepanza causa errori facilmente evitabili. Cerca i nameserver attuali e poi ispeziona i record della zona presenti lì.

Ti serve il quadro completo: record A e AAAA per il sito, record CNAME per i sottodomini, record MX per la posta, record TXT per la verifica e qualsiasi record insolito usato da strumenti di terze parti. Un record TXT mancante può bloccare un flusso di accesso. Un record MX sbagliato può interrompere la posta.

Non affidarti alla memoria. Un dominio online da anni può contenere record aggiunti da persone diverse in momenti diversi, e alcuni potrebbero non essere più documentati altrove. Se il proprietario del sito non sa spiegare un record, è un motivo per conservarlo finché non capisci a cosa serve.

Questo è anche il momento di annotare redirect e vecchi hostname. Se il traffico arriva ancora su un vecchio sottodominio, segnalo ora. Un redirect che funziona all’origine può fallire più tardi se l’hostname non è stato copiato in Cloudflare.

Tieni una copia della zona attuale fuori dall’account del registrar. Basta un file di testo semplice. Va bene anche un foglio di calcolo. L’importante è poter recuperare tutto, soprattutto se devi poi importare record DNS su Cloudflare senza perdere voci importanti.

3. Crea il sito su Cloudflare e importa i record DNS esistenti

Dopo l’analisi, aggiungi il dominio a Cloudflare. Cloudflare analizzerà i record DNS esistenti e proverà a importarli nella sua zona. Questa scansione fa risparmiare tempo, ma non garantisce che tutto sia stato copiato correttamente; per questo conviene importare record DNS su Cloudflare e verificare subito il risultato.

Controlla i record importati uno per uno. Un record può mancare, un sottodominio può essere duplicato oppure un valore può essere obsoleto. Il primo passaggio riguarda l’accuratezza, non la velocità. Se vedi un hostname che dovrebbe puntare al tuo server web ma ora punta altrove, correggilo prima di toccare il registrar.

Due controlli semplici intercettano molti errori. Primo: confronta i record importati con la tua lista di audit. Secondo: verifica che il dominio apex e il comune hostname “www” risolvano entrambi nel posto giusto. Sono i record che gli utenti incontreranno per primi.

Se gestisci un sito che si comporta come un sito web corporate, tieni d’occhio con attenzione i sottodomini. Un portale di supporto, un hostname di staging e un file host spesso convivono con il sito principale, e basta un record mancante per creare un disservizio difficile da diagnosticare.

Una nota pratica: l’importazione di Cloudflare è utile, ma non sostituisce la tua verifica. La scansione è un punto di partenza. Il tuo audit è il controllo finale.

4. Scegli quali record devono restare proxati e quali devono rimanere solo DNS

Cloudflare ti lascia scegliere per molti record. La nuvola arancione significa che il traffico passa attraverso il proxy di Cloudflare. La nuvola grigia significa solo DNS. Questa scelta non è estetica. Cambia il percorso delle richieste.

Il traffico web del sito pubblico viene spesso proxato. I record di posta no. I record di verifica no. Anche alcuni sottodomini che servono API o strumenti specializzati dovrebbero restare solo DNS, a meno che tu non abbia testato con cura l’intero percorso. Se vuoi una regola veloce, proxare il sito e lasciare in pace i servizi non web, salvo un motivo preciso per cambiarli.

Un errore comune è proxare tutto perché sembra più ordinato. Non resta ordinato a lungo. Un record MX dietro il proxy non funzionerà. Un hostname di verifica potrebbe non essere più riconosciuto da un altro servizio. Un endpoint per il trasferimento file potrebbe comportarsi in modo strano perché non era pensato per passare attraverso il proxy web.

Pensa in termini di funzione, non di aspetto. Il sito può essere proxato per prestazioni e sicurezza. La posta di solito dovrebbe restare solo DNS. Se la tua configurazione include pixel di tracciamento, endpoint webhook o host di verifica di terze parti, testali uno per uno.

Il traffico che deve restare DNS puro è spesso proprio quello che meno vuoi rompere. Tienilo bene a mente prima di cliccare troppe volte sulla nuvola arancione.

5. Aggiorna i nameserver del dominio presso il registrar

Cloudflare assegnerà due nameserver al dominio. Devi sostituire i nameserver attuali presso il registrar con quei due valori. È il passaggio che affida a Cloudflare l’autorità sul DNS, quindi copiali esattamente come mostrati.

Nel registrar, trova la sezione dei nameserver e rimuovi la coppia precedente. Poi inserisci la coppia assegnata da Cloudflare. Salva la modifica.

Non andare nel panico se il sito non cambia subito. Le modifiche DNS non si sincronizzano secondo un unico orologio. Un visitatore potrebbe raggiungere ancora il vecchio percorso per un po’, ed è normale. Se il vecchio host DNS resta attivo durante la transizione, riduci il rischio di lookup falliti.

Una frase breve qui: sii preciso. Un solo carattere sbagliato nell’entry del nameserver può impedire la delega.

Inoltre, non cambiare più di una cosa alla volta. Se rinomini record, cambi host e modifichi i nameserver nella stessa sessione, rendi la risoluzione dei problemi molto più complicata del necessario.

6. Verifica che il dominio sia attivo su Cloudflare e testa i percorsi reali del traffico

Dopo il cambio dei nameserver, Cloudflare dovrebbe mostrare il dominio come attivo. Se non succede, in genere il problema è uno di questi tre: la modifica sul registrar non è stata salvata, i nameserver sono stati inseriti in modo errato oppure il registrar ha ancora dati in cache. Controlla questi aspetti prima di incolpare il server di origine.

Poi testa i percorsi reali, non solo la homepage. Apri il dominio principale, la versione “www”, una sottopagina importante e qualsiasi sottodominio rilevante. Se il sito ha una pagina di login, testa anche quella. Se prevede un download di file o l’invio di un modulo, prova anche quelle azioni. Le pagine possono caricarsi mentre un endpoint nascosto è rotto.

Qui aiuta uno strumento di monitoraggio. Se usi una piattaforma di analisi e monitoraggio del sito, confronta le prime richieste in tempo reale dopo il passaggio con il pattern normale. Un aumento improvviso degli errori su un hostname è spesso il primo segnale che un record DNS o un’impostazione del proxy richiedono attenzione.

Usa un secondo browser o una finestra privata per un test pulito. I dati memorizzati in cache possono nascondere i problemi. Lo stesso vale per una vecchia sessione di accesso.

Se qualcosa fallisce, testa il percorso partendo dal dominio verso l’esterno: DNS, risposta edge, risposta dell’origine e poi logica dell’applicazione. Quest’ordine fa risparmiare tempo.

7. Imposta le prime opzioni sicure di Cloudflare per una nuova connessione

Una volta che il dominio è attivo, mantieni conservative le prime impostazioni. Scegli una modalità SSL/TLS che corrisponda a ciò che il tuo origin supporta davvero e non andare a tentativi. Se il certificato dell’origine non è pronto, il browser potrebbe mostrare errori oppure Cloudflare potrebbe rifiutare la connessione. È una brutta sorpresa nel giorno del lancio.

Le impostazioni di sicurezza di base dovrebbero essere il passo successivo. Se ti interessa già la sicurezza del sito, è qui che Cloudflare comincia ad aiutare oltre il DNS. Parti dai controlli più ovvi e poi testa di nuovo il sito. Le regolazioni aggressive possono aspettare finché non sai che la configurazione di base funziona correttamente.

Anche il comportamento della cache merita un primo sguardo accurato. Una pagina che cambia spesso non dovrebbe essere trattata allo stesso modo di una pagina che cambia di rado. Se hai dubbi, mantieni prima il comportamento predefinito, osserva come risponde il sito e poi fai una modifica alla volta.

Un’abitudine utile è distinguere tra “sicuro subito” e “migliore in seguito”. Sicuro subito significa impostare correttamente il percorso SSL e confermare che il sito si apra ancora. Migliore in seguito significa ottimizzare gli header della cache o irrigidire le regole dopo aver avuto log da consultare. Questo ordine evita disservizi autoinflitti.

Mantieni questa fase piccola. Le modifiche piccole sono più facili da annullare.

8. Verifica i casi limite: email, sottodomini, redirect e problemi di mixed content

Qui molti siti inciampano. L’email dipende di solito da record DNS che dovrebbero restare solo DNS. Verifica che i record MX puntino ancora all’host di posta corretto e che i record TXT per SPF, DKIM o DMARC siano stati preservati. Se la posta si blocca, il sito può sembrare perfettamente funzionante mentre i messaggi aziendali spariscono.

I sottodomini meritano una checklist propria. Un hostname di staging, un host immagini e un endpoint di upload possono richiedere trattamenti diversi. Se uno di questi è stato proxato per errore, potresti vedere comportamenti strani solo su quell’hostname. Quel tipo di bug fa perdere tempo perché la homepage funziona.

Anche i redirect possono rivelare errori. Se il vecchio sito inviava i visitatori da un hostname a un altro, testa di nuovo quel percorso dopo il passaggio. Una catena di redirect che prima funzionava potrebbe ora puntare a un hostname mai aggiunto a Cloudflare. Un solo record mancante può rompere l’intero percorso.

I problemi di mixed content compaiono quando il sito carica alcune risorse via HTTP mentre la pagina stessa viene servita in HTTPS. I browser non gradiscono questa combinazione. Le immagini possono sparire, gli script possono fallire e un modulo può smettere di inviare dati. Correggi gli URL alla fonte, a livello di applicazione, non solo nel browser.

Se il tuo dominio supporta un flusso di assistenza al sito dopo il lancio, tieni un elenco breve degli host più fragili: posta, staging, upload, redirect e verifica di terze parti. Sono queste le cinque aree in cui di solito compaiono i primi ticket.

Un ultimo controllo pratico: prova il sito da una rete che non usi normalmente. Una connessione mobile può far emergere un problema di cache o un ritardo DNS che la rete dell’ufficio nasconde. Percorsi diversi rivelano problemi diversi.

E se stai collegando un sito che ha già esigenze operative rigide, documenta ogni record DNS che hai toccato. Non dopo. Adesso.