CF GarageCe qui change quand WordPress passe derrière le proxy
WordPress mélange trois types de trafic qui exigent des traitements opposés : les consultations anonymes (cachables), les sessions authentifiées (jamais cachées) et l'automatisation à fort volume comme xmlrpc.php et wp-login.php (à limiter en débit). Une configuration Cloudflare qui les traite pareil produit les symptômes classiques : pages d'admin qui déconnectent, paniers qui se vident, ou hit ratio bloqué près de zéro.
Configurer pas à pas
Étape 1 : régler SSL/TLS sur Full (strict). Dans SSL/TLS > Overview, choisissez Full (strict). Le mode Flexible fait récupérer l'origine en HTTP clair par l'edge et est la cause numéro un des boucles de redirection WordPress (ERR_TOO_MANY_REDIRECTS) et des avertissements de contenu mixte. Installez un certificat d'origine gratuit ou un Let's Encrypt valide sur le serveur.
Étape 2 : contourner le cache pour le trafic authentifié. Ajoutez une Cache Rule : quand la requête correspond aux chemins wp-admin ou porte un cookie de connexion WordPress (Cookie contains "wordpress_logged_in"), réglez l'éligibilité au cache sur Bypass. Les pages anonymes restent cachables, les rédacteurs connectés ont un site vivant.
Étape 3 : cacher le reste avec insistance. Allongez les TTL edge et navigateur des fichiers statiques de /wp-content/. WordPress versionne les fichiers statiques par nom de fichier quand vous utilisez un plugin d'optimisation : les TTL longs sont sûrs. Cette seule règle fait typiquement passer le hit ratio de quasi zéro à 80-95 %, comme détaillé dans notre guide sur le diagnostic du cache et du hit ratio.
Étape 4 : protéger la connexion et xmlrpc. wp-login.php et xmlrpc.php absorbent un bruit constant de brute force. Une règle de Rate Limiting sur ces chemins précis (quelques requêtes par minute et par IP, action Managed Challenge) nettoie le trafic sans toucher les vrais rédacteurs. Pour aller plus loin sur les formulaires, les motifs de notre guide sur les créations de comptes abusives et le brute force s'appliquent tels quels.
Étape 5 : IPs réelles et stratégie de purge. Assurez-vous que WordPress voit les IP visiteurs (Cloudflare transmet CF-Connecting-IP ; un plugin ou la config serveur la traduit) pour que les plugins de sécurité ne bannissent pas les IP Cloudflare. Et planifiez la purge avant chaque mise à jour de thème : WordPress ne signale pas les changements de contenu à l'edge à moins que votre plugin de cache ne parle à l'API Cloudflare.
Les erreurs fréquentes sur WordPress
- Le SSL Flexible « pour que ça marche ». Il masque le vrai problème (pas de certificat à l'origine) et crée des boucles avec les configurations de redirection typiques. Full (strict) est le bon réglage.
- Repasser les enregistrements A en DNS only pour « réparer » le cache. Cela supprime toutes les protections et l'accélération. Corrigez les cache rules à la place.
- Bloquer sans exempter les bots vérifiés. Un filtrage agressif qui ignore
cf.client.botrisque le blocage des crawlers ; notre guide sur le blocage accidentel de Googlebot couvre la récupération. - Laisser
xmlrpc.phpgrand ouvert. Sauf si un plugin en dépend, limitez-le en débit ou bloquez-le : c'est l'amplificateur favori du password spraying. - Oublier la proxification après un basculement staging. Un enregistrement en DNS only expose l'IP du serveur et court-circuite toutes les règles.
Questions fréquentes
Le cache Cloudflare casse-t-il les connexions ou les paniers ?
Pas quand la règle de contournement couvre les chemins admin et les cookies de session. Les casses viennent d'un cache HTML appliqué aveuglément, qui sert la session d'un visiteur à un autre. Séparez anonyme et authentifié, et les deux problèmes disparaissent.
Faut-il encore un plugin de cache avec Cloudflare ?
Ils font des métiers différents : le plugin gère le cache de pages côté serveur et purge à la publication, Cloudflare cache au bord du réseau. Beaucoup de sites utilisent les deux ; décidez délibérément quelle couche possède le cache de pages.
Pourquoi une boucle de redirection après l'activation de Cloudflare ?
Presque toujours Flexible SSL combiné à une configuration WordPress ou serveur qui force le HTTPS. L'edge récupère en HTTP, l'origine redirige vers HTTPS, et la boucle tourne. Full (strict) la casse instantanément.
Faut-il limiter wp-login.php en débit ?
Oui. C'est l'endpoint le plus attaqué de WordPress. Quelques requêtes par minute et par IP avec une action Managed Challenge arrêtent le bruit sans gêner les rédacteurs réels.