Pourquoi la boucle se produit-elle exactement ?

Une boucle de redirection derrière Cloudflare™ suit presque toujours le même schéma : le visiteur demande https://exemple.com, Cloudflare rejoint votre serveur d'origine en HTTP (c'est le comportement du mode SSL/TLS « Flexible »), l'origine répond qu'elle force le HTTPS par une 301, et la requête repart vers https://exemple.com... que Cloudflare resservira de nouveau en HTTP vers l'origine. Le navigateur s'arrête après environ 20 allers-retours et affiche l'erreur.

Ce schéma n'existait pas avant l'activation du proxy : en direct, le navigateur parlait déjà en HTTPS au serveur. C'est l'introduction d'un intermédiaire qui décale la perception du protocole, et c'est pourquoi le problème apparaît systématiquement « après avoir mis Cloudflare ».

Les cinq causes classiques, de la plus fréquente à la plus sournoise

  • Mode SSL/TLS « Flexible » : Cloudflare rejoint l'origine en HTTP, l'origine force le HTTPS, boucle. C'est la cause n°1, et elle est renforcée par le fait que Cloudflare propose Flexible « pour que ça marche vite » au moment de l'ajout de la zone.
  • Double redirection HTTPS : « Always Use HTTPS » côté Cloudflare et une règle .htaccess / bloc Nginx qui force aussi le HTTPS. Chaque couche renvoie l'autre vers l'URL qu'elle vient de quitter.
  • Règles de redirection conflictuelles : une Redirect Rule Cloudflare (par exemple racine vers www) qui coexiste avec une redirection équivalente côté origine, ou une Page Rule héritée oubliée.
  • URLs de base incorrectes dans le CMS : WordPress, PrestaShop et consorts stockent l'URL du site en base ; si elle diffère (http vs https, www vs non-www) de l'URL réellement servie, l'application redirige à chaque requête.
  • 301 mémorisées de part et d'autre : les navigateurs cachent les 301 jusqu'à un an, et une ancienne redirection erronée peut donc « survivre » à sa propre correction côté serveur.

Le protocole de résolution, étape par étape

  1. Observez la chaîne de redirection réelle. En ligne de commande, sans cache : 
    curl -sIL https://www.exemple.com/ | grep -iE "HTTP/|location"
    Si vous voyez la même URL réapparaître dans les en-têtes Location, la boucle est confirmée et vous voyez à quel maillon elle alterne http/https ou www/non-www.
  2. Passez le mode SSL/TLS en Full (strict). Dans SSL/TLS > Overview, choisissez Full (strict) et déployez un certificat valide sur l'origine (Let's Encrypt, ou un Origin Certificate Cloudflare gratuit de 15 ans). C'est le réglage qui élimine la cause n°1.
  3. Choisissez UN endroit où forcer le HTTPS. Soit « Always Use HTTPS » chez Cloudflare et aucune règle de forçage côté origine, soit l'inverse. Si l'origine est un CMS, la règle d'origine est souvent plus intrusive à neutraliser ; le plus simple est de laisser Cloudflare faire.
  4. Auditez toutes les couches de redirection. Redirect Rules et Bulk Redirects côté Cloudflare, puis .htaccess/nginx.conf et configuration de l'application côté origine. Chaque couche qui force la même chose doit être réduite à une seule. Notre guide sur les redirections en masse chez Cloudflare détaille le bon ordre de priorité.
  5. Alignez les URLs déclarées par l'application. WordPress : Réglages > Général (siteurl/home). PrestaShop : URL de la boutique dans les paramètres. Shopify et les SaaS gèrent cela eux-mêmes, mais vérifiez le domaine principal déclaré.
  6. Cassez le cache avant de conclure. Testez systématiquement en fenêtre privée ou avec curl, purgez le cache Cloudflare (Caching > Purge), et faites vider le cache de leur navigateur aux utilisateurs qui ont vu la boucle : leur machine rejoue peut-être une 301 qui n'existe plus.

Les erreurs qui font réapparaître la boucle

  • Garder Flexible « parce que ça marche » : le site peut sembler fonctionner si l'origine ne force pas HTTPS, mais chaque page est servie en HTTP entre Cloudflare et l'origine, et le moindre forçage côté application fait basculer le site en boucle. Flexible est un différé, pas un correctif.
  • Corriger sans purger : la configuration serveur est corrigée, mais le test se fait dans un navigateur qui rejoue une 301 mémorisée. La boucle « résiste » alors qu'elle a disparu côté serveur, et le diagnostic repart de zéro.
  • Oublier www vs non-www : la boucle ne concerne pas toujours le protocole. Un site servi sur exemple.com qui redirige www vers la racine, combiné à une règle Cloudflare qui fait l'inverse, boucle indéfiniment sur les deux hôtes.
  • Empiler les règles de redirection au fil des incidents : une Page Rule de 2019, une Redirect Rule de 2024 et un .htaccess hérité se composent en chaîne. Une passe d'audit complète est moins coûteuse que le prochain incident.

Questions fréquentes

Pourquoi la boucle de redirection n'apparaît-elle que sur certains navigateurs ?

Parce que la boucle repose sur des redirections 301 mises en cache localement. Un navigateur qui a déjà mémorisé une ancienne 301 rejoue la redirection sans même contacter le serveur, tandis qu'une fenêtre privée ou curl voit la configuration réelle. Testez en navigation privée avant de retoucher à la configuration : le problème n'existe peut-être déjà plus côté serveur.

Faut-il laisser le mode SSL Flexible pour que le site fonctionne ?

Non, c'est l'inverse : Flexible est la cause la plus fréquente de la boucle. Cloudflare rejoint alors l'origine en HTTP, l'origine répond par une 301 vers HTTPS, et la requête repart en boucle. La configuration correcte est Full (strict) avec un certificat valide sur l'origine, déployable gratuitement, y compris sur un plan Free.

Faut-il forcer le HTTPS chez Cloudflare, sur le serveur, ou les deux ?

À un seul endroit. Si l'origine force déjà le HTTPS, « Always Use HTTPS » côté Cloudflare ajoute une couche de redirection qui peut boucler avec la première. Choisissez l'endroit le plus simple à faire évoluer (en général Cloudflare) et neutralisez l'autre.

Pourquoi la boucle persiste après la correction ?

À cause du cache. Les 301 sont mémorisées par les navigateurs jusqu'à un an et parfois mémorisées à l'edge. Purgez le cache Cloudflare, testez en fenêtre privée ou avec curl -I, et communiquez aux utilisateurs déjà impactés qu'ils doivent vider leur cache ou réessayer plus tard.

Votre site tourne en boucle depuis l'activation du proxy ?

CF Garage remonte la chaîne de redirection maillon par maillon, remet le mode SSL/TLS en ordre et supprime les redirections en doublon. Tarif fixe, communication écrite, garantie de satisfaction.

Découvrir les tarifs & commander

Ressources et guides complémentaires