WordPress « Vous êtes redirigé » : stopper les boucles de redirection SSL et liées aux cookies

novembre 5, 2025 • février 3, 2026 • Lecture : 29 min • Views: 12

Cet article vous a aidé ?

Si vous êtes déjà allé sur wp-admin, regardé la roue qui tourne, puis été renvoyé vers la page de connexion comme si rien ne s’était passé — bienvenue dans le monde des boucles de redirection WordPress. Le navigateur affiche « trop de redirections » ou WordPress affiche « Vous êtes redirigé ». Vos utilisateurs disent « le site est en panne ». Vous dites des mots peu adaptés à un dossier de changement.

Ce mode de défaillance est rarement « WordPress est cassé ». Il s’agit presque toujours de la perception HTTP vs HTTPS par votre requête qui ne correspond pas à la perception de WordPress, ou d’un cookie qui ne persiste jamais. La correction est généralement mineure. La chasse peut être longue si vous ne la traitez pas comme un incident SRE : reproduire, observer, réduire, changer une chose, vérifier.

Ce que signifie réellement l’erreur (et pourquoi ça boucle)

Les boucles de redirection WordPress résultent d’un désaccord entre couches. Votre navigateur suit des instructions comme : « allez sur https://… », puis « non, allez sur http://… », puis « en fait, https à nouveau. » Ou vous vous connectez, mais le cookie d’authentification ne correspond pas à l’hôte/schéma/chemin attendu par WordPress, donc WordPress décide que vous n’êtes pas connecté et vous redirige vers la page de connexion, qui essaie à nouveau, et échoue encore. Cela tourne en rond.

WordPress lui-même émet des redirections à partir de plusieurs endroits :

Canonicalisation de l’URL du site (mismatch Home/SiteURL, ou mauvais schéma/hôte) : WordPress tente d’imposer ce qu’il croit être l’URL du site.
Application du SSL pour l’administration (FORCE_SSL_ADMIN, règles wp-admin) : les chemins de connexion et d’administration sont forcés en HTTPS.
Cookies d’authentification pluggables (COOKIE_DOMAIN, cookies sécurisés, cookie path) : si les cookies ne correspondent pas, il se comporte comme si vous n’étiez jamais connecté.
Décisions des proxies/CDN (X-Forwarded-Proto, CF-Visitor, terminaison TLS) : WordPress voit « HTTP » à l’origine alors que l’utilisateur voit « HTTPS » dans le navigateur.
Réécritures serveur (.htaccess, return 301 Nginx, redirections au niveau de l’application) : plusieurs moteurs de redirection se disputent le contrôle.

En production, vous avez presque toujours au moins trois systèmes qui pensent être « la seule couche responsable des redirections » : le CDN, le load balancer/reverse proxy et le serveur web d’origine. WordPress en est un quatrième. Si deux d’entre eux ne sont pas d’accord sur le schéma ou l’hôte, vous obtenez une boucle. S’ils sont d’accord mais que le cookie ne persiste pas, vous obtenez une boucle de connexion qui ressemble à la précédente, mais qui en est une autre.

Une règle sèche qui paye les factures : choisissez exactement une couche pour maîtriser les redirections HTTP→HTTPS et www→non-www. Tous les autres doivent laisser passer la requête et transmettre les en-têtes correctement.

Guide de diagnostic rapide

1) Confirmer quel type de boucle il s’agit (schéma/hôte vs cookie)

Si la chaîne de redirections alterne entre http et https, ou entre www et apex, vous êtes en enfer de canonicalisation. Si elle vous renvoie constamment vers /wp-login.php après un POST réussi, vous êtes probablement en enfer des cookies.

2) Observer la chaîne de redirections depuis l’extérieur, pas depuis votre navigateur

Utilisez curl pour voir les en-têtes Location. Votre navigateur est utile jusqu’à un certain point ; il cache des détails derrière « trop de redirections ».

3) Identifier le point de terminaison SSL

Où se termine le TLS ? CDN ? Load balancer ? Nginx sur l’hôte ? Si l’origine voit HTTP alors que le client voit HTTPS, vous devez transmettre l’information de schéma via des en-têtes et apprendre à WordPress à leur faire confiance.

4) Vérifier la vérité de WordPress : Home et SiteURL

WordPress stocke ces valeurs dans la base et parfois dans wp-config.php. Si elles ne correspondent pas à l’URL publique réelle, WordPress va « corriger » et rediriger indéfiniment.

5) Ne regarder les plugins, le cache et les règles étranges qu’ensuite

Les plugins provoquent bien des boucles, mais la plupart des boucles attribuées aux plugins sont encore des mismatches de schéma/cookie. Désactivez les plugins en dernier, pas en premier. Vous voulez déboguer des systèmes, pas faire des exorcismes.

Une citation, parce qu’elle convient : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Taxonomie des boucles de redirection : SSL vs cookies vs cache

A) Terminaison SSL / mismatch d’en-têtes proxy

Cas classique : le client se connecte en HTTPS à un CDN ou load balancer, qui se connecte à l’origine en HTTP. WordPress tourne sur l’origine et voit $_SERVER['HTTPS'] désactivé et le port serveur à 80. WordPress construit des URLs en http://, puis l’edge force https://, puis WordPress force http://, et vous avez bâti une machine à mouvement perpétuel qui ne produit que de la misère.

Schéma de correction : assurez-vous que l’edge définit X-Forwarded-Proto: https (et/ou un en-tête fournisseur), et assurez-vous que l’origine et WordPress l’interprètent correctement. Ensuite, assurez-vous qu’une seule couche applique les redirections HTTPS.

B) Cookie non défini / non renvoyé (la boucle de connexion)

Vous entrez vos identifiants, ça « connecte », puis vous revenez sur l’écran de connexion. Cela signifie que WordPress ne voit pas un cookie d’authentification valide lors de la requête suivante. Causes possibles :

Cookies sécurisés définis en HTTPS mais le site est accédé en HTTP (ou vice versa).
Mauvais domaine de cookie (COOKIE_DOMAIN mismatch entre example.com et www.example.com).
Proxy qui réécrit les en-têtes Host ; WordPress définit des cookies pour un domaine incorrect.
Politiques SameSite interagissant avec des flux de connexion embarqués (moins courant pour wp-admin standard, plus courant pour des flux SSO).
Niveau de cache qui met en cache la page de connexion ou les réponses de redirection. Oui, certains le font. Non, ça ne finit pas bien.

C) Redirections canoniques conflictuelles (www, slash final, mapping multisite)

WordPress aime une URL canonique. Votre CDN aussi. Votre reverse proxy aussi. Et cinq plugins différents qui veulent « aider le SEO » aussi. Lorsque plusieurs composants « corrigent » chacun l’URL différemment — ajout/suppression de www, forcer un slash final, normaliser les majuscules, ou pousser /index.php — vous pouvez créer une boucle sans impliquer SSL du tout.

D) Cache et effets secondaires des « optimisations »

Les réponses de redirection sont cacheables. Certains caches stockent agressivement les 301/302 quand on leur demande, et certains administrateurs les mettent en cache par des règles trop larges. Si un cache garde un mauvais en-tête Location, vous pouvez corriger l’origine et voir la boucle depuis certaines géos ou seulement pour certains utilisateurs.

Blague #1 : Les boucles de redirection sont comme la politique de bureau — tout le monde insiste sur le fait qu’il s’« aligne », et personne n’est responsable du résultat réel.

Tâches pratiques (commandes, sorties, décisions)

Ces tâches sont destinées à être exécutées depuis un shell admin sur l’hôte d’origine, ou depuis un bastion. Si vous ne pouvez pas exécuter de commandes, adaptez-les à votre environnement. Le but est le même : collecter des preuves, puis décider.

Tâche 1 : Inspecter la chaîne de redirections avec curl

cr0x@server:~$ curl -sS -D - -o /dev/null -L --max-redirs 10 https://example.com/wp-admin/ | sed -n '1,120p'
HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

HTTP/2 302
location: https://example.com/wp-admin/
set-cookie: wordpress_logged_in_abc123=cr0x%7C1735900000%7Ctoken; path=/; secure; HttpOnly

HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1

Ce que cela signifie : On rebondit entre wp-login et wp-admin même après qu’un cookie logged_in soit défini. Cela suggère fortement que le cookie n’est pas renvoyé ou n’est pas valide pour les requêtes suivantes.

Décision : Passez aux vérifications centrées sur les cookies : domaine, drapeau secure, en-têtes Host du proxy et mise en cache des endpoints d’auth.

Tâche 2 : Vérifier le basculement http↔https

cr0x@server:~$ curl -sS -I http://example.com/ | egrep -i '^(HTTP|location)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

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

Ce que cela signifie : Votre edge redirige HTTP→HTTPS, mais votre origine (ou l’application) redirige HTTPS→HTTP. C’est une boucle claire à deux nœuds.

Décision : Choisissez le schéma canonique (nous sommes en 2025 ; c’est HTTPS), puis désactivez la redirection conflictuelle sur une couche et corrigez la gestion de forwarded-proto.

Tâche 3 : Confirmer ce que WordPress pense être l’URL du site (WP-CLI)

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

Ce que cela signifie : WordPress croit que le site est en HTTP. Si le site public est en HTTPS, WordPress va continuer à essayer de « corriger » selon les paramètres et plugins.

Décision : Mettez à jour home et siteurl en HTTPS (après avoir confirmé que le TLS est correctement terminé et que les en-têtes proxy sont corrects).

Tâche 4 : Définir Home/SiteURL en toute sécurité avec WP-CLI

cr0x@server:/var/www/html$ sudo -u www-data wp option update home 'https://example.com'
Success: Updated 'home' option.
cr0x@server:/var/www/html$ sudo -u www-data wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.

Ce que cela signifie : Vous avez changé les URLs canoniques dans la base. WordPress génèrera maintenant des URLs en HTTPS.

Décision : Retestez immédiatement les chaînes de redirections. Si ça boucle encore, vous avez probablement une règle de redirection en amont ou un mismatch de proxy.

Tâche 5 : Vérifier wp-config.php pour des surcharges d’URL codées en dur

cr0x@server:~$ sudo egrep -n "WP_HOME|WP_SITEURL|FORCE_SSL_ADMIN|COOKIE_DOMAIN|COOKIEPATH|SITECOOKIEPATH" /var/www/html/wp-config.php
82:define('WP_HOME','http://example.com');
83:define('WP_SITEURL','http://example.com');

Ce que cela signifie : Même si vous avez corrigé la base, ces constantes la surchargent. C’est un piège commun du type « pourquoi rien n’a changé ? »

Décision : Modifiez-les en HTTPS ou retirez-les et gérez via la base (choisissez un seul plan de contrôle ; ne mélangez pas sans précaution).

Tâche 6 : Vérifier quel schéma l’origine pense servir

cr0x@server:~$ sudo -u www-data php -r 'var_export([$_SERVER["HTTPS"]??null,$_SERVER["SERVER_PORT"]??null,$_SERVER["HTTP_X_FORWARDED_PROTO"]??null,$_SERVER["HTTP_HOST"]??null]);'
array (
  0 => NULL,
  1 => '80',
  2 => 'https',
  3 => 'example.com',
)

Ce que cela signifie : Le TLS est terminé en amont (HTTPS est null, port 80), mais le proxy envoie X-Forwarded-Proto=https. WordPress ne fera pas automatiquement confiance à cela sauf si la pile est configurée pour le faire.

Décision : Assurez-vous que le reverse proxy transmet l’en-tête de façon cohérente, et configurez WordPress/PHP pour traiter X-Forwarded-Proto comme faisant autorité (prudemment — seulement si vous faites confiance au proxy).

Tâche 7 : Inspecter les en-têtes proxy Nginx (cause fréquente)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "proxy_set_header (Host|X-Forwarded-Proto|X-Forwarded-For)|return 301|listen 443|listen 80" | sed -n '1,120p'
45:    listen 80;
61:    return 301 https://$host$request_uri;
90:    listen 443 ssl http2;
132:    proxy_set_header Host $host;
133:    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
134:    proxy_set_header X-Forwarded-Proto $scheme;

Ce que cela signifie : Si l’origine est derrière un autre proxy, $scheme peut être http même lorsque le client utilisait HTTPS. Alors WordPress voit forwarded-proto=http et génère des redirections HTTP.

Décision : Si le TLS est terminé à l’edge, définissez X-Forwarded-Proto https (ou transmettez l’en-tête proto de l’edge) entre proxies, pas $scheme.

Tâche 8 : Vérifier les règles de rewrite Apache (.htaccess) pour des redirections conflictuelles

cr0x@server:~$ sudo sed -n '1,160p' /var/www/html/.htaccess
# BEGIN WordPress
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Ce que cela signifie : Cela force HTTPS à l’origine. Si votre edge force déjà HTTPS mais communique avec l’origine via HTTP, Apache redirigera vers HTTPS sur l’hôte d’origine — parfois le mauvais hôte, parfois un nom privé, parfois simplement des boucles avec l’edge.

Décision : Déplacez l’application du HTTPS à l’edge (recommandé) ou terminez TLS sur l’origine. Ne faites pas les deux à moitié.

Tâche 9 : Confirmer le comportement Cloudflare/Flexible SSL (preuves en-têtes)

cr0x@server:~$ curl -sS -I https://example.com/ | egrep -i "^(cf-|server:|location:|x-forwarded-proto:)"
server: cloudflare
cf-cache-status: DYNAMIC

Ce que cela signifie : Vous êtes derrière Cloudflare (ou un CDN similaire). Si le CDN est configuré en mode qui se connecte à l’origine via HTTP tout en présentant HTTPS aux clients, vous devez vous assurer que la pile d’origine comprend le schéma réel.

Décision : Préférez les modes « Full »/TLS de bout en bout et une gestion cohérente de forwarded-proto. Assurez-vous aussi que le CDN ne réécrit pas les en-têtes Location de façon surprenante.

Tâche 10 : Vérifier que les cookies sont renvoyés (jar de cookies curl)

cr0x@server:~$ curl -sS -c /tmp/cj.txt -b /tmp/cj.txt -L --max-redirs 5 https://example.com/wp-login.php -o /dev/null -D - | egrep -i "set-cookie:|location:|HTTP/"
HTTP/2 200
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

cr0x@server:~$ grep -v '^#' /tmp/cj.txt | sed -n '1,5p'
example.com	FALSE	/	TRUE	0	wordpress_test_cookie	WP%20Cookie%20check

Ce que cela signifie : Le cookie est marqué Secure et scope à example.com et /. Si vous accédez via www.example.com ou via HTTP, il ne sera pas envoyé. De plus, si un proxy réécrit l’Host, le domaine du cookie peut être incorrect.

Décision : Assurez-vous que le nom d’hôte public correspond à ce que WordPress utilise, et évitez de basculer entre www et apex pendant la connexion.

Tâche 11 : Confirmer la conservation de l’en-tête Host à travers les proxies

cr0x@server:~$ curl -sS -H 'Host: example.com' -I http://127.0.0.1/ | egrep -i "^(HTTP|location|set-cookie)"
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Ce que cela signifie : Votre vhost local répond correctement quand Host est défini. Si vous voyez à la place des redirections vers un nom d’hôte interne, la configuration du proxy/origin laisse fuiter des noms internes dans les en-têtes Location.

Décision : Corrigez le vhost/server_name et proxy_set_header Host ; confirmez aussi que home/siteurl de WordPress correspond à l’hôte public voulu.

Tâche 12 : Rechercher des redirections mises en cache dans Nginx ou un proxy de cache

cr0x@server:~$ sudo egrep -R "proxy_cache|fastcgi_cache|expires|add_header Cache-Control|location = /wp-login.php|location ~ \\.php" -n /etc/nginx | sed -n '1,120p'
/etc/nginx/sites-enabled/example.conf:55:    fastcgi_cache WORDPRESS;
/etc/nginx/sites-enabled/example.conf:56:    add_header X-Cache $upstream_cache_status;
/etc/nginx/sites-enabled/example.conf:80:    location = /wp-login.php { include fastcgi_params; }
/etc/nginx/sites-enabled/example.conf:81:    fastcgi_cache WORDPRESS;

Ce que cela signifie : Quelqu’un met en cache des réponses PHP, y compris wp-login.php. Cela peut mettre en cache des redirections et des en-têtes Set-Cookie, produisant des boucles bizarres qui varient selon les utilisateurs.

Décision : Désactivez la mise en cache pour les endpoints de connexion/admin et pour les réponses qui définissent des cookies d’auth. Cachez le front-end anonyme, pas les flux d’authentification.

Tâche 13 : Vérifier que WordPress ne détecte pas HTTPS incorrectement (test mu-plugin rapide)

cr0x@server:~$ sudo install -d /var/www/html/wp-content/mu-plugins
cr0x@server:~$ sudo tee /var/www/html/wp-content/mu-plugins/00-proxy-https.php >/dev/null <<'PHP'
<?php
// Trust X-Forwarded-Proto only if coming from known proxies (adjust CIDRs).
$trusted = ['10.0.0.0/8','172.16.0.0/12','192.168.0.0/16'];
$remote = $_SERVER['REMOTE_ADDR'] ?? '';
function ip_in_cidrs($ip, $cidrs) {
  foreach ($cidrs as $cidr) {
    [$subnet,$bits] = explode('/', $cidr);
    $ip_long = ip2long($ip);
    $sub_long = ip2long($subnet);
    $mask = -1 << (32 - (int)$bits);
    if (($ip_long & $mask) === ($sub_long & $mask)) return true;
  }
  return false;
}
if (ip_in_cidrs($remote, $trusted)) {
  if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
    $_SERVER['SERVER_PORT'] = 443;
  }
}
PHP

Ce que cela signifie : C’est un test pragmatique pour forcer la détection HTTPS quand on est derrière des proxies de confiance. Ce n’est pas « la » solution pour tous les environnements, mais cela prouve rapidement si la détection du schéma est la cause.

Décision : Si les boucles disparaissent, implémentez une solution plus propre à long terme dans votre stack proxy/app et gardez la frontière de confiance stricte.

Tâche 14 : Vérifier Home/SiteURL au niveau DB sans WP-CLI (pour CLI cassée)

cr0x@server:~$ mysql -N -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('home','siteurl');"
home	http://example.com
siteurl	http://example.com

Ce que cela signifie : Même chose que WP-CLI, mais cela fonctionne quand l’intégration PHP/CLI est buggée.

Décision : Mettez à jour ces valeurs (avec prudence) si elles sont fausses. Si vous êtes en multisite, arrêtez-vous et lisez d’abord la FAQ multisite plus bas.

Tâche 15 : Confirmer que les cookies admin ne sont pas retirés par une politique d’en-têtes de sécurité

cr0x@server:~$ curl -sS -I https://example.com/wp-login.php | egrep -i "set-cookie|content-security-policy|strict-transport-security|x-frame-options"
strict-transport-security: max-age=31536000; includeSubDomains; preload

Ce que cela signifie : HSTS est correct et généralement utile. Mais si vous définissez includeSubDomains et que vous avez des sous-domaines hérités encore en HTTP, ces clients seront forcés en HTTPS et peuvent atteindre des endpoints cassés — alimentant parfois un sac de nœuds de redirections.

Décision : Gardez HSTS, mais seulement après avoir vérifié la couverture TLS pour tous les sous-domaines requis. Ne cochez pas preload à la légère.

Blague #2 : Si votre WordPress est coincé dans une boucle de redirection, félicitations — votre site a atteint le mouvement perpétuel, juste pas le type utile.

Trois mini-récits du monde de l’entreprise

1) L’incident causé par une mauvaise hypothèse : « Le load balancer gère le HTTPS, donc l’app sait qu’elle est en HTTPS »

Ils venaient de migrer d’un VM unique avec Apache vers une stack « correcte »: CDN → load balancer → Nginx → PHP-FPM. La demande de changement disait « pas de modifications fonctionnelles ». Cette phrase a coûté plus de soirées que n’importe quelle panne.

Le site était en ligne. La page d’accueil semblait correcte. Puis les éditeurs ont essayé de se connecter et ont eu la boucle « Vous êtes redirigé ». L’ingénieur de garde a fait la danse habituelle : vider les cookies du navigateur, essayer en navigation privée, désactiver quelques plugins. Rien. Pendant ce temps, l’équipe marketing a découvert de nouvelles façons d’actualiser une page.

L’hypothèse sous-jacente était subtile : parce que le client utilisait HTTPS, l’application saurait qu’elle est en HTTPS. Mais le TLS était terminé au load balancer, et le trafic vers l’origine était en clair HTTP. Nginx définissait X-Forwarded-Proto en utilisant $scheme, qui était http à ce saut. WordPress voyait HTTP, définissait des attentes non sécurisées, et renvoyait la redirection d’administration.

La correction fut peu glamoureuse et immédiate : définir X-Forwarded-Proto à partir de l’en-tête entrant du load balancer, pas du schéma local ; ajouter un petit snippet de détection HTTPS dans WordPress avec une frontière de confiance proxy stricte ; puis standardiser la propriété des redirections à l’edge uniquement. Après cela, la boucle de connexion a disparu.

Le postmortem fut encore moins glamour : « ne rien présumer du schéma ; observer les en-têtes à chaque saut. » Ils ont ajouté un endpoint d’affichage d’en-têtes en une ligne pour le debug interne et verrouillé qui peut changer la logique d’en-têtes proxy. La panne n’était pas héroïque ; c’était un fait manquant.

2) L’optimisation qui a mal tourné : mettre en cache wp-login.php « pour la performance »

Une autre organisation avait un pic de trafic. Le front-end était WordPress et le taux de cache était… aspirational. Une initiative de performance bien intentionnée a déployé des règles agressives fastcgi_cache Nginx. L’objectif était sensé : réduire la charge PHP, réduire la latence, éviter des coûts de montée en charge.

En staging tout semblait bien. Puis la production est arrivée : échecs de connexion intermittents, certains utilisateurs voyant les redirections post-connexion d’autres utilisateurs, et une boucle de redirection bizarre qui n’arrivait que dans certaines régions. Ce n’était pas cohérent, ce qui donnait l’impression que « WordPress est instable ». Ce n’était pas le cas.

Ils avaient mis en cache des réponses de /wp-login.php et des redirections de /wp-admin/. Cela signifiait des Location headers en cache et du Set-Cookie en cache, ce qui revient à « réutiliser aléatoirement une ancienne chorégraphie d’authentification ». Si vous voulez saboter votre propre système d’auth via un cache, c’est efficace.

La résolution : créer des règles explicites no-cache pour /wp-login.php, /wp-admin/ et toute requête/réponse qui définit des cookies d’auth. Ils ont aussi inclus le schéma/hôte et quelques en-têtes importants dans la clé de cache. Les performances ont légèrement baissé. La fiabilité a explosé. C’est le compromis à faire.

Par la suite, ils ont continué à mettre en cache — mais seulement pour les GET anonymes et pour les pages de contenu. L’équipe a aussi appris à traiter la mise en cache des 301/302 comme une capacité contrôlée par changement. Le caching des redirections peut être utile ; il peut aussi être une panne déguisée.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : une couche canonique de redirection + tests enregistrés

Une troisième équipe gérait WordPress pour plusieurs unités, derrière un CDN et deux couches de proxies. Ils avaient déjà été brûlés, alors ils ont fait quelque chose de profondément peu à la mode : ils ont établi une règle et l’ont documentée.

La règle : le CDN est propriétaire des redirections HTTP→HTTPS et de la normalisation www. L’origine n’émet jamais de redirections schéma/hôte, seulement des redirections au niveau application (permalinks, etc.). Tous les proxies doivent préserver Host et définir forwarded proto de façon cohérente. Home/SiteURL de WordPress doit correspondre à l’URL publique, et toute surcharge dans wp-config.php est interdite sauf ticket expliquant pourquoi.

Ils ont aussi construit un petit test de régression de chaîne de redirections comme vérification de déploiement. Il exécutait curl -IL sur des endpoints clés (/, /wp-admin/, /wp-login.php) et vérifiait : max 3 redirections, URL finale en https, hôte final canonique, pas d’alternance entre login/admin. Si la chaîne changeait, le déploiement était bloqué.

Des mois plus tard, une mise à jour d’un plugin fournisseur a introduit un nouveau comportement de redirection canonique qui aurait heurté les règles du CDN. Le test l’a détecté avant les clients. Ils n’avaient pas eu besoin d’héroïsme ; ils avaient besoin de la routine ennuyeuse qui dit « non, pas aujourd’hui. »

Erreurs courantes : symptôme → cause racine → correction

1) « Trop de redirections » seulement en HTTPS

Symptôme : HTTP fonctionne (ou redirige une fois), HTTPS boucle.
Cause racine : L’origine pense que les requêtes sont HTTP parce que le TLS se termine en amont ; WordPress génère des URLs HTTP et redirige.
Correction : Transmettez et faites confiance à X-Forwarded-Proto=https correctement ; définissez home/siteurl WordPress en https ; assurez-vous qu’une seule couche applique les redirections de schéma.

2) Boucle de connexion : identifiants acceptés, puis retour à wp-login.php

Symptôme : POST vers wp-login réussit, puis redirection vers login avec reauth=1.
Cause racine : Cookie d’auth non renvoyé (mismatch domaine, drapeau secure, cache, ou réécriture de Host).
Correction : Assurez un hôte cohérent (www vs apex), un COOKIE_DOMAIN correct (ou unset), ne mettez pas en cache les endpoints d’auth, préservez Host à travers les proxies.

3) Alternance www et non-www dans les en-têtes Location

Symptôme : La chaîne de redirections bascule entre example.com et www.example.com.
Cause racine : Le CDN impose un hôte ; home/siteurl WordPress ou une réécriture serveur impose l’autre.
Correction : Choisissez un hôte canonique, définissez-le dans une seule couche, alignez home/siteurl WordPress et supprimez les règles de réécriture concurrentes.

4) Boucle de redirection apparue après activation de HSTS

Symptôme : Certains clients restent coincés ; d’autres vont bien.
Cause racine : HSTS force HTTPS sur des sous-domaines non prêts ; un sous-domaine redirige vers HTTP, que les navigateurs refusent.
Correction : Retirez includeSubDomains jusqu’à obtention d’une couverture TLS complète, ou corrigez le TLS pour tous les sous-domaines ; évitez preload tant que vous n’êtes pas certain.

5) Boucle seulement pour certaines géographies / FAI

Symptôme : Tickets de support provenant d’une région ; vous ne pouvez pas reproduire localement.
Cause racine : Cache d’edge conservant un 301/302 périmé ou configuration CDN incohérente par POP.
Correction : Purgez les redirections mises en cache ; réduisez la cacheabilité des redirections ; vérifiez le déploiement de configuration uniforme sur les POPs.

6) Boucle juste après avoir changé l’URL du site dans les réglages WordPress

Symptôme : L’administration devient inaccessible immédiatement après le changement d’URL.
Cause racine : La nouvelle URL ne correspond pas au vhost/ingress réel ; WordPress vous redirige vers un hôte qui ne sert pas WordPress.
Correction : Mettez à jour via WP-CLI ou la DB avec prudence ; assurez-vous que DNS/vhost correspondent ; ajoutez temporairement une entrée hosts pour tester.

7) Boucles admin multisite après changements de mapping de domaine

Symptôme : Le réseau admin fonctionne sur un domaine mais pas sur les sites mappés.
Cause racine : Mapping de domaine incorrect ou conflits de domaine/path des cookies entre sous-sites.
Correction : Confirmez les constantes multisite et les réglages de mapping de domaine ; alignez la configuration des cookies avec la stratégie de mapping ; assurez-vous que le proxy préserve Host par site.

Listes de contrôle / plan étape par étape

Étape par étape : corriger une boucle SSL/proxy (le cas courant)

Observer la chaîne de redirections avec curl. Confirmer si elle alterne schémas ou hôtes.
Identifier la terminaison TLS : CDN, LB, origine. Dessinez le diagramme des sauts. Ne devinez pas.
Choisir le propriétaire des redirections : généralement l’edge (CDN/LB) pour le schéma et l’hôte canonique.
Désactiver les redirections concurrentes sur les autres couches (supprimez les return/rewrite Nginx/Apache conflictuels ; auditez les plugins WordPress qui forcent le SSL).
Corriger les en-têtes forwardés : préserver Host ; définir X-Forwarded-Proto au schéma client ; assurer que les sauts upstream→origin ne l’écrasent pas.
Apprendre à WordPress à interpréter le schéma derrière des proxies (via config/snippet de proxy de confiance), mais ne faites pas confiance à des en-têtes client arbitraires.
Définir home/siteurl WordPress sur l’URL publique canonique (préférez la DB ou les constantes wp-config, pas les deux).
Retester la chaîne de redirections pour : nombre max de redirections, URL finale, hôte cohérent, schéma cohérent.
Vider les caches (CDN et tous reverse proxies) si des redirections ont été mises en cache.
Ajouter un contrôle de régression afin que le prochain « petit changement » ne devienne pas un incident.

Étape par étape : corriger une boucle cookie/connexion

Reproduire avec curl cookie jar pour confirmer que les cookies sont définis et renvoyés.
Stabiliser le nom d’hôte : utilisez toujours l’hôte canonique pour la connexion/admin. Ne basculez pas entre www et apex.
Vérifier la portée du cookie : domaine et chemin. Évitez de forcer COOKIE_DOMAIN sauf nécessité.
Assurer la cohérence des cookies sécurisés : si les cookies sont Secure, servez login/admin en HTTPS de bout en bout.
Désactiver la mise en cache pour les endpoints d’auth partout : règles CDN, Nginx/Apache, plugins.
Vérifier la préservation de l’en-tête Host à travers les proxies ; WordPress l’utilise pour construire redirections et cookies.
Ce n’est qu’ensuite que vous devez soupçonner les plugins qui modifient les flux de connexion, les plugins de sécurité ou les intégrations SSO personnalisées.

Checklist opérationnelle : que noter durant l’incident

URLs exactes en échec et si cela affecte les utilisateurs anonymes ou seulement les authentifiés.
Sortie de la chaîne de redirections (curl -IL avec en-têtes) depuis au moins un point de vue externe.
Où le TLS se termine et quels en-têtes sont forwardés à chaque saut.
Valeurs actuelles de home/siteurl et toute surcharge wp-config.
Couches de cache dans le chemin et si des redirections sont en cache.
Ce qui a changé récemment (règle CDN, plugin, migration, renouvellement de certificat, politique du load balancer).

Faits et contexte historique

Fait 1 : Les premières applications web comptaient souvent sur la présence de variables serveur comme HTTPS=on ; les reverse proxies ont cassé cette hypothèse bien avant la généralisation.
Fait 2 : L’en-tête X-Forwarded-Proto est devenu un standard de facto parce que les backend avaient besoin de connaître le schéma client original après terminaison TLS en amont.
Fait 3 : WordPress stocke home et siteurl dans la base, un choix de conception qui facilite les déplacements/renommages — jusqu’à ce qu’on oublie de les mettre à jour lors d’une migration.
Fait 4 : La connexion WordPress repose sur plusieurs cookies (test cookie, logged_in, auth, secure_auth), et différents chemins/portées peuvent s’appliquer selon l’admin ou le front-end.
Fait 5 : Les caches sont devenus courants devant WordPress car le rendu PHP était coûteux sous charge ; mettre en cache les flux d’auth a toujours été une mauvaise idée, mais « toujours » n’a pas arrêté grand monde.
Fait 6 : HTTPS est passé d’un « utile pour paiements » à une « expectative par défaut » en grande partie à cause des changements UX des navigateurs et des incentives SEO, ce qui a augmenté la fréquence des bugs de mismatch HTTP/HTTPS.
Fait 7 : HSTS a été créé pour prévenir les attaques de SSL stripping ; opérationnellement, cela signifie aussi qu’une mauvaise configuration HTTPS peut rester collée aux clients plus longtemps que votre patience.
Fait 8 : Les codes de statut des redirections comptent : les 301 peuvent être mis en cache agressivement par navigateurs et CDNs, rendant une erreur temporaire étonnamment persistante.
Fait 9 : Les modes de type « Flexible SSL » existent pour faciliter l’onboarding, mais ils normalisent aussi le schéma dangereux HTTPS→edge et HTTP→origin, lequel est la source de nombreuses boucles.

FAQ

1) Pourquoi WordPress affiche « Vous êtes redirigé » au lieu d’un message d’erreur ?

Ce message signifie généralement que WordPress essaie d’envoyer une redirection (souvent via JavaScript/meta refresh) quand il considère que l’URL demandée est incorrecte ou que l’auth est incomplète. Le navigateur atteint ensuite l’URL suivante et le cycle recommence.

2) Est-ce toujours causé par le SSL ?

Non. Le mismatch SSL/proxy est fréquent, mais les problèmes de portée des cookies (domaine/chemin/drapeau secure), les redirections mises en cache et les règles contradictoires www/non-www sont aussi courants. Le moyen le plus rapide de trier est la chaîne de redirections : alternances de schéma suggèrent SSL ; rebonds connexion/admin suggèrent cookies.

3) Dois-je corriger en définissant WP_HOME et WP_SITEURL dans wp-config.php ?

Parfois. C’est un plan de contrôle valide, surtout si vous voulez de la config-as-code. Mais ne le mélangez pas à des valeurs gérées en DB sans précaution ; les surcharges peuvent embrouiller le futur vous. Si vous les définissez dans wp-config.php, retirez la tentation de « juste changer dans l’UI ».

4) Je suis derrière un load balancer. Quels en-têtes doivent être corrects ?

Au minimum : préserver Host et passer X-Forwarded-Proto reflétant le schéma client. Passez aussi X-Forwarded-For pour le logging et les limites de débit. Ensuite, assurez-vous que WordPress/PHP fait confiance à ces en-têtes uniquement depuis les IPs de proxies connus.

5) Pourquoi ça marche pour moi mais pas pour d’autres utilisateurs ?

Généralement le cache. Un POP CDN peut avoir mis en cache un mauvais 301/302 ; ou un navigateur a mis en cache un 301 ; ou un path spécifique est en cache sans Set-Cookie. Purgez les caches d’edge et vérifiez le Cache-Control sur les réponses de redirection.

6) Comment savoir si les cookies sont le problème ?

Si la connexion « réussit » mais que vous retombez sur wp-login.php, il s’agit presque toujours de cookies. Confirmez en capturant Set-Cookie puis en vérifiant que le cookie est renvoyé sur la requête suivante (curl cookie jar, ou outils développeur du navigateur en regardant les en-têtes de requête).

7) Un plugin peut-il causer des boucles de redirection ?

Oui, en particulier les plugins de sécurité/SSL/SEO. Mais traitez la mise en cause des plugins en dernier recours après avoir confirmé que l’infrastructure ne ment pas sur le schéma/l’hôte. Désactivez les plugins seulement après avoir capturé la chaîne de redirections et vérifié home/siteurl et les en-têtes proxy.

8) Et le multisite — les corrections sont-elles différentes ?

Le multisite ajoute plus de façons de se tromper sur les domaines/portée des cookies. Home/siteurl peut ne pas raconter toute l’histoire, le mapping de domaine ajoute de la complexité, et domaine/path des cookies peut différer par site. Approchez-le de la même façon : observez redirections et cookies, mais validez les hôtes par site et les réglages réseau.

9) J’ai corrigé l’origine mais les navigateurs bouclent encore. Pourquoi ?

Les navigateurs mettent en cache les 301 de façon agressive. Les CDNs aussi mettent en cache les redirections si on leur demande. Testez avec un client fraîchement lancé, videz les caches et envisagez d’utiliser des 302 pendant la stabilisation d’une migration, puis passez à 301 une fois sûr.

10) Existe-t-il une architecture « meilleure » pour prévenir cela ?

Oui : HTTPS de bout en bout, un seul propriétaire des redirections canoniques (généralement l’edge), en-têtes forwardés corrects, et règles explicites no-cache pour admin/auth. Ce n’est pas excitant. C’est pour ça que ça marche.

Conclusion : prochaines étapes qui ne vous feront pas perdre votre après-midi

Si vous ne retenez qu’une habitude opérationnelle : capturez toujours la chaîne de redirections et le comportement des cookies avant de changer quoi que ce soit. Les boucles de redirection semblent chaotiques, mais elles sont déterministes. Le système fait exactement ce que vous lui avez demandé — juste pas ce que vous aviez voulu.

Prochaines étapes pratiques :

Exécutez les vérifications de chaîne de redirections curl et classez la boucle (schéma/hôte vs cookie).
Alignez home/siteurl WordPress avec l’URL publique canonique et retirez les surcharges conflictuelles.
Corrigez les en-têtes proxy et les frontières de confiance afin que l’origine connaisse le schéma et l’hôte client.
Faites qu’une seule couche soit propriétaire des redirections canoniques ; désactivez les autres.
Excluez login/admin de toutes les couches de cache, puis purgez les redirections mises en cache.
Ajoutez un petit test de régression des redirections aux déploiements pour que cela devienne un problème résolu, pas une réunion récurrente.