Cloudflare en mode reverse proxy devant votre site, c'est la recette la plus rapide pour ajouter un CDN mondial, du cache statique, un WAF et une protection anti-DDoS L7, sans rien casser côté origine. La plupart des clients qui hébergent un site WordPress, Drupal ou e-commerce chez Datacampus finissent par brancher Cloudflare devant. Le plan gratuit couvre déjà l'essentiel.
Notre recommandation : ne pas transférer toute votre zone DNS
Avant d'enchaîner les étapes, un mot sur notre position côté Datacampus, parce qu'elle diverge souvent de ce que raconte Cloudflare par défaut.
Sur le plan Free, Cloudflare impose un seul mode d'activation : vous changez les nameservers de votre domaine pour pointer vers les leurs, et toute votre zone DNS (A, AAAA, MX, TXT, SRV, CAA…) passe sous leur gestion. Simple à activer, mais vous perdez le contrôle direct de vos enregistrements, vos MX, votre délivrabilité mail, et vous devenez dépendant de leur interface pour la moindre modification DNS.
Sur les plans Business et Enterprise, Cloudflare propose un mode alternatif baptisé CNAME Setup (ou partial DNS) : vous gardez votre zone DNS chez votre registrar ou chez Datacampus, et vous ajoutez simplement un CNAME pointant www.votredomaine.fr vers www.votredomaine.fr.cdn.cloudflare.net. Seul le flux web transite par Cloudflare, le reste de la zone reste maître chez vous.
Si vous préférez rester sur le plan Free — c'est parfaitement légitime pour beaucoup de sites — le reste de cette doc s'applique, avec la contrainte du transfert de zone complet. Prévoyez simplement de bien relire les records importés (MX, TXT de vérification, SPF) avant de basculer les nameservers.
Pourquoi Cloudflare devant son site
- CDN mondial anycast — les assets statiques (images, CSS, JS) sont servis depuis le POP le plus proche du visiteur. Un visiteur à Tokyo ne tape plus jusqu'à Chasseneuil.
- Cache statique — Cloudflare sert les fichiers cachables sans réveiller l'origine. Votre bande passante et votre CPU respirent.
- Anti-DDoS L7 inclus dans le plan gratuit, avec absorption des attaques volumétriques.
- WAF managé de base gratuit, règles custom sur les plans payants.
- Masquage de l'IP d'origine, ce qui complique la vie des scans directs et des bruteforce ciblés.
- TLS gratuit côté visiteur, HTTP/2 et HTTP/3 activables en un clic.
Architecture
Visiteur
│ HTTPS
▼
Cloudflare (POP anycast, TLS, cache, WAF)
│ HTTPS
▼
Origine Datacampus (Plesk, Apache/Nginx, PHP-FPM)Cloudflare termine le TLS visiteur, consulte son cache, applique ses règles (WAF, bot mitigation, redirections), puis relaie la requête à votre origine si nécessaire. L'origine ne voit que des IPs Cloudflare — c'est ce qui masque votre serveur, mais c'est aussi le principal piège à connaître (voir étape 5).
Étape 1 — Ajouter le domaine sur Cloudflare (plan Free)
- Créez un compte sur dash.cloudflare.com.
- Cliquez sur Add a site, saisissez
votredomaine.fr. - Choisissez le plan Free.
- Cloudflare scanne le DNS public et importe automatiquement la zone (A, AAAA, CNAME, MX, TXT, SRV). Relisez la liste ligne par ligne avant de valider : un record oublié et le service qui l'utilisait ne répond plus (mail, vérification domaine, SSO, etc.).
Étape 2 — Changer les nameservers chez le registrar
Cloudflare vous fournit deux nameservers du type xxx.ns.cloudflare.com. Rendez-vous chez votre registrar (Gandi, OVH, Ionos, Namecheap, Dynadot…) et remplacez les nameservers actuels (ceux de Datacampus ou d'un autre hébergeur) par ceux de Cloudflare.
La propagation DNS prend de quelques minutes à 24 heures selon les TTL. Cloudflare envoie un email dès que la bascule est effective. Tant que ce n'est pas fait, votre site continue de répondre comme avant : rien ne casse.
À partir de ce moment, toute modification DNS (créer un sous-domaine, changer un MX, ajouter un TXT pour une vérification Google/Microsoft) se fait côté Cloudflare, plus côté registrar ni côté Datacampus. C'est précisément la contrepartie du plan Free qu'on évoquait plus haut.
Étape 3 — Configurer le mode SSL/TLS
Dans Cloudflare, onglet SSL/TLS > Overview. Le choix du mode est critique.
| Mode | Visiteur → Cloudflare | Cloudflare → Origine | Verdict |
|---|---|---|---|
| Off | HTTP | HTTP | À éviter absolument. |
| Flexible | HTTPS | HTTP | Piège classique. Beaucoup de CMS cassent (boucles de redirection, assets mixtes). À bannir. |
| Full | HTTPS | HTTPS (certificat origine accepté même auto-signé) | Acceptable pour dépanner. |
| Full (strict) | HTTPS | HTTPS (certificat origine valide exigé) | Recommandé. Let's Encrypt sur Plesk côté origine + certificat Cloudflare côté visiteur. |
Sur Plesk, installez d'abord le certificat Let's Encrypt gratuit sur le domaine (voir Let's Encrypt avec Plesk), puis activez Full (strict) sur Cloudflare. Pas l'inverse, sinon vous passez quelques minutes avec le site cassé.
Étape 4 — Activer le proxy orange
Dans DNS > Records, chaque record A ou AAAA a un toggle :
- Nuage orange (Proxied) — le trafic transite par Cloudflare. CDN, cache, WAF actifs.
- Nuage gris (DNS only) — Cloudflare sert uniquement le DNS, le trafic tape directement sur l'IP.
Passez en orange les records qui servent du HTTP/HTTPS : @, www, les sous-domaines web. Laissez en gris tout ce qui n'est pas du web (MX, SMTP d'envoi, enregistrements de vérification pointant vers une IP précise, services VPN, SSH, etc.).
mail., smtp., imap., autodiscover.
Étape 5 — Récupérer la vraie IP visiteur côté origine
Une fois le proxy orange actif, toutes les requêtes qui arrivent sur votre serveur Datacampus viennent d'IPs Cloudflare (104.x.x.x, 172.x.x.x…). Si vous ne faites rien, vos logs Apache, vos stats AWStats, vos scripts de détection d'abus, fail2ban, les plugins de sécurité WordPress, tout voit Cloudflare au lieu du visiteur.
Cloudflare ajoute l'IP réelle dans deux en-têtes : CF-Connecting-IP (le plus fiable) et X-Forwarded-For.
Apache côté Plesk — mod_remoteip
Chez Datacampus, chaque site tourne sous son propre utilisateur Linux (pas www-data). Le module mod_remoteip est disponible. Dans Plesk : Sites Web & Domaines > Apache & nginx Settings > Additional directives for HTTPS :
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22La liste officielle et à jour est sur cloudflare.com/ips. Pensez à ajouter les plages IPv6 si vous servez de l'IPv6. Appliquez la même config en HTTP si vous gardez le port 80 actif pour les redirections.
WordPress
Deux options.
- Plugin officiel Cloudflare — installe le correctif
$_SERVER['REMOTE_ADDR']automatiquement. - Snippet dans
wp-config.php, à placer avant « That's all, stop editing » :
if (!empty($_SERVER['HTTP_CF_CONNECTING_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}Sans cette étape, Wordfence banniera des IPs Cloudflare (catastrophique : un bloc et c'est une partie du monde qui ne voit plus le site), et fail2ban ne pourra plus identifier un attaquant.
Étape 6 — Configurer le cache
Par défaut, Cloudflare cache déjà les extensions statiques courantes (.css, .js, .jpg, .webp, .woff2…). Pour aller plus loin, utilisez les Cache Rules (onglet Caching > Cache Rules).
Schéma type pour un WordPress :
| Règle | Action |
|---|---|
URI Path contient /wp-content/uploads/ | Eligible for cache, Edge TTL 1 mois |
| File extension ∈ {css, js, webp, avif, woff2, svg} | Eligible for cache, Edge TTL 1 mois |
URI Path contient /wp-admin/, /wp-login.php | Bypass cache |
URI Path contient /checkout, /cart, /my-account | Bypass cache |
URI Path contient /.well-known/acme-challenge/ | Bypass cache (voir pièges) |
Pour un site statique pur ou un JAMstack, activez Cache Everything sur la racine avec un TTL court, et purgez sur déploiement via l'API Cloudflare.
Bonnes pratiques, gratuites et immédiates
- Speed > Optimization > Content Optimization : activer Brotli.
- Network : activer HTTP/2, HTTP/3 (QUIC), 0-RTT.
- SSL/TLS > Edge Certificates : activer Always Use HTTPS et Automatic HTTPS Rewrites.
- Security > Bots : activer Bot Fight Mode (filtrage des bots connus, gratuit).
- Security > WAF : laisser les Managed Rules gratuites actives.
- SSL/TLS > Edge Certificates : activer HSTS seulement quand vous êtes sûr de rester en HTTPS (le rollback prend 6 mois de patience chez les visiteurs).
Pièges courants
Le certificat d'origine expire sans qu'on le voie
Depuis un navigateur, tout semble vert : c'est le certificat Cloudflare qui est servi. Pendant ce temps, le Let's Encrypt côté origine a pu expirer, et le jour où vous désactivez le proxy (ou passez en DNS only pour debug), c'est l'avertissement de sécurité. Surveillez l'expiration du certificat Plesk, et gardez les notifications d'expiration activées dans Plesk.
Let's Encrypt HTTP-01 qui échoue
Le renouvellement Let's Encrypt utilise un challenge sur /.well-known/acme-challenge/. Si Cloudflare met en cache ce chemin (cas rare mais possible avec certaines Cache Rules agressives), le challenge échoue. Créez une Cache Rule Bypass cache explicite sur ce chemin, comme indiqué plus haut. Alternative : passer le certificat en DNS-01.
Whitelist d'IPs qui ne marche plus
Vos anciennes règles Require ip dans .htaccess, vos allowlists fail2ban, vos filtres Wordfence ou WP Cerber : tout ce qui se base sur REMOTE_ADDR doit passer par mod_remoteip ou le snippet CF-Connecting-IP. Sinon vous bloquez Cloudflare au lieu des attaquants, ou l'inverse.
Redirections en boucle
Symptôme typique du mode Flexible : l'origine envoie une redirection HTTP → HTTPS, Cloudflare retape en HTTP, boucle. Remède : Full (strict), toujours.
Cookies manquants ou sessions qui sautent
Vérifiez que vos règles de cache ne cachent pas les réponses contenant Set-Cookie (comportement par défaut correct, mais une Cache Rule trop large peut casser ça).
IP d'origine : masquée mais pas secrète
Cloudflare cache votre IP sur les records proxifiés, mais si elle a fuité historiquement — un record direct.votredomaine.fr oublié en gris, une archive DNS (DNSDB, SecurityTrails, Censys), un email SMTP qui expose l'IP serveur dans ses headers — elle reste trouvable. Un attaquant peut alors taper en direct sur l'origine et contourner Cloudflare.
Deux parades :
- IP dédiée côté Datacampus (ticket au ServiceDesk). Vous cloisonnez votre site sur une IP qui ne sert que lui, et vous filtrez sur l'origine pour n'accepter que les plages Cloudflare.
- Authenticated Origin Pulls — Cloudflare signe ses requêtes vers l'origine avec un certificat client, et l'origine rejette toute requête non signée. Combinaison imparable avec la whitelist d'IPs.
Check-list de mise en production
- Certificat Let's Encrypt valide côté Plesk, renouvellement testé.
- SSL/TLS mode en Full (strict).
- Records web en orange, MX en gris, services non-web en gris.
mod_remoteipconfiguré avec les plages Cloudflare à jour.- Plugins de sécurité et fail2ban vérifiés sur une connexion réelle (comparer l'IP vue et l'IP réelle du visiteur).
- Cache Rules testées :
/wp-adminjamais caché,/.well-known/acme-challenge/bypass. - Always Use HTTPS, Brotli, HTTP/3 activés.
- Alerte sur expiration du certificat d'origine.
Pour aller plus loin sur le durcissement côté origine, voir Hardening général et .htaccess essentiels.