Pourquoi deux réglages décident de tout
Cloudflare se branche en quelques clics, et c'est précisément pour cela qu'on le laisse tel quel. Or deux pannes coûtent un client. La première touche le chiffrement : en mode Flexible, Cloudflare parle en HTTP clair à l'origine ; si l'origine redirige déjà tout vers HTTPS, la requête repart en boucle et le navigateur affiche ERR_TOO_MANY_REDIRECTS. La seconde touche le cache : dès qu'une règle trop large rend du HTML éligible, une page personnalisée peut être servie à un autre visiteur. La réponse n'est pas de désactiver Cloudflare, mais de répartir les rôles. L'agence tient la relation client et les réglages de la zone ; l'hébergeur tient l'origine, c'est-à-dire un certificat valide, les redirections et les en-têtes de cache.
Ce que ce réglage standard vous évite
- Boucle de redirection — le mode Flexible combiné à une redirection HTTP vers HTTPS sur l'origine, que le navigateur signale par ERR_TOO_MANY_REDIRECTS.
- Page connectée servie à un autre visiteur — une règle « tout mettre en cache » sans exception pour le panier, le compte ou l'administration.
- Back-office figé — l'administration affiche une ancienne version parce qu'une réponse dynamique a été conservée.
- Erreurs 525 et 526 — le handshake TLS échoue ou le certificat d'origine ne passe pas la validation, dès que vous basculez en Full ou Full (strict).
- Chiffrement de façade — en Flexible, le visiteur voit le cadenas alors que le tronçon entre Cloudflare et l'origine circule en clair.
- Réglages différents d'un site à l'autre — une liste d'étapes unique remplace les décisions prises au cas par cas, donc les oublis.
Prérequis à vérifier avant de toucher à la zone
Quatre points, aucun ne se devine. Un certificat valide à l'origine : non expiré, non révoqué, au nom du site, avec la chaîne complète (certificat final et intermédiaires). La documentation Cloudflare accepte un certificat d'une autorité publique comme Let's Encrypt, ou un certificat Cloudflare Origin CA, qui ne vaut toutefois que tant que l'enregistrement reste proxifié. Le port 443 ouvert vers l'origine, avec SNI pris en charge. Un accès à la zone DNS du client. Enfin la liste des URL dynamiques du site : administration, panier, paiement, compte.
Sur un hébergement ServOrbit, le certificat SSL Let's Encrypt est inclus, avec un renouvellement automatique : l'origine remplit donc le premier point, et le mode Full (strict) devient possible. Le contrôle de renouvellement derrière le proxy figure dans la dernière étape.
Les modes SSL/TLS de Cloudflare, de Off à Full (strict)
Faites défiler le tableau
| Mode | Entre Cloudflare et l'origine | Verdict pour un site client |
|---|---|---|
| Off | Tout circule en HTTP clair, des deux côtés. | À proscrire. |
| Flexible | Le visiteur peut utiliser HTTPS ; le trajet de Cloudflare vers l'origine n'est pas chiffré. | Dépannage temporaire. Boucle assurée si l'origine redirige vers HTTPS. |
| Full | HTTPS vers l'origine, sans validation du certificat : un certificat auto-signé ou invalide est accepté. | Palier de transition, le temps de corriger le certificat. |
| Full (strict) | HTTPS avec validation du certificat d'origine (autorité publique ou Origin CA). | Cible standard de tous vos sites. |
| Automatic SSL/TLS | Le recommandeur choisit le mode le plus sûr que l'origine supporte, sans jamais en choisir un moins sûr. | Réglage par défaut : fixez tout de même le mode explicitement pour savoir ce qui s'applique. |
Ordre d'opérations sans coupure
Contrôlez le certificat de l'origine
Depuis votre poste, interrogez l'origine directement avec son adresse (IP_ORIGINE est un modèle à remplacer) :
openssl s_client -connect IP_ORIGINE:443 -servername mondomaine.com </dev/null | openssl x509 -noout -subject -datesLe sujet doit porter le nom du site et les dates doivent encadrer aujourd'hui. Complétez par
curl -sI --resolve mondomaine.com:443:IP_ORIGINE https://mondomaine.com/: une réponse HTTP valide prouve que le certificat est accepté.Relevez les redirections de l'origine
Testez le port 80 de l'origine :
curl -sI --resolve mondomaine.com:80:IP_ORIGINE http://mondomaine.com/. Si la réponse contient un en-tête Location vers https://, l'origine redirige tout vers HTTPS. C'est la cause de la boucle en mode Flexible, et ce n'est pas un défaut : c'est un bon réglage d'origine.Gardez l'enregistrement en DNS seul
Tant que les deux contrôles précédents ne sont pas verts, le proxy reste désactivé sur l'enregistrement. Le trafic va directement à l'origine, comme avant.
Passez le mode SSL/TLS en Full (strict)
Dans le tableau de bord de la zone, ouvrez SSL/TLS, Vue d'ensemble, puis choisissez le mode personnalisé Full (strict). Tant que l'enregistrement n'est pas proxifié, rien ne change pour le visiteur.
Activez le proxy en dernier
Passez l'enregistrement A, AAAA ou CNAME du site en mode proxifié. Le geste, enregistrement par enregistrement, est décrit dans Activer ou couper le proxy Cloudflare d'un enregistrement DNS.
Imposez HTTPS à la périphérie
Une fois en Full (strict), activez « Always Use HTTPS » ou une règle de redirection côté Cloudflare, et retirez si possible la redirection côté origine : la documentation Cloudflare cite ce choix parmi les remèdes à la boucle.
Contrôlez le résultat
Lancez
curl -sI https://mondomaine.com/: vous attendez une réponse 200 ou la redirection prévue, et l'en-tête server: cloudflare. Vérifiez aussi que le renouvellement du certificat d'origine passe encore derrière le proxy : l'hébergeur documente le renouvellement automatique, pas son comportement derrière Cloudflare. Relisez la date de fin du certificat avec l'étape 1 après le prochain renouvellement, et revenez en Full si le certificat expire. Passez ensuite à la section cache avant de déclarer le site livré.
Ce que Cloudflare met en cache par défaut, et où le risque apparaît
Cloudflare décide du cache d'après l'extension du fichier, pas d'après son type MIME : archives, images, vidéos, polices, documents, feuilles CSS et scripts JS sont éligibles. La documentation précise que le CDN ne met pas en cache le HTML ni le JSON par défaut. Elle ajoute qu'il ne conserve pas une réponse accompagnée d'un en-tête Set-Cookie, ni une réponse dont Cache-Control vaut private, no-store, no-cache ou max-age=0, ni une requête qui n'est pas en GET. Le risque apparaît donc le jour où quelqu'un ajoute une règle de cache sur tout le site. Cette règle rend le HTML éligible, et si l'origine ne signale rien, une page de panier ou de compte peut rejoindre le cache.
Chemins à ne jamais laisser en cache sur un site dynamique
- Administration et connexion —
/wp-adminet/wp-login.phppour WordPress, ou l'équivalent de votre CMS. - Panier et paiement —
/cart,/checkoutet leurs variantes traduites sur une boutique WooCommerce. - Compte client —
/my-accountet toute page qui affiche des données propres au visiteur. - Cookies de session — par exemple
wordpress_logged_in_ouwoocommerce_items_in_cart: une requête qui les porte doit toujours aller à l'origine. - Prévisualisations — les URL avec
?preview=true, que seul l'auteur connecté doit voir. - API authentifiées —
/wp-jsonquand la réponse dépend de l'utilisateur connecté.
Créer la règle de contournement avec les Cache Rules
Ouvrez les Cache Rules
Dans la zone, ouvrez Caching puis Cache Rules, et créez une règle. Les Cache Rules exigent que l'enregistrement du domaine ou du sous-domaine soit proxifié.
Écrivez le filtre
Choisissez Edit expression et saisissez, en l'adaptant à votre CMS :
(http.request.uri.path contains "/wp-admin") or (http.request.uri.path contains "/wp-login.php") or (http.request.uri.path contains "/cart") or (http.cookie contains "wordpress_logged_in_")Choisissez Bypass cache
Sous « Then », dans Cache eligibility, sélectionnez Bypass cache : les requêtes correspondantes ne sont plus éligibles au cache.
Placez et testez la règle
Choisissez son rang avec « Place at », enregistrez, puis utilisez le Rules simulator de Cloudflare pour vérifier que la règle se déclenche bien sur une URL d'administration ou de panier.
Vérifier le cache réellement appliqué
Une règle bien écrite ne prouve rien tant qu'on n'a pas lu la réponse. L'en-tête cf-cache-status dit ce que Cloudflare a fait de chaque requête. Pour l'administration : curl -sI https://mondomaine.com/wp-admin/ | grep -i cf-cache-status. Pour une page avec un cookie de connexion simulé : curl -sI -H "Cookie: wordpress_logged_in_test=1" https://mondomaine.com/ | grep -i cf-cache-status. Sur ces deux URL, la valeur ne doit jamais être HIT. Faites aussi le test sur une page publique, deux fois de suite, pour voir passer un MISS puis un HIT si vous avez choisi de la mettre en cache.
Lire les valeurs de cf-cache-status
- HIT — la ressource a été trouvée dans le cache de Cloudflare et servie depuis celui-ci.
- MISS — la réponse était éligible, mais absente du cache à cet instant : l'origine l'a servie.
- EXPIRED — une copie existait mais elle était périmée ; l'origine a servi une réponse fraîche.
- BYPASS — la requête pouvait être mise en cache, mais la réponse de l'origine ne l'était finalement pas.
- DYNAMIC — Cloudflare a jugé à la requête que la ressource n'est pas éligible et a interrogé l'origine directement.
- REVALIDATED — l'origine a confirmé par une requête conditionnelle que la copie en cache était toujours valable.
- STALE — une copie périmée a été servie parce que l'origine n'a pas pu être jointe.
Dépannage : les erreurs qui reviennent
Cinq symptômes couvrent la plupart des appels de clients après une mise derrière Cloudflare. Pour chacun, la documentation Cloudflare décrit la cause ; la correction se joue presque toujours à l'origine, donc chez l'hébergeur, ou dans le mode SSL/TLS de la zone.
- ERR_TOO_MANY_REDIRECTS (Chrome), « La page ne redirige pas correctement » (Firefox) — cause : mode Flexible et origine qui redirige HTTP vers HTTPS. Remède : passer en Full ou Full (strict), ce qui exige un certificat d'origine, ou retirer la redirection côté origine et imposer HTTPS à la périphérie. Vérifiez aussi « Always Use HTTPS », HSTS et les règles de redirection qui se contredisent.
- Erreur 525, SSL handshake failed — le handshake TLS échoue alors que la zone est en Full ou Full (strict). Causes citées : aucun certificat valide installé, port 443 fermé, SNI non pris en charge, suites de chiffrement incompatibles. Remède : rejouer l'étape 1 et consulter le journal d'erreurs nginx ou Apache de l'origine.
- Erreur 526, invalid SSL certificate — en Full (strict), Cloudflare ne peut pas valider le certificat d'origine : expiré, révoqué, mauvais nom ou chaîne incomplète, l'origine devant servir le certificat final et les intermédiaires. Repli temporaire : Full, le temps de corriger.
- Erreurs 521 et 522, web server is down et connection timed out — ce ne sont pas des erreurs de certificat : l'origine est hors service ou ne répond pas à temps. Vérifiez le pare-feu de l'origine, puis transmettez à l'hébergeur le code, l'heure avec son fuseau et l'URL touchée.
- Panier ou compte d'un visiteur vu par un autre — une règle de cache trop large. Désactivez-la, ajoutez la règle de contournement, purgez le cache, puis relisez cf-cache-status sur les chemins sensibles.
Le retour arrière, avant qu'on vous le demande
Notez l'état de départ : mode SSL/TLS, enregistrements proxifiés, règles existantes. Si le site se dégrade après la bascule, repassez l'enregistrement en DNS seul : le trafic retourne directement à l'origine. Un piège : un certificat Cloudflare Origin CA n'est reconnu que par Cloudflare, et la documentation avertit qu'en coupant le proxy le visiteur voit une erreur de certificat non fiable. Gardez donc un certificat d'une autorité publique à l'origine.
Qui tient quoi, et par où continuer
Une fois la liste rodée, elle tient sur une page par site : certificat contrôlé, Full (strict), proxy activé, règle de contournement testée, cf-cache-status relu. Le partage reste simple : à l'agence la zone du client et ses réglages, à l'hébergeur l'origine. Pour les gestes voisins, voyez Activer le DNS managé Cloudflare sur un domaine, et Migrer un site WordPress client sans coupure si le site change d'origine avant d'être placé derrière Cloudflare.
