2026年11月12日

Configurare Cloudflare su WordPress: nameserver, SSL, IP reale, WAF

Sicurezza

Questo articolo è un'edizione localizzata dell'originale giapponese. Leggi l'originale in giapponese

Installare Cloudflare su WordPress richiede, in ordine: ① aggiungere il sito a Cloudflare e cambiare i nameserver del dominio, ② impostare la modalità di crittografia SSL/TLS su Full (strict), ③ ripristinare sul server l'IP reale del visitatore, ④ proteggere la pagina di login con una regola personalizzata del WAF. Anche il piano gratuito include CDN, SSL, protezione DDoS e regole personalizzate (fino a 5).

In questo articolo trovi ogni impostazione e i controlli da fare dopo il cambio. I nomi e la disposizione delle schermate di Cloudflare possono cambiare, quindi qui ci basiamo sulla documentazione ufficiale (developers.cloudflare.com) a novembre 2026.

Cosa decidere prima di iniziare

La gestione del DNS passa a Cloudflare. Il registrar del dominio non cambia, ma i record DNS si modificano dalla schermata di Cloudflare.
I record DNS della posta (MX e simili) non vanno messi in proxy. Cloudflare gestisce solo il traffico web (HTTP/HTTPS).
Verifica che l'origine (il server su cui sta WordPress) abbia un certificato SSL valido. Se HTTPS funziona già, per esempio con Let's Encrypt, va bene così.
Se hai attivato DNSSEC presso il registrar, disattivalo prima di cambiare i nameserver. Un vecchio record DS rimasto fa fallire la risoluzione dei nomi.

Passo 1: aggiungi il sito e cambia i nameserver

Crea un account Cloudflare e aggiungi il dominio dalla dashboard. Puoi scegliere il piano Free.
Cloudflare legge gli attuali record DNS e li elenca: controlla che non manchi nulla. Alcuni record non vengono letti, quindi confrontali con la schermata di gestione DNS attuale e aggiungi a mano quelli mancanti.
Per i record A (oppure AAAA, CNAME) del sito web attiva lo stato proxy (nuvola arancione). Per MX e per i record A del server di posta, disattivalo (solo DNS, nuvola grigia).
Cloudflare mostra due nomi di nameserver, nella forma 〇〇.ns.cloudflare.com, assegnati a ciascun account. Usa i due che compaiono nella tua schermata, non quelli scritti in altri articoli.
Nel pannello del registrar del dominio, cambia i nameserver con quei due.

Per verificare se il cambio è avvenuto, usa questi comandi. La propagazione può richiedere alcune ore.

# I nameserver sono i due di Cloudflare?
dig NS example.com +short

# Il traffico passa da Cloudflare? (vengono restituiti server: cloudflare e cf-ray)
curl -sI https://example.com | grep -iE '^(server|cf-ray):'

Quando lo stato del dominio nella schermata di Cloudflare diventa attivo (Active), il passaggio è completo.

Passo 2: imposta SSL/TLS su Full (strict)

In SSL/TLS di Cloudflare esistono modalità che stabiliscono come criptare la comunicazione tra visitatore e Cloudflare e tra Cloudflare e origine.

Modalità	Tra Cloudflare e origine	Uso con WordPress
Off	Nessuna crittografia	Da non usare
Flexible	HTTP (senza crittografia)	Da non usare. Causa loop di reindirizzamento e contenuti misti
Full	HTTPS (il certificato non viene verificato)	Soluzione temporanea finché non hai un certificato
Full (strict)	HTTPS (il certificato viene verificato)	È quella da usare

La modalità si cambia nella pagina Overview di SSL/TLS della dashboard di Cloudflare. L'opzione predefinita «Automatic SSL/TLS» sceglie automaticamente la modalità più sicura che l'origine supporta. Scegliendo tu stesso Full (strict), il sito non può funzionare in una modalità non voluta. Per l'origine puoi usare il certificato di un'autorità pubblica (come Let's Encrypt) oppure un certificato Origin CA emesso da Cloudflare.

Ecco perché evitare Flexible. Con Flexible la richiesta arriva all'origine in HTTP, quindi WordPress o il server rispondono «è arrivata in HTTP, reindirizzo a HTTPS», Cloudflare torna a chiedere all'origine in HTTP e il ciclo si ripete (il browser mostra ERR_TOO_MANY_REDIRECTS). Con Full (strict) la richiesta arriva all'origine anche in HTTPS, quindi in WordPress non serve codice aggiuntivo che legga X-Forwarded-Proto e riscriva $_SERVER['HTTPS'].

Controlla inoltre che in «Impostazioni» → «Generali» (Settings → General) gli indirizzi «Indirizzo WordPress (URL)» e «Indirizzo del sito (URL)» inizino con https://. Se immagini e altre risorse restano su http://, vedi come risolvere i contenuti misti.

Passo 3: ripristina l’IP reale del visitatore

Passando da Cloudflare, l'origine della connessione che arriva al server (REMOTE_ADDR) diventa un indirizzo IP di Cloudflare. In questo stato log degli accessi, IP dei commenti e plugin che limitano i tentativi di login trattano tutti i visitatori come se fossero un IP di Cloudflare. Cloudflare passa l'IP del visitatore nell'header CF-Connecting-IP, quindi configura il server in modo che si fidi di quell'header solo quando la connessione arriva da Cloudflare.

Se riscrivi REMOTE_ADDR con il valore dell'header senza controllare la provenienza, chi accede direttamente all'origine senza passare da Cloudflare può dichiarare l'IP che vuole tramite l'header. Per questo motivo non usare il codice, presente in articoli datati, che si limita ad assegnare a REMOTE_ADDR il valore di HTTP_CF_CONNECTING_IP se esiste.

L'elenco degli indirizzi IP di Cloudflare è pubblicato su https://www.cloudflare.com/ips/. L'elenco può cambiare, quindi rivedilo periodicamente.

Con Nginx

Usa ngx_http_realip_module. Nel blocco http o server elenca tutti gli intervalli di Cloudflare.

# Intervalli IP di Cloudflare (a novembre 2026; l'elenco aggiornato è su cloudflare.com/ips)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;

sudo nginx -t && sudo systemctl reload nginx

Con Apache (Debian / Ubuntu)

Usa mod_remoteip. Crea /etc/apache2/conf-available/remoteip.conf ed elenca gli intervalli di Cloudflare in RemoteIPTrustedProxy.

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32

sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

Per scrivere l'IP reale nel log degli accessi, in LogFormat (combined) di /etc/apache2/apache2.conf sostituisci %h con %a.

Se non puoi cambiare la configurazione del server (wp-config.php)

Se usi un hosting condiviso e non puoi toccare la configurazione del server web, fai lo stesso controllo in wp-config.php. Mettilo prima della riga require_once ABSPATH . 'wp-settings.php';. Il valore di CF-Connecting-IP (se è un indirizzo IP valido) viene usato solo quando la connessione arriva da un intervallo di Cloudflare.

<?php
// Usa CF-Connecting-IP come IP del visitatore solo se la connessione passa da Cloudflare
$cf_ranges = [
    '173.245.48.0/20', '103.21.244.0/22', '103.22.200.0/22', '103.31.4.0/22',
    '141.101.64.0/18', '108.162.192.0/18', '190.93.240.0/20', '188.114.96.0/20',
    '197.234.240.0/22', '198.41.128.0/17', '162.158.0.0/15', '104.16.0.0/13',
    '104.24.0.0/14', '172.64.0.0/13', '131.0.72.0/22',
    '2400:cb00::/32', '2606:4700::/32', '2803:f800::/32', '2405:b500::/32',
    '2405:8100::/32', '2a06:98c0::/29', '2c0f:f248::/32',
];

function cf_ip_in_range(string $ip, string $cidr): bool
{
    [$net, $bits] = explode('/', $cidr);
    $ip_bin  = inet_pton($ip);
    $net_bin = inet_pton($net);
    if ($ip_bin === false || $net_bin === false || strlen($ip_bin) !== strlen($net_bin)) {
        return false;
    }
    $bits  = (int) $bits;
    $bytes = intdiv($bits, 8);
    if ($bytes > 0 && substr($ip_bin, 0, $bytes) !== substr($net_bin, 0, $bytes)) {
        return false;
    }
    $rest = $bits % 8;
    if ($rest === 0) {
        return true;
    }
    $mask = (0xFF << (8 - $rest)) & 0xFF;
    return (ord($ip_bin[$bytes]) & $mask) === (ord($net_bin[$bytes]) & $mask);
}

if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']) && !empty($_SERVER['REMOTE_ADDR'])) {
    foreach ($cf_ranges as $range) {
        if (cf_ip_in_range($_SERVER['REMOTE_ADDR'], $range)) {
            $visitor = filter_var($_SERVER['HTTP_CF_CONNECTING_IP'], FILTER_VALIDATE_IP);
            if ($visitor !== false) {
                $_SERVER['REMOTE_ADDR'] = $visitor;
            }
            break;
        }
    }
}

In wp-config.php c'è già <?php all'inizio, quindi non copiare la prima riga <?php e incolla dalla seconda riga in poi. Prima di incollare, fai un backup di wp-config.php.

Passo 4: proteggi la pagina di login con una regola personalizzata del WAF

Le regole personalizzate del WAF di Cloudflare si possono creare fino a 5 nel piano gratuito e permettono di scegliere azioni diverse da Log (Block, Managed Challenge e così via). Per crearle, nella pagina Security rules della dashboard scegli «Create rule» → «Custom rules», indica la condizione (Field, Operator, Value) e l'azione, quindi premi «Deploy».

Esempio 1: aprire login e amministrazione solo al tuo IP

È l'esempio per chi ha un IP fisso a casa o in ufficio. Come espressione si scrive così (sostituisci 203.0.113.10 e 198.51.100.0/24 con i tuoi IP).

(http.request.uri.path eq "/wp-login.php" or starts_with(http.request.uri.path, "/wp-admin/"))
and http.request.uri.path ne "/wp-admin/admin-ajax.php"
and not ip.src in {203.0.113.10 198.51.100.0/24}

Come azione scegli Block. /wp-admin/admin-ajax.php è escluso dalla condizione perché funzioni delle pagine pubbliche, come i moduli di contatto e lo scroll infinito, possono chiamarlo senza login.

Esempio 2: se non hai un IP fisso, limita per paese con Managed Challenge

(http.request.uri.path eq "/wp-login.php" or http.request.uri.path eq "/xmlrpc.php")
and not ip.src.country in {"JP"}

Per riconoscere il paese si usa ip.src.country (codice di 2 lettere ISO 3166-1). ip.geoip.country degli articoli datati è deprecato. Come azione scegli prima Managed Challenge, controlla negli eventi di sicurezza che non venga fermato traffico legittimo e, se serve, passa a Block. Anche la documentazione di Cloudflare consiglia questo modo di procedere. xmlrpc.php viene usato se pubblichi da Jetpack o da un'app per smartphone, quindi verifica se lo usi prima di inserirlo nella condizione.

Il blocco per paese è una misura di supporto che si aggira con una VPN o simili. Abbinalo all'autenticazione a due fattori e al limite dei tentativi di accesso. Il modo per riconoscere il paese lato Nginx è spiegato in Limitare l'accesso per paese con Nginx GeoIP2.

Passo 5: comportamento predefinito della cache e purge alla pubblicazione

Per impostazione predefinita Cloudflare non mette in cache l'HTML. Mette in cache i file statici stabiliti dall'estensione, come immagini, CSS, JavaScript e font. Non mette in cache nemmeno le risposte che contengono l'header Set-Cookie. Perciò, se non imposti nulla, l'area di amministrazione e la pagina di login non vengono mai messe in cache da Cloudflare.

Se vuoi mettere in cache anche l'HTML, puoi ampliare l'ambito con le Cache Rules, ma in quel caso devi escludere /wp-admin/, /wp-login.php, le anteprime e la visualizzazione per gli utenti loggati. Sbagliando l'esclusione, le schermate riservate agli amministratori potrebbero essere mostrate ad altri, quindi se non sei sicuro è più prudente lasciare le impostazioni predefinite.

Se hai sostituito CSS o immagini e la pagina non cambia, fai il purge (cancellazione) dalle impostazioni della cache nella dashboard. Per fare il purge automatico a ogni pubblicazione o aggiornamento di un articolo, chiama l'API di Cloudflare. Crea prima in Cloudflare un token API con il solo permesso «Cache Purge» e scrivilo come costante in wp-config.php insieme all'ID della zona (mostrato nella pagina di panoramica del dominio).

define( 'CF_ZONE_ID', 'ID-ZONA' );
define( 'CF_API_TOKEN', 'TOKEN-API' );

Metti il codice seguente nel functions.php di un tema figlio oppure in un piccolo plugin tuo (va bene anche Code Snippets).

<?php
// Quando un articolo viene pubblicato o aggiornato, elimina da Cloudflare la cache dell'articolo e della home page
function cf_purge_urls(array $urls): bool
{
    if (!defined('CF_ZONE_ID') || !defined('CF_API_TOKEN')) {
        return false;
    }

    $response = wp_remote_post(
        'https://api.cloudflare.com/client/v4/zones/' . CF_ZONE_ID . '/purge_cache',
        [
            'headers' => [
                'Authorization' => 'Bearer ' . CF_API_TOKEN,
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode(['files' => array_values($urls)]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('Cloudflare purge failed: ' . $response->get_error_message());
        return false;
    }

    $result = json_decode(wp_remote_retrieve_body($response), true);
    return !empty($result['success']);
}

add_action('publish_post', function (int $post_id): void {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    cf_purge_urls([get_permalink($post_id), home_url('/')]);
});

publish_post scatta quando un articolo viene pubblicato e quando un articolo già pubblicato viene aggiornato. L'API purge_cache accetta files, con cui indichi gli URL, ma anche purge_everything, che cancella tutto. Il purge totale obbliga a rileggere anche tutti i file statici, quindi non usarlo a ogni pubblicazione di un articolo.

Cosa controllare dopo il passaggio

Nel risultato di curl -sI compaiono server: cloudflare e cf-ray e nel browser c'è il lucchetto
Riesci a fare il login all'amministrazione, salvare un articolo e caricare un file multimediale
Nei nuovi commenti e nei log degli accessi viene registrato l'IP del visitatore e non quello di Cloudflare
Le email dal modulo di contatto arrivano (il record MX non è in proxy)
Se hai creato una regola personalizzata del WAF, apri wp-login.php da una rete non autorizzata (per esempio la rete mobile dello smartphone) e verifica che compaia un blocco o una challenge

Problemi frequenti

Compare ERR_TOO_MANY_REDIRECTS

Controlla se la modalità SSL/TLS è Flexible. Installa un certificato sull'origine e passa a Full (strict): il problema si risolve.

Non riesco più a entrare nell’amministrazione

È possibile che la condizione della regola personalizzata del WAF non comprenda il tuo IP o il tuo paese. Disattiva temporaneamente la regola dalla dashboard di Cloudflare, controlla negli eventi di sicurezza quale regola ti ha bloccato e poi correggi l'espressione.

Tutti gli accessi sembrano provenire dallo stesso IP

Il ripristino dell'IP reale del Passo 3 non funziona. Con Nginx controlla l'intervallo di set_real_ip_from e real_ip_header, con Apache controlla che remoteip sia attivo.

Riepilogo

Cambia i nameserver con i due assegnati al tuo account e non mettere in proxy i record per la posta come MX
SSL/TLS su Full (strict). Flexible causa loop di reindirizzamento e contenuti misti
L'IP reale si ripristina fidandosi di CF-Connecting-IP solo quando la connessione arriva da un intervallo di Cloudflare
Limita la pagina di login per IP o paese con una regola personalizzata del WAF, iniziando con Managed Challenge per vedere gli effetti
L'HTML per impostazione predefinita non viene messo in cache. Il purge alla pubblicazione si fa con un token API che ha solo il permesso «Cache Purge»