WordPress Trop de redirections : corriger les boucles de redirection www/https/Cloudflare

Vous avez modifié « un petit réglage » — peut‑être activé le SSL dans Cloudflare, forcé le HTTPS ou changé le www — et maintenant le site rebondit comme une bille : le navigateur affiche Trop de redirections, la connexion ne tient pas et votre outil de supervision réclame de la poésie.

Les boucles de redirection ne sont presque jamais mystérieuses. Ce sont simplement des systèmes distribués qui font ce que vous leur avez demandé, à quatre endroits différents, dans le mauvais ordre. Déroulons cela avec un diagnostic de niveau production, pas des clics au hasard.

Ce que signifie réellement « Trop de redirections »

Un navigateur demande une URL, reçoit une redirection 301/302/307/308, la suit, et continue à être redirigé jusqu’à atteindre une limite (souvent autour de 20–30 sauts). L’erreur est le navigateur qui se protège d’une boucle infinie. La boucle peut se produire à plusieurs couches :

• Application : WordPress estime qu’il doit utiliser HTTPS ou le www, donc il émet des redirections.
• Serveur web : Des règles de réécriture Nginx/Apache forcent HTTPS ou l’hôte canonique, souvent avec une regex qui capture tout.
• Edge/CDN : Cloudflare « Always Use HTTPS », Transform Rules, Page Rules ou Workers redirigent avant même que l’origine soit consultée.
• Load balancer / reverse proxy : Terminaison TLS + en‑têtes proxy manquants font croire à l’origine que les requêtes sont en HTTP alors que le client utilisait HTTPS.

Les boucles correspondent généralement à l’un de ces schémas :

• Ping‑pong HTTP ↔ HTTPS : l’edge dit « passe en HTTPS », l’origine dit « non, retourne en HTTP ».
• Ping‑pong www ↔ apex : une couche force www, une autre force non‑www.
• Conflit schéma + hôte : HTTPS non‑www → HTTPS www → HTTP www → HTTP non‑www → …
• Boucles de cookies/sessions : surtout autour de /wp-admin ou du checkout WooCommerce quand les cookies sécurisés et la détection de schéma divergent.

Voici le modèle mental fiable : une boucle de redirection est une politique de canonicalisation en conflit répartie sur des systèmes qui ne partagent pas d’état.

Topologie des boucles de redirection : où naît la boucle

Le débogage des redirections est plus rapide quand on cartographie le chemin de la requête :

1. Client → edge Cloudflare (règles, mode SSL, comportement HSTS, cache)
2. Cloudflare → origine (schéma utilisé pour se connecter, en‑têtes ajoutés)
3. Porte d’entrée de l’origine (vhosts Nginx/Apache et réécritures)
4. PHP/WordPress (SiteURL/Home, wp_redirect(), plugins, logique is_ssl())
5. Retour (les en‑têtes Location sont réécrits ? mis en cache ? mélangés ?)

Quand vous voyez « Trop de redirections », vous ne cherchez pas « le réglage ». Vous cherchez deux opinions concurrentes sur l’URL canonique. Supprimez-en une.

Méthode de diagnostic rapide

Si vous êtes de garde, vous n’avez pas de temps pour la philosophie. Faites ceci dans l’ordre.

1) Observer la chaîne de redirections depuis l’extérieur

Utilisez un outil qui montre chaque saut, schéma, hôte et code de statut. Votre objectif : identifier le point de bascule où ça change (http→https ou www→apex).

2) Identifier si Cloudflare est impliqué

Si les réponses incluent des en‑têtes Cloudflare (ou si votre DNS est en proxy orange), supposez que Cloudflare peut réécrire ou cacher des redirections. Déterminez le mode SSL configuré et toute fonctionnalité « forcer HTTPS ».

3) Contourner Cloudflare pour tester le comportement de l’origine

Atteignez l’origine directement (ou via override hosts) en conservant le même en‑tête Host. Si l’origine boucle seule, corrigez l’origine/WordPress. Si l’origine est propre, la boucle est côté Cloudflare (ou entre Cloudflare et l’origine à cause d’un décalage de mode SSL).

4) Décidez d’une politique d’URL canonique

Choisissez exactement un hôte canonique (www ou apex) et exactement un schéma (HTTPS). Ensuite, appliquez‑le à un seul endroit — de préférence l’edge ou le serveur web, pas WordPress plus trois plugins.

5) Vérifiez les en‑têtes proxy et la détection de schéma par WordPress

Si le TLS est terminé avant l’origine, WordPress doit connaître le schéma initial via des en‑têtes comme X-Forwarded-Proto. Sans cela, WordPress croit être en HTTP et redirige « utilement » vers ce qu’il estime correct.

6) Purgez les caches qui mémorisent la mauvaise redirection

Cloudflare peut mettre en cache des redirections. Les navigateurs aussi. Les plugins de cache WordPress également. Votre correction peut être correcte et sembler toujours cassée tant que les caches ne sont pas purgés ou contournés.

Faits et contexte intéressants (parce que l’histoire se répète)

• Fait 1 : L’en‑tête HTTP Host (virtual hosting) est devenu courant à la fin des années 1990 ; avant cela, de nombreux serveurs supposaient un site par IP. Les redirections basées sur l’hôte se sont beaucoup répandues après ça.
• Fait 2 : Le 301 (Moved Permanently) est souvent mis en cache par les navigateurs et intermédiaires. Un mauvais 301 peut vous suivre plus longtemps qu’un mauvais 302.
• Fait 3 : Le mode « Flexible » de Cloudflare existe pour les sites sans TLS à l’origine, mais c’est aussi une manière classique de créer des boucles HTTP↔HTTPS quand l’origine force HTTPS.
• Fait 4 : WordPress stocke historiquement les URL canoniques dans deux options — siteurl et home — et leur discordance est toujours l’une des façons les plus rapides d’inventer une boucle.
• Fait 5 : HSTS n’effectue pas de redirection via des réponses serveur ; il met à niveau les requêtes dans le navigateur. C’est excellent pour la sécurité et confus quand on se demande « pourquoi ça va encore en https ? ».
• Fait 6 : Les codes de redirection ont évolué avec HTTP/1.1 : 307 et 308 ont été introduits pour préserver la sémantique de la méthode (POST restant POST). Certains proxies gèrent encore mal cela dans des cas limites.
• Fait 7 : Les premières pratiques « forcer SSL dans l’admin » de WordPress précèdent les proxys TLS‑terminants courants ; beaucoup de snippets supposent que l’origine voit HTTPS et cassent derrière des load balancers modernes.
• Fait 8 : Les CDN ont commencé comme accélérateurs statiques ; maintenant ils livrent une logique complète requête/réponse (Workers, règles d’edge). C’est puissant — et c’est aussi trois endroits supplémentaires pour rediriger accidentellement.

Une citation opérationnelle à garder sur un post‑it :

idée paraphrasée — John Allspaw : « Les postmortems sans blâme fonctionnent parce qu’ils se concentrent sur la manière dont le système a rendu la défaillance possible, pas sur qui a appuyé sur le bouton. »

Tâches pratiques : commandes, sorties attendues et décisions

Ces tâches sont l’ossature du diagnostic réel. Chacune inclut (a) la commande, (b) ce que signifie la sortie, (c) la décision suivante. Exécutez‑les depuis un shell que vous contrôlez.

Task 1: Get the redirect chain (headers only)

cr0x@server:~$ curl -sS -I -L -o /dev/null -w '%{url_effective}\n%{http_code}\n' https://example.com
https://www.example.com/
200

Signification : Avec -L, curl a suivi les redirections. L’URL effective est là où vous avez atterri. Le code HTTP à la fin est la réponse finale.

Décision : Si vous n’atteignez jamais 200 et que curl renvoie « maximum redirects followed », capturez la liste complète des sauts ensuite (Task 2). Si vous atterrissez sur un hôte/schéma différent de celui attendu, trouvez où la canonicalisation se produit.

Task 2: Print every hop (Location headers)

cr0x@server:~$ curl -sS -D - -o /dev/null http://example.com | sed -n '1,20p'
HTTP/1.1 301 Moved Permanently
Date: Fri, 26 Dec 2025 12:00:00 GMT
Location: https://example.com/
Server: cloudflare
CF-RAY: 8abc1234abcd1234-LHR

Signification : Vous pouvez voir si la redirection est générée par Cloudflare (en‑tête Server, CF-RAY) ou par l’origine.

Décision : Si Cloudflare émet la redirection, inspectez d’abord les règles/le mode SSL Cloudflare. Sinon, allez voir la configuration de l’origine.

Task 3: Ask curl to show the whole redirect trace

cr0x@server:~$ curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' -I https://example.com
301 https://www.example.com/

Signification : Le serveur a renvoyé une redirection et curl vous indique l’URL suivante.

Décision : Si redirect_url change de schéma/hôte de manière inattendue, identifiez la couche responsable en contournant Cloudflare (Task 6/7).

Task 4: Check whether the browser is doing HSTS upgrades (from server side, infer)

cr0x@server:~$ curl -sS -I https://example.com | grep -i strict-transport-security
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Signification : HSTS est activé. Les navigateurs peuvent forcer HTTPS même si vous tapez HTTP.

Décision : Si vous testez le comportement HTTP, ne vous fiez pas à une session de navigateur normale. Utilisez curl, un profil navigateur propre, ou retirez temporairement HSTS une fois le site stable (avec précaution).

Task 5: Resolve DNS to confirm you’re actually using Cloudflare

cr0x@server:~$ dig +short example.com
104.21.12.34
172.67.98.76

Signification : Ce sont des IP anycast Cloudflare (souvent). Si vous voyez les IP d’origine, vous n’êtes peut‑être pas en proxy.

Décision : Si vous êtes en proxy, les réglages Cloudflare comptent. Si le DNS pointe vers votre origine, concentrez‑vous sur l’origine/WordPress.

Task 6: Bypass Cloudflare by hitting origin IP with Host header

cr0x@server:~$ curl -sS -I --resolve example.com:80:203.0.113.10 http://example.com
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
Server: nginx

Signification : --resolve force curl à parler à l’IP d’origine tout en conservant Host: example.com. C’est le test le plus propre « est‑ce Cloudflare le problème ? ».

Décision : Si l’origine redirige elle‑même en boucle (répétez aussi pour HTTPS), corrigez l’origine/WordPress. Si l’origine renvoie 200 proprement mais le chemin Cloudflare boucle, corrigez la config Cloudflare.

Task 7: Test origin HTTPS directly (certificate might not match)

cr0x@server:~$ curl -sS -I -k --resolve example.com:443:203.0.113.10 https://example.com
HTTP/1.1 200 OK
Server: nginx

Signification : -k ignore la validation du certificat. Vous testez le comportement, pas la PKI.

Décision : Si HTTPS vers l’origine renvoie 200 mais Cloudflare en « Flexible » se connecte en HTTP, vous avez trouvé le décalage. Changez le mode SSL Cloudflare (détails plus bas).

Task 8: Inspect Cloudflare-to-origin scheme assumptions via headers at origin

cr0x@server:~$ sudo tail -n 3 /var/log/nginx/access.log
198.51.100.23 - - [26/Dec/2025:12:01:02 +0000] "GET / HTTP/1.1" 301 169 "-" "Mozilla/5.0" "https"
198.51.100.23 - - [26/Dec/2025:12:01:03 +0000] "GET / HTTP/1.1" 301 169 "-" "Mozilla/5.0" "http"

Signification : De nombreux formats Nginx incluent $scheme ou des champs forwarded proto. Si vous voyez alterner « http » et « https » pour le même parcours client, vous êtes en territoire ping‑pong.

Décision : Réglez l’application de schéma canonique dans une seule couche, et assurez‑vous que forwarded‑proto est pris en compte par WordPress.

Task 9: Verify WordPress SiteURL and Home (WP-CLI)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp option get siteurl
http://www.example.com
cr0x@server:~$ wp option get home
https://example.com

Signification : Ces valeurs ne doivent pas se combattre. Ici elles divergent sur le schéma et l’hôte.

Décision : Choisissez l’URL canonique (par exemple https://example.com) et définissez les deux ainsi (Task 10). Vérifiez aussi les redirections codées en dur dans la config du serveur.

Task 10: Fix WordPress SiteURL/Home safely (WP-CLI)

cr0x@server:~$ wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.
cr0x@server:~$ wp option update home 'https://example.com'
Success: Updated 'home' option.

Signification : WordPress est désormais d’accord avec lui‑même. Cela supprime une source majeure de redirection.

Décision : Retestez la chaîne de redirections (Task 1/2). Si la boucle persiste, elle est ailleurs (règles Cloudflare ou serveur web).

Task 11: Find hardcoded WP_HOME/WP_SITEURL in wp-config.php

cr0x@server:~$ grep -nE "WP_HOME|WP_SITEURL" /var/www/html/wp-config.php
82:define('WP_HOME', 'https://www.example.com');
83:define('WP_SITEURL', 'https://www.example.com');

Signification : Ces constantes écrasent les options en base. Les mises à jour WP-CLI ne compteront pas si elles sont définies.

Décision : Modifiez‑les pour qu’elles correspondent à l’URL canonique ou supprimez‑les si vous voulez contrôler via la BD. Puis retestez.

Task 12: Check Cloudflare SSL mode symptoms by observing Location header scheme

cr0x@server:~$ curl -sS -I https://example.com | egrep -i 'HTTP/|location:|server:'
HTTP/2 301
location: http://example.com/
server: cloudflare

Signification : Vous avez demandé HTTPS, Cloudflare a répondu par une redirection vers HTTP. C’est presque toujours une règle ou une mauvaise canonicalisation à l’edge/ou l’origine.

Décision : Vérifiez « Always Use HTTPS », les Redirect Rules et le mode SSL Cloudflare. Vérifiez aussi que l’origine ne réécrit pas étrangement les en‑têtes Location.

Task 13: Nginx: list server blocks and look for return/rewrite

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "server_name|return 301|rewrite" | head
123:    server_name example.com www.example.com;
140:    return 301 https://$host$request_uri;

Signification : Vous avez une redirection globale vers HTTPS utilisant $host. Si une autre couche change l’hôte, vous pouvez boucler.

Décision : Canonicalisez l’hôte explicitement (choisissez un seul) au lieu de refléter $host, et assurez‑vous que les réglages Cloudflare sont alignés.

Task 14: Apache: locate RewriteRule forcing scheme/host

cr0x@server:~$ sudo apachectl -t -D DUMP_VHOSTS | head
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/000-default.conf:1)
*:443                  example.com (/etc/apache2/sites-enabled/default-ssl.conf:2)
cr0x@server:~$ grep -RIn "RewriteRule|RewriteCond|Redirect " /etc/apache2/sites-enabled | head
/etc/apache2/sites-enabled/000-default.conf:12:RewriteCond %{HTTPS} !=on
/etc/apache2/sites-enabled/000-default.conf:13:RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Signification : Cela force HTTPS selon la notion Apache de %{HTTPS}. Derrière un proxy, Apache peut ne pas le voir comme activé.

Décision : Enseignez à Apache les en‑têtes forwarded proto ou terminez TLS à Apache. Sinon il continuera à rediriger même pour des clients déjà en HTTPS.

Task 15: Confirm what WordPress thinks the request scheme is (PHP snippet via wp-cli eval)

cr0x@server:~$ wp eval 'var_export([ "is_ssl" => is_ssl(), "https_server" => $_SERVER["HTTPS"] ?? null, "xfp" => $_SERVER["HTTP_X_FORWARDED_PROTO"] ?? null ]);'
array (
  'is_ssl' => false,
  'https_server' => NULL,
  'xfp' => 'https',
)

Signification : WordPress voit X-Forwarded-Proto: https mais is_ssl() est toujours false, selon la façon dont le serveur/PHP gèrent l’environnement.

Décision : Implémentez la gestion des proxies de confiance pour que WordPress interprète correctement forwarded proto (détails dans la section WordPress/proxy). Si vous ne pouvez pas le faire en toute sécurité, appliquez la canonicalisation à l’edge et gardez l’origine cohérente.

Task 16: Verify Cloudflare cache isn’t serving an old redirect

cr0x@server:~$ curl -sS -I https://example.com | egrep -i 'cf-cache-status|age|location|http/'
HTTP/2 301
location: https://www.example.com/
cf-cache-status: HIT
age: 834

Signification : Cloudflare sert une redirection mise en cache. Votre origine est peut‑être déjà corrigée.

Décision : Purgez le cache pertinent sur Cloudflare, et assurez‑vous que la nouvelle redirection canonique est correcte avant de réintroduire le caching.

Blague 1 : Les boucles de redirection sont le seul type d’« évolutivité infinie » que la plupart des sites WordPress atteignent sans essayer.

Coupables spécifiques à WordPress : SiteURL, Home, cookies et admin

1) SiteURL vs Home mismatch

WordPress utilise deux URL qui semblent synonymes parce qu’elles ont été inventées à des époques différentes pour des usages légèrement différents :

• siteurl : où résident les fichiers cœur de WordPress (wp-admin, wp-includes).
• home : la racine publique du site.

Dans la plupart des installations elles doivent être identiques. Si elles divergent en schéma ou en hôte, WordPress peut se « corriger » via des redirections. Quand un proxy/CDN intervient, cette correction peut entrer en collision avec d’autres corrections.

Faire : définissez les deux sur l’URL canonique sauf si vous hébergez réellement le cœur WordPress dans un sous‑répertoire.

Éviter : le corriger seulement en base alors que wp-config.php l’écrase, ou vice versa. Choisissez une source de vérité.

2) FORCE_SSL_ADMIN et les plugins « sécurité » « utiles »

define('FORCE_SSL_ADMIN', true); force le SSL dans l’admin. C’est correct quand l’origine voit HTTPS. C’est un générateur de boucle quand le TLS est terminé chez Cloudflare ou un load balancer et que l’origine voit du plain HTTP.

De nombreux plugins de sécurité répliquent ce comportement, parfois avec leur propre logique de redirection ou en définissant des cookies avec l’attribut Secure alors que l’application pense être en HTTP. C’est ainsi que vous obtenez des boucles de connexion où les identifiants sont acceptés mais la session ne tient pas.

3) WordPress derrière un reverse proxy : rendre la détection de schéma ennuyeuse

Si les requêtes arrivent à l’origine en HTTP mais que l’utilisateur était en HTTPS, WordPress doit savoir que le « vrai » schéma est HTTPS. Typiquement ceci passe par :

• X-Forwarded-Proto: https
• CF-Visitor: {"scheme":"https"} (Cloudflare)

Dans un monde idéal, votre serveur web définit $_SERVER['HTTPS']='on' quand il fait confiance aux en‑têtes proxy. Dans la réalité, il faut le câbler explicitement et restreindre la confiance aux IPs proxy connues. Sinon vous donnez aux attaquants la possibilité d’envoyer un en‑tête « prétends que je suis https » et vous créez des failles de sécurité.

4) Cookies et flags domaine/secure

Les boucles de redirection autour de la connexion viennent souvent de cookies scindés par rapport au nom d’hôte courant. Exemple : cookie défini pour www.example.com alors que l’utilisateur est redirigé vers example.com. WordPress ne voit pas le cookie, suppose que vous n’êtes pas connecté, redirige encore, et ainsi de suite.

De même, si le navigateur n’envoie les cookies Secure qu’en HTTPS, mais que quelque chose vous bascule en HTTP au milieu de la chaîne, vous perdez l’état de session et vous vous retrouvez dans une boucle qui ressemble à « impossible de rester connecté ».

Coupables spécifiques à Cloudflare : modes SSL, règles et cache

1) Cloudflare SSL/TLS modes : la fabrique de boucles

Cloudflare propose plusieurs modes SSL entre visiteur↔Cloudflare et Cloudflare↔origine. Le mode d’échec célèbre :

• Cloudflare « Flexible » : le visiteur se connecte en HTTPS à Cloudflare, mais Cloudflare connecte l’origine en HTTP.
• Votre origine (ou WordPress) est configuré pour forcer HTTPS.
• L’origine répond avec 301 Location: https://example.com.
• Cloudflare récupère cette URL… mais utilise toujours HTTP vers l’origine (parce que Flexible), reçoit à nouveau la redirection HTTPS, et vous avez construit une boucle avec enthousiasme de niveau entreprise.

Correction : N’utilisez pas Flexible pour WordPress si vous forcez HTTPS à l’origine. Utilisez « Full » ou « Full (strict) » avec un certificat d’origine valide. Si vous ne pouvez pas encore faire cela, cessez de forcer HTTPS à l’origine et laissez Cloudflare le gérer (mais cela a des compromis de sécurité).

2) « Always Use HTTPS » plus redirections HTTPS à l’origine

La double application n’est pas toujours nuisible, mais elle augmente la complexité. Si Cloudflare force HTTPS et que votre origine force aussi HTTPS en se basant sur une détection de schéma imparfaite, vous pouvez toujours boucler.

Préférence : appliquez le schéma à l’edge, et configurez l’origine pour servir les deux sans rediriger (ou rediriger seulement quand vous êtes sûr que l’origine voit le bon schéma). Cela réduit la charge et concentre la canonicalisation en une seule couche.

3) Règles www/non‑www : choisissez un hôte canonique

Cloudflare peut faire des redirections d’hôte via des règles. Votre origine peut le faire aussi. WordPress peut aussi (selon son URL stockée). Si vous laissez les trois le faire, vous demandez essentiellement un désaccord à 2h du matin.

Choisissez une option :

• Option A (canonicalisation à l’edge) : Cloudflare gère www↔apex et HTTP→HTTPS. L’origine sert le contenu sans redirections « utiles ».
• Option B (canonicalisation à l’origine) : Nginx/Apache fait les redirections canoniques. Cloudflare se contente de proxyfier et de mettre en cache.

Je privilégie l’Option A quand Cloudflare est devant, car cela réduit les requêtes vers l’origine et évite l’implication de PHP. Mais faites‑le proprement et évitez de cacher de mauvaises redirections.

4) Redirections mises en cache et théâtre « c’est encore cassé »

Cloudflare peut mettre en cache les 301/302. Les navigateurs peuvent cacher fortement les 301. Si vous testez une fois, vous pouvez empoisonner vos propres résultats.

Opérationnellement, vérifiez le comportement avec des en‑têtes anti‑cache ou depuis un environnement propre. Et lorsque vous corrigez, purgez le cache edge après avoir vérifié que le nouveau comportement est correct — purger trop tôt amplifie l’impact d’une mauvaise correction.

5) Workers et Transform Rules : les auteurs silencieux de redirections

Dans des environnements d’entreprise, la boucle de redirection n’est parfois pas une simple case à cocher. C’est un Worker déployé il y a six mois pour normaliser les URL ou définir des cookies. Les Workers peuvent réécrire les en‑têtes Location, changer les schémas, et faire des redirections conditionnelles selon les en‑têtes et la géolocalisation. C’est puissant.

C’est aussi la raison pour laquelle votre argument « j’ai vérifié les Page Rules » n’impressionnera pas votre futur vous.

Configurations Nginx/Apache qui piquent

Nginx : le piège du miroir $host

Ceci est courant et souvent erroné dans les déploiements multi‑couches :

• return 301 https://$host$request_uri;

Si l’en‑tête Host entrant est parfois www et parfois apex (parce qu’une couche précédente bascule), vous reflétez cet hôte et conservez le conflit. Mieux : redirigez explicitement vers votre hôte canonique, pas vers n’importe quel hôte reçu.

Nginx : détection de schéma derrière un proxy

Quand Nginx est derrière un proxy, $scheme est le schéma entre le proxy et l’origine, pas entre l’utilisateur et l’edge. Si Cloudflare se connecte en HTTP, $scheme vaut http même si l’utilisateur est en HTTPS. Si vous écrivez des redirections basées sur $scheme, vous pourriez rediriger des utilisateurs HTTPS vers HTTPS (ok) mais le faire indéfiniment (pas ok) selon la façon dont le proxy rejoue cela.

Apache : RewriteCond %{HTTPS} !=on n’est pas conscient du proxy

%{HTTPS} d’Apache reflète si Apache a négocié TLS. Si TLS est terminé en amont, il sera off. Apache redirigera alors vers HTTPS — même si l’utilisateur l’est déjà. Avec un proxy en amont qui reste en HTTP, vous pouvez boucler.

La solution correcte est une configuration consciente du proxy (et, surtout, limiter la confiance aux IPs proxy).

Blague 2 : La façon la plus rapide de trouver toutes les règles de redirection dans votre pile est de casser la production et d’attendre que cinq équipes jurent qu’elles n’ont rien ajouté.

Erreurs courantes : symptôme → cause → correction

Voici les schémas que je vois le plus, avec des actions correctives spécifiques.

1) Symptom: HTTPS request redirects to HTTP (or flips back and forth)

Cause : règle Cloudflare forçant HTTP, redirections canoniques mal configurées à l’origine, ou interaction du mode SSL « Flexible » avec une origine qui force HTTPS.

Correction : Utilisez « Full »/« Full (strict) » quand l’origine force HTTPS. Supprimez toute règle edge qui redirige vers HTTP. Assurez‑vous que l’origine ne génère pas de Location en HTTP.

2) Symptom: apex redirects to www, and www redirects to apex

Cause : règles canoniques concurrentes sur plusieurs couches (Cloudflare + Nginx + WordPress). Ou divergence SiteURL/Home de WordPress.

Correction : Choisissez un hôte canonique. Implémentez exactement une règle de redirection (préférez l’edge ou le serveur web). Réglez home et siteurl de WordPress sur l’hôte canonique.

3) Symptom: /wp-admin keeps redirecting to /wp-admin/ (or to login) forever

Cause : WordPress ne détecte pas correctement le HTTPS, provoquant un décalage cookies/session. Parfois aggravé par des plugins de cache.

Correction : Assurez‑vous que forwarded proto est de confiance et mappé pour que is_ssl() soit correct. Désactivez le cache pour les chemins admin. Vérifiez le domaine des cookies et l’hôte canonique.

4) Symptom: Works when Cloudflare is paused (DNS-only), fails when proxied

Cause : règles Cloudflare / mode SSL / redirect mis en cache, ou l’origine attend une connexion TLS directe.

Correction : Alignez le mode SSL (« Full strict » idéalement), révisez les règles edge, purgez les redirections en cache.

5) Symptom: Only some users see loop; others are fine

Cause : 301 caché dans le navigateur, HSTS, logique edge géo‑spécifique, ou POPs edge avec cache incohérent.

Correction : Testez avec curl et un profil navigateur propre. Purgez le cache edge. Vérifiez HSTS et évitez de basculer de schéma pendant la correction.

6) Symptom: Loop starts after enabling “Always Use HTTPS” or a WordPress SSL plugin

Cause : double application des règles plus détection de schéma proxy incorrecte.

Correction : Retirez un des applyers. Si Cloudflare force HTTPS, désactivez les plugins WordPress de redirection SSL et retirez les redirections serveur redondantes sauf nécessité.

Trois mini‑histoires d’entreprise issues des tranchées des redirections

Mini-story 1: The incident caused by a wrong assumption

L’entreprise avait un site marketing WordPress derrière Cloudflare et un load balancer managé. Un développeur a activé un plugin de renforcement de sécurité qui « forçait le HTTPS partout ». Le changement est passé parce que ça semblait évidemment correct et l’environnement de staging n’utilisait pas le même chemin proxy.

En quelques minutes, la page d’accueil est devenue inaccessible dans les navigateurs. La supervision affichait un pic de réponses 301. L’ingénieur d’astreinte a fait la vérification classique : hit direct sur l’origine — ok. Via Cloudflare — boucle de redirection.

L’hypothèse erronée était subtile : ils croyaient que l’origine verrait le HTTPS quand les utilisateurs utilisaient HTTPS. Ce n’était pas le cas. Le TLS se terminait sur le load balancer, et la connexion du load balancer vers l’origine était en HTTP. WordPress regardait $_SERVER['HTTPS'], ne trouvait rien, et émettait des redirections vers HTTPS. Cloudflare (en mode Flexible) parlait aussi HTTP à l’origine et poursuivait la redirection à l’infini.

La correction fut ennuyeuse et immédiate : passer Cloudflare en mode Full, ajouter un certificat d’origine valide, et retirer la fonctionnalité de redirection du plugin. La correction à long terme : un runbook définissant la propriété de la canonicalisation (edge) et une politique de confiance des en‑têtes proxy à l’origine.

Mini-story 2: The optimization that backfired

Une équipe voulait « réduire la charge d’origine » en mettant plus de cache chez Cloudflare. Quelqu’un a activé le cache HTML et autorisé la mise en cache des 301. Ça a marché — jusqu’à ce que ça ne marche plus.

Une semaine plus tard, une campagne marketing a changé l’hôte canonique de www vers apex. Ils ont mis à jour les URLs WordPress et ajouté une redirection d’hôte à l’edge. Ça a bien été testé dans un navigateur. Puis les tickets support sont arrivés : la moitié du monde était toujours redirigée vers l’ancien hôte, puis rebondissait, atteignant la limite de redirections.

Le problème n’était pas l’idée de mettre en cache ; c’était mettre en cache la mauvaise chose au mauvais moment. Cloudflare avait mis en cache d’anciennes redirections dans différents POPs. Certains clients avaient aussi mis en cache un 301 de façon permanente. Le système est devenu incohérent : différents utilisateurs recevaient des « vérités » différentes sur l’URL canonique, ce qui alimentait la logique de redirection de WordPress et les domaines de cookie.

La correction a impliqué des purges ciblées de cache, le passage temporaire à des 302 pendant la migration, et — surtout — la réduction du nombre d’« auteurs » de redirections à une seule couche pour éviter la dérive. Le postmortem recommandait clairement : ne mettez pas en cache des redirections à moins d’avoir opérationnalisé leur invalidation.

Mini-story 3: The boring but correct practice that saved the day

Une autre organisation gérait plusieurs propriétés WordPress avec un modèle edge/origin standard. Rien de fou : une politique d’URL canonique documentée, un contrôle obligatoire « vérification de chaîne de redirections » dans la revue de changement, et un petit script validant www et apex sur HTTP et HTTPS avant déploiement.

Un vendredi, une migration DNS a déplacé un domaine vers un autre compte Cloudflare. Le nouveau compte avait une règle par défaut : « Always Use HTTPS ». L’origine appliquait déjà HTTPS, mais elle le faisait en Apache avec %{HTTPS} !=on. Derrière Cloudflare, Apache ne voyait jamais HTTPS. Cela aurait dû être une boucle classique.

Elle n’est pas devenue incident parce que leurs pré‑tests l’ont détectée immédiatement. Le script montrait que la chaîne de redirections n’atteignait jamais 200. Ils ont bloqué le changement, ajusté Apache pour qu’il soit conscient du proxy (et limité la confiance), puis activé la règle edge.

La leçon est agaçante mais vraie : la meilleure correction de redirection est d’empêcher la boucle dès le déploiement. Ce n’est pas glamour. C’est fiable.

Listes de contrôle / plan pas à pas

Step 0: Decide the canonical URL policy (don’t skip)

• Schéma canonique : HTTPS.
• Hôte canonique : choisissez soit example.com ou www.example.com.
• Une couche d’application : edge ou origine (pas les deux sauf si vous comprenez l’interaction).

Step 1: Capture redirect matrix (4-way test)

Testez toutes les combinaisons et notez où chacune aboutit :

• http + apex
• http + www
• https + apex
• https + www

Vous voulez que les quatre aboutissent exactement à une URL canonique en 0–2 sauts.

Step 2: Fix Cloudflare SSL mode first when Cloudflare is in front

• Si l’origine supporte TLS : utilisez Full (strict) quand possible ; sinon Full.
• Évitez Flexible quand l’origine force HTTPS.

Step 3: Remove duplicate redirect logic

• Désactivez les plugins WordPress « forcer SSL » si l’edge/l’origine le gèrent déjà.
• Retirez les règles de réécriture Nginx/Apache conflictuelles qui font l’hôte si Cloudflare s’en charge.
• Maintenez SiteURL/Home WordPress alignés sur l’URL canonique.

Step 4: Make origin proxy-aware (securely)

• Assurez‑vous que l’origine définit le bon schéma selon des en‑têtes proxy de confiance.
• Restreignez la confiance aux plages IP des proxies connus (IP Cloudflare et votre load balancer).
• Validez que is_ssl() retourne true pour le trafic utilisateur en HTTPS.

Step 5: Purge caches and retest

• Purgez le cache Cloudflare pour le site (ou au moins les redirections mises en cache).
• Contournez le cache navigateur (nouveau profil / navigation privée n’est pas toujours suffisant pour HSTS).
• Relancez les tests curl et vérifiez que l’URL finale est stable.

Step 6: Put a guardrail in CI/change review

• Ajoutez un test automatisé de chaîne de redirections pour la matrice 4‑voies.
• Échouez les changements si un chemin dépasse 2 redirections ou n’atteint jamais 200/403/401 selon l’attendu.

FAQ

1) Why does WordPress redirect even when I didn’t configure redirects?

WordPress applique des URL canoniques basées sur ses valeurs home/siteurl et l’interprétation de la requête. Il peut rediriger vers l’hôte/schéma « correct », surtout pour les chemins admin.

2) What’s the fastest way to tell whether Cloudflare is the redirect source?

Vérifiez les en‑têtes de réponse pour des marqueurs Cloudflare (comme CF-RAY) puis contournez Cloudflare avec curl --resolve pour atteindre l’origine directement avec le même Host.

3) Is Cloudflare “Flexible” SSL ever safe for WordPress?

Ça peut l’être, mais c’est fragile. Si votre origine ou WordPress force HTTPS, Flexible est un risque de boucle. En production, « Full (strict) » est la réponse mature.

4) I fixed it, but some users still get redirected wrongly. Why?

Les mauvais 301 sont mis en cache par les navigateurs et Cloudflare. Aussi, HSTS met à niveau côté client. Purgez le cache edge et testez depuis un environnement propre ; envisagez des 302 temporaires pendant la transition.

5) Should I enforce www/non-www in WordPress, Nginx, or Cloudflare?

Choisissez une couche. Si Cloudflare est toujours devant, l’edge est souvent la plus simple. Si vous bypass parfois Cloudflare (clients API régionaux), faites‑le à l’origine. Ne l’appliquez pas dans les trois.

6) Why does /wp-admin redirect loop more than the homepage?

Les flux admin dépendent des cookies et des flags Secure. Si WordPress pense que la requête est en HTTP, il peut définir des cookies ou redirections incohérentes, provoquant des boucles de connexion.

7) How do I handle redirects without breaking POST requests (checkout forms)?

Évitez de rediriger les POST si possible. Si vous devez le faire, utilisez des codes qui préservent la méthode (307/308) et vérifiez que votre pile edge/proxy les supporte. Souvent, la meilleure correction est d’avoir le bon schéma/hôte canonique avant la soumission.

8) Can a plugin cause a redirect loop even if SiteURL/Home are correct?

Oui. Les plugins de sécurité, SSL et cache ajoutent souvent des redirections ou modifient le comportement des cookies. Désactivez‑les temporairement pour isoler. Si la désactivation corrige, retirez la fonctionnalité de redirection du plugin et appliquez la canonicalisation ailleurs.

9) Why does it only break on mobile networks or specific countries?

Les différents POPs Cloudflare peuvent servir des redirections mises en cache différentes, et les règles/Workers géo‑spécifiques peuvent se comporter différemment. Traitez‑le comme un problème de cache distribué : vérifiez les en‑têtes, les identifiants de POP, et purgez.

10) What’s the “one change” that fixes most loops?

Aligner le mode SSL Cloudflare avec la réalité de l’origine (Full/Full strict) et faire en sorte que WordPress soit d’accord sur l’URL canonique (SiteURL/Home). Ensuite, retirez la logique de redirection dupliquée.

Conclusion : étapes concrètes à livrer

Les boucles de redirection surviennent quand plusieurs couches se disputent sur ce qu’est « l’URL réelle ». Votre travail est d’arrêter la dispute.

1. Choisissez une URL canonique (HTTPS + un hôte).
2. Prouvez où se situe la boucle avec l’inspection des sauts curl et les tests de contournement d’origine.
3. Corrigez la couche responsable : mode SSL/règles Cloudflare, règles de réécriture de l’origine, ou SiteURL/Home et en‑têtes proxy WordPress.
4. Retirez la logique de redirection dupliquée pour éviter qu’elle réapparaisse lors du prochain « petit » changement.
5. Purgez les redirections mises en cache et vérifiez que la matrice 4‑voies (http/https × www/apex) converge rapidement vers une seule URL.

Si vous ne faites rien d’autre : arrêtez d’avoir des auteurs de redirections en conflit. La production aime la simplicité. Elle aime aussi que vous ne soyez pas réveillé.