Boucle de connexion WordPress : renvoi vers la page de connexion — comment réparer

Plan de diagnostic rapide (vérifiez ceci en premier)

Si vous n’avez que cinq minutes avant que quelqu’un d’important demande pourquoi il ne peut pas publier le billet du PDG, faites ceci dans l’ordre. Cette séquence trouve rapidement le goulot d’étranglement parce qu’elle suit le chemin d’authentification : navigateur → cache en périphérie → proxy inverse → PHP → base de données.

1) Confirmez si les cookies sont définis et renvoyés

• Vérifier : Le navigateur reçoit-il un Set-Cookie après l’envoi POST des identifiants ?
• Puis : La requête suivante vers /wp-admin/ inclut-elle ce cookie ?
• Pourquoi : Une « boucle » de connexion signifie souvent que WordPress dit « je n’ai pas reçu de cookie d’auth valide », donc il vous renvoie.

2) Confirmez que l’URL canonique et le schéma sont cohérents

• Vérifier : Basculez-vous entre http et https ou entre www et le domaine apex ?
• Pourquoi : Les cookies sont limités par des règles de domaine + schéma. Si votre POST de connexion a lieu sur un hôte/schéma et que l’admin charge sur un autre, votre cookie peut ne pas s’appliquer.

3) Contournez les caches et couches de sécurité

• Vérifier : Un cache en périphérie, un WAF, un plugin « performance » ou un proxy inverse met-il en cache wp-login.php ou altère-t-il les en-têtes ?
• Pourquoi : Les points d’entrée d’authentification sont dynamiques. Les mettre en cache, c’est comme étiqueter votre porte d’entrée « parfois ouverte ».

4) Désactivez les plugins en sécurité, puis les thèmes

• Vérifier : Le problème disparaît-il lorsque les plugins sont désactivés ?
• Pourquoi : Un plugin « sécurité » ou de « consentement cookie » peut casser l’auth de façon créative.

5) Validez les sessions côté serveur, PHP et l’écriture DB

• Vérifier : PHP écrit-il des sessions ? La base de données est-elle accessible en écriture ? Y a-t-il des erreurs fatales ?
• Pourquoi : Si WordPress ne peut pas définir l’état lié à l’auth (ou si vous avez des bizarreries d’object cache), il ne peut pas vous maintenir connecté.

Comment fonctionne réellement le flux de connexion WordPress (pour cesser de chasser des fantômes)

La connexion WordPress repose sur les cookies. Quand vous soumettez des identifiants à wp-login.php, WordPress :

1. Valide le nom d’utilisateur/mot de passe (ou SSO) et vérifie le statut/capacités de l’utilisateur.
2. Émet des cookies d’authentification : typiquement wordpress_logged_in_* et wordpress_sec_* (les noms varient selon le hash/salt et les réglages).
3. Redirige (302) vers /wp-admin/ ou vers une cible.
4. À la requête suivante, WordPress lit les cookies, les valide avec les salts et l’enregistrement utilisateur, puis autorise l’accès ou redirige de nouveau vers la connexion.

Une « boucle de connexion » signifie une des trois choses :

• Le cookie n’a jamais été défini (bloqué, supprimé, réponse mise en cache, mauvais en-têtes).
• Le cookie a été défini mais jamais renvoyé (mismatch de domaine, flag secure, mismatch de chemin, problèmes SameSite dans certains flux).
• Le cookie a été envoyé mais rejeté (salts incorrects après migration, incohérence DB/object cache, dérive d’heure, méta utilisateur étrange, plugin d’auth personnalisé).

Un mantra pratique : traitez ceci comme du débogage de systèmes distribués. Il y a plusieurs couches, et n’importe quelle couche peut « utilement » réécrire votre requête en échec.

Paraphrase d’une idée d’un poids lourd de la fiabilité : paraphrase — « L’espoir n’est pas une stratégie. » — attribué à Gene Kranz (mentalité des opérations de mission).

Blague #1 : Une boucle de connexion WordPress est le seul cardio que certains d’entre nous font dans une journée de travail. Ce n’est pas un bon programme de bien-être.

Faits intéressants et contexte historique (court, utile)

• Fait 1 : WordPress utilise une authentification basée sur les cookies depuis les premières versions ; les noms de cookies incluent des hachages dérivés des réglages du site et des salts de sécurité, d’où les migrations qui peuvent « casser » les connexions.
• Fait 2 : Le point d’accès wp-login.php est l’une des URL publiques les plus ciblées sur Internet ; de nombreuses piles d’hébergement ajoutent des règles WAF ou de limitation de débit qui peuvent interférer subtilement avec les connexions légitimes.
• Fait 3 : L’espace d’administration repose beaucoup sur les redirections (hôte canonique, enforcement SSL, emplacement admin). Une mauvaise configuration de redirection produit des boucles plus vite que presque n’importe quel autre bug.
• Fait 4 : Les navigateurs ont durci la gestion des cookies au fil du temps (notamment les paramètres SameSite), ce qui peut casser des flux de connexion impliquant des POSTs intersites ou des callbacks d’IdP externes si vous ne définissez pas correctement les cookies.
• Fait 5 : Beaucoup de CDN « tout mettre en cache » proposaient à l’origine des réglages naïfs ; les configurations modernes excluent généralement wp-admin et wp-login.php, mais cela reste fréquemment mal configuré.
• Fait 6 : WordPress stocke les URL canoniques (home et siteurl) dans la base de données, mais permet des overrides via wp-config.php. Les conflits entre les deux sont un générateur classique de boucles.
• Fait 7 : Un proxy inverse (load balancer, CDN, ingress) change la signification de « est-ce HTTPS ? » à moins que les en-têtes forwardés soient corrects ; WordPress utilise cela pour décider des flags de cookie sécurisé et des cibles de redirection.
• Fait 8 : Le cache d’objets (Redis/Memcached) peut rendre l’authentification « hantée » lorsque des valeurs obsolètes persistent après des déploiements ou lorsque plusieurs serveurs applicatifs ne sont pas alignés sur les salts/config.

Les vraies causes de la boucle de connexion (classées par fréquence)

1) Mismatch d’URL, d’hôte ou de HTTPS (le tapis roulant des redirections canoniques)

WordPress veut une URL unique pour le site. Si votre pile sert plusieurs variantes—http, https, avec/sans www, peut-être un domaine alternatif—le POST de connexion peut se produire sur une variante, mais la redirection vers /wp-admin/ aboutit sur une autre. Les cookies ne voyagent pas comme vous le souhaiteriez.

Déclencheurs courants :

• home et siteurl définis différemment (un en http, l’autre en https).
• HTTPS forcé au niveau du load balancer, mais WordPress croit être en HTTP.
• Règles de redirection dans Nginx/Apache qui se battent avec les redirections canoniques de WordPress.

2) Cookies bloqués, supprimés ou mal scoppés

Si les cookies ne sont pas définis ou renvoyés, WordPress ne peut pas vous garder connecté. Causes :

• Proxy/CDN qui supprime les en-têtes Set-Cookie pour « rendre la réponse cachable ».
• Mismatch domaine/chemin du cookie après un changement de domaine.
• Cookies sécurisés sur HTTPS qui ne fonctionnent pas parce que WordPress ne détecte pas HTTPS (il définit donc des cookies non sécurisés, puis on redirige vers HTTPS et ils ne sont pas acceptés).
• Plugins de consentement cookie ou de sécurité malveillants qui réécrivent les en-têtes.

3) Cache (edge, plugin, serveur) qui met en cache la mauvaise chose

Il est impressionnant de voir combien de configurations « performance » tentent de mettre en cache les pages de connexion. Si la réponse de connexion ou la redirection est mise en cache, différents utilisateurs commencent à partager le même état cassé. De plus, si un cache supprime les cookies, l’authentation casse de façon invisible.

4) Conflits plugins/thèmes, surtout sécurité et SSO

Les plugins de sécurité, les ponts SSO, les plugins 2FA et les packs « désactiver XML-RPC » s’accrochent souvent aux filtres d’authentification. Une mauvaise mise à jour peut introduire une règle de redirection qui ne se termine jamais.

5) Salts/clés cassés après migration ou dérive de configuration entre serveurs

WordPress signe les cookies d’auth avec les salts et clés dans wp-config.php. Si vous les changez, les cookies existants deviennent invalides (ce qui est normal), mais si vous avez plusieurs serveurs applicatifs avec des salts différents, les utilisateurs se déconnectent ou font des boucles selon le backend qui les sert.

6) Dérive d’heure ou bizarrerie de terminaison TLS

Les cookies d’auth contiennent une expiration. Si l’heure système est incorrecte (dérive VM, conteneur, NTP cassé), les cookies peuvent sembler immédiatement expirés. Moins fréquent, mais spectaculaire quand ça arrive.

7) Échecs d’écriture DB ou système de fichiers et fatales subtiles

L’auth WordPress dépend de lectures/écritures DB et de l’exécution complète de PHP. Si PHP fait un fatal après avoir défini une redirection, ou si la DB est en lecture seule, vous pouvez vous retrouver dans une boucle sans erreur utilisateur évidente. Vérifiez les logs sérieusement.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des tâches pratiques que vous pouvez lancer sur un hôte Linux typique. Ajustez les chemins si votre distribution ou layout diffère. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision suivante.

Task 1: Reproduire la chaîne de redirections depuis le serveur

cr0x@server:~$ curl -I -L https://example.com/wp-admin/ | sed -n '1,40p'
HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wp-wpml_current_language=en; path=/
server: nginx

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: no-store, no-cache, must-revalidate, max-age=0

Ce que cela signifie : Un seul 302 vers la page de connexion est normal si vous n’êtes pas authentifié. Si vous voyez des 302 répétés qui rebondissent entre wp-login.php et wp-admin, vous avez une boucle.

Décision : Si la boucle apparaît ici sans navigateur, vous avez affaire à une logique de redirection côté serveur ou à un problème d’URL canonique — ce n’est pas « mon navigateur qui est bizarre ».

Task 2: Vérifier si les réponses de la page de connexion sont mises en cache par un proxy/CDN

cr0x@server:~$ curl -I https://example.com/wp-login.php | egrep -i 'cache|age|cf-cache-status|x-cache|via|set-cookie'
cache-control: no-store, no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Vous voulez no-store ou un en-tête de cache similaire restrictif. Si vous voyez des en-têtes comme x-cache: HIT ou un statut de cache CDN montrant un hit, c’est suspect.

Décision : Si mis en cache, configurez le CDN/proxy inverse pour bypasser le cache pour /wp-login.php et /wp-admin/*, et pour ne jamais supprimer Set-Cookie.

Task 3: Confirmer les URL canoniques WordPress (WP-CLI)

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

Ce que cela signifie : Ce mismatch (https vs http) est un déclencheur classique de boucle.

Décision : Alignez-les sur le même schéma et hôte. Choisissez une URL canonique et tenez-vous-y.

Task 4: Corriger home et siteurl en sécurité

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

Ce que cela signifie : WordPress générera des cookies/redirections selon ces valeurs.

Décision : Retestez la connexion. Si la boucle persiste, passez à la détection HTTPS et aux en-têtes proxy.

Task 5: Vérifier si WordPress croit que la requête est HTTPS (derrière un proxy)

cr0x@server:~$ grep -R "HTTPS" -n /var/www/html/wp-config.php | head
# (no output)

Ce que cela signifie : Aucune forçage explicite de HTTPS au niveau de l’application. C’est acceptable si vos en-têtes proxy sont corrects, mais risqué sinon.

Décision : Si vous terminez TLS au load balancer et que vous forwardez vers PHP en HTTP, assurez-vous que X-Forwarded-Proto est défini et pris en compte, ou définissez conditionnellement $_SERVER['HTTPS']='on' dans wp-config.php.

Task 6: Vérifier les en-têtes forwardés dans Nginx (coupable fréquent)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "X-Forwarded-Proto|X-Forwarded-For|fastcgi_param"
112:    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
113:    proxy_set_header X-Forwarded-Proto $scheme;
210:    fastcgi_param HTTPS $https if_not_empty;

Ce que cela signifie : Si vous êtes derrière un proxy, $scheme peut être http entre le proxy et l’origine même quand le client utilisait HTTPS. Cela fait croire à WordPress qu’il est en HTTP.

Décision : Définissez le proto forwardé correctement depuis la périphérie (LB → origine). Souvent, vous voulez que Nginx fasse confiance à X-Forwarded-Proto de votre LB et le passe à PHP.

Task 7: Inspecter les en-têtes de réponse pour des cookies manquants/réécrits

cr0x@server:~$ curl -s -D - https://example.com/wp-login.php -o /dev/null | sed -n '1,40p'
HTTP/2 200
date: Fri, 27 Dec 2025 11:20:00 GMT
content-type: text/html; charset=UTF-8
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Vous recevez au moins un Set-Cookie pour le cookie de test. Après avoir posté les identifiants, vous devriez voir aussi les cookies d’auth.

Décision : Si Set-Cookie disparaît uniquement sur POST, suspectez des règles WAF, du cache ou un plugin qui plante en cours de réponse.

Task 8: Poster vers wp-login.php et vérifier les cookies d’auth (simulation serveur)

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://example.com/wp-login.php \
  -d "log=admin&pwd=wrongpassword&wp-submit=Log+In&redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&testcookie=1" | egrep -i 'HTTP/|set-cookie:|location:'
HTTP/2 200
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Avec de mauvais identifiants vous n’obtiendrez pas de cookies d’auth ; vous devez obtenir un 200 avec la page d’erreur.

Décision : Si même des identifiants corrects ne produisent pas de cookies d’auth (vous verriez des lignes set-cookie supplémentaires), passez aux logs PHP et à l’isolation des plugins.

Task 9: Vérifier PHP-FPM et les logs web pour des fatales liées à l’auth

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 11:18:32] WARNING: [pool www] child 2147 said into stderr: "PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/foo/foo.php:12) in /var/www/html/wp-includes/pluggable.php on line 1428"

Ce que cela signifie : « Headers already sent » peut empêcher la définition des cookies. Pas de cookies, pas de connexion. Ce fichier de plugin a sorti quelque chose (même des espaces), avant que WordPress n’ait pu définir les en-têtes.

Décision : Désactivez le plugin fautif. Puis corrigez-le proprement (ou remplacez-le) car cela reviendra.

Task 10: Désactiver les plugins sans passer par wp-admin

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp plugin deactivate --all
Success: Deactivated 14 of 14 plugins.

Ce que cela signifie : Vous avez retiré l’interférence des plugins de l’équation.

Décision : Retestez la connexion. Si c’est corrigé, réactivez les plugins un par un pour trouver le coupable (oui, fastidieux ; oui, plus rapide que deviner).

Task 11: Basculer vers un thème par défaut pour éliminer les hacks d’auth au niveau thème

cr0x@server:/var/www/html$ wp theme list
+----------------+----------+--------+---------+
| name           | status   | update | version |
+----------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| corp-theme     | active   | none   | 4.8.1   |
+----------------+----------+--------+---------+
cr0x@server:/var/www/html$ wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Ce que cela signifie : Si votre thème a des redirections personnalisées de connexion, des hooks SSO, ou un buffering de sortie cassé, cela l’isole.

Décision : Si cela corrige la boucle, votre « beau thème corporate » est maintenant un incident de production. Traitez-le en conséquence.

Task 12: Vérifier la dérive de configuration des salts/keys entre serveurs (diff rapide)

cr0x@server:~$ sudo egrep "AUTH_KEY|SECURE_AUTH_KEY|LOGGED_IN_KEY|NONCE_KEY" -n /var/www/html/wp-config.php
54:define('AUTH_KEY',         '...a...');
55:define('SECURE_AUTH_KEY',  '...b...');
56:define('LOGGED_IN_KEY',    '...c...');
57:define('NONCE_KEY',        '...d...');

Ce que cela signifie : Ces valeurs doivent être identiques sur tous les serveurs applicatifs derrière le load balancer.

Décision : Si vous avez plusieurs origines, vérifiez qu’elles correspondent partout. Si non, corrigez le déploiement pour que la configuration soit cohérente.

Task 13: Vérifier l’heure système et la synchro NTP (sanité des expirations de cookies)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-27 11:20:44 UTC
           Universal time: Fri 2025-12-27 11:20:44 UTC
                 RTC time: Fri 2025-12-27 11:20:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : Si les horloges sont décalées ou NTP inactif, les cookies peuvent sembler instantanément expirés.

Décision : Si non synchronisé, corrigez l’heure d’abord. Ne déboguez pas l’auth sur un serveur qui ne sait pas quelle heure il est.

Task 14: Vérifier la santé du cache d’objets Redis (si utilisé)

cr0x@server:~$ redis-cli ping
PONG
cr0x@server:~$ redis-cli info | egrep "used_memory_human|maxmemory_human|evicted_keys"
used_memory_human:312.45M
maxmemory_human:512.00M
evicted_keys:18422

Ce que cela signifie : Beaucoup d’évictions peuvent causer des comportements étranges. Pas toujours des boucles de connexion, mais cela peut déstabiliser des valeurs caches liées à l’auth dans certaines configurations.

Décision : Si les évictions sont élevées, augmentez la mémoire du cache ou réduisez l’usage. Confirmez aussi que votre plugin d’object cache est adapté et configuré correctement.

Task 15: Confirmer que la DB est écrivable et ne retourne pas d’erreurs

cr0x@server:~$ mysql -N -e "SHOW GLOBAL VARIABLES LIKE 'read_only';"
read_only	OFF

Ce que cela signifie : Si la DB est en lecture seule (ou en échec), WordPress peut se comporter de façon imprévisible, surtout pour les sessions/plugins qui écrivent la méta utilisateur.

Décision : Si read_only est ON de façon inattendue, corrigez l’état de réplication/basculement ou pointez WordPress vers le primaire correct.

Task 16: Valider que wp-content n’est pas en lecture seule (mises à jour et certains flux d’auth)

cr0x@server:~$ sudo -u www-data test -w /var/www/html/wp-content && echo "wp-content writable" || echo "wp-content NOT writable"
wp-content writable

Ce que cela signifie : Toutes les boucles de connexion ne concernent pas les écritures de fichiers, mais les problèmes de permissions accompagnent souvent des déploiements cassés et des problèmes « headers already sent ».

Décision : Si non écrivable et que votre stack l’attend, corrigez la propriété/permissions ; si votre stack interdit les écritures, assurez-vous que les plugins/thèmes n’essaient pas d’écrire à l’exécution d’une manière qui casse les réponses.

Erreurs courantes : symptôme → cause racine → correctif

Symptôme : Mot de passe correct, redirection instantanée vers wp-login.php, sans erreur

Cause racine : Cookies non stockés ou non renvoyés (mismatch de domaine, flag secure, « headers already sent », proxy supprimant Set-Cookie).

Correctif : Vérifiez la cohérence home/siteurl, inspectez les en-têtes de réponse pour Set-Cookie, éliminez les warnings PHP « headers already sent », et désactivez les caches sur login/admin.

Symptôme : Ça marche sur un navigateur/appareil, échoue sur un autre

Cause racine : Différences de politique de cookie (comportement SameSite, blocage des cookies tiers), cookies obsolètes, ou extension de navigateur modifiant les requêtes.

Correctif : Testez dans un profil propre/en navigation privée, videz les cookies du site, assurez-vous que votre flux de connexion est en première partie (pas de POST inter-site), et confirmez HTTPS et l’hôte canonique.

Symptôme : Ça marche en accès direct sur l’origine, échoue via CDN/WAF

Cause racine : Cache en bordure des endpoints d’auth/admin, pages de challenge WAF, suppression d’en-têtes, ou protection anti-bot traitant des humains comme des bots.

Correctif : Contournez le bord pour confirmer, puis ajoutez des règles de bypass explicites. Éventuellement allowliste des plages IP admin si approprié et assurez-vous que les pages de challenge n’affectent pas les POSTs sur wp-login.php.

Symptôme : N’échoue que lorsque « Forcer HTTPS » ou HSTS est activé

Cause racine : WordPress ne détecte pas HTTPS derrière un proxy ; il définit des cookies ou redirections de manière incohérente.

Correctif : Corrigez les en-têtes forwardés et/ou activez la détection HTTPS dans wp-config.php. Assurez-vous qu’une seule couche effectue la redirection canonique.

Symptôme : Déconnexions aléatoires / boucles en environnement load-balanced

Cause racine : Différence de salts/keys entre serveurs applicatifs, wp-config.php incohérent, ou absence de sessions persistantes (sticky sessions) requises par un plugin.

Correctif : Rendre la configuration immuable et identique sur tous les nœuds. Évitez la dépendance aux sticky sessions ; si inévitable, configurez-les explicitement et documentez pourquoi.

Symptôme : La connexion fonctionne, mais wp-admin déconnecte immédiatement après quelques clics

Cause racine : Plugin de cache mettant en cache admin-ajax, plugin de sécurité agressif invalidant les sessions, ou dérive d’horloge.

Correctif : Excluez les chemins admin du cache, ajustez les règles de sécurité, et vérifiez la synchronisation temporelle.

Symptôme : Seuls les administrateurs sont affectés ; les éditeurs peuvent se connecter

Cause racine : Politiques de redirection spécifiques aux administrateurs, mauvaise configuration 2FA, vérifications de capacités, ou mu-plugin personnalisé.

Correctif : Inspectez les must-use plugins et les réglages de sécurité ; testez avec tous les plugins désactivés ; examinez les logs serveurs pour des redirections spécifiques aux rôles.

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

Checklist A : Récupération en une passe pour revenir dans wp-admin

1. Effacez les cookies du navigateur pour le site (ou utilisez une fenêtre privée). Si vous ne pouvez pas vous connecter là non plus, ce n’est pas « des cookies obsolètes ».
2. Confirmez l’URL canonique :
   • Faites en sorte que home et siteurl soient identiques (schéma + hôte).
   • Choisissez soit www soit le domaine apex et tenez-vous-y.
3. Contournez le CDN/WAF temporairement (fichier hosts / accès direct à l’origine) pour voir si la périphérie est le problème.
4. Désactivez tous les plugins via WP-CLI ou en renommant wp-content/plugins.
5. Changez pour un thème par défaut pour éliminer le code d’auth du thème.
6. Consultez les logs pour « headers already sent » et erreurs fatales.
7. Corrigez la détection HTTPS derrière les proxies (en-têtes forwardés ou forçage conditionnel HTTPS dans wp-config.php).
8. Réactivez les plugins un par un. Arrêtez-vous quand la boucle revient. Ce plugin est votre coupable, pas votre victime.

Checklist B : Durcir pour que cela ne revienne pas mardi prochain

1. Excluez les endpoints d’auth du cache : /wp-login.php, /wp-admin/*, et typiquement /wp-json/ selon vos flux admin.
2. Standardisez le déploiement de la config : une source de vérité pour wp-config.php et les salts, déployée identiquement sur tous les nœuds.
3. Surveillez les redirections : suivez les taux de 302 pour wp-login.php et wp-admin. Un pic est souvent un signal d’alerte.
4. Loggez à la périphérie et à l’origine : incluez des IDs de requête pour tracer une tentative de connexion à travers la pile.
5. Documentez votre politique d’URL canonique (hôte, schéma, HSTS). Une politique non écrite devient du folklore ; le folklore devient des incidents.
6. Testez après les changements : chaque fois que vous touchez aux règles CDN, à la terminaison HTTPS ou aux plugins de cache, testez explicitement le flux de connexion.

Blague #2 : Le moyen le plus rapide de créer une boucle de connexion WordPress est de dire « C’est juste un petit changement de redirection. » La boucle vous entend.

Trois mini-récits d’entreprise depuis le front

Incident #1 : La mauvaise hypothèse (HTTPS c’est HTTPS, non ?)

Une entreprise de taille moyenne faisait tourner WordPress derrière un load balancer qui terminait TLS. Les serveurs origine parlaient HTTP en interne. L’équipe a supposé que parce que le navigateur affichait une icône de cadenas, l’application « savait » qu’elle était en HTTPS.

Un après-midi, des éditeurs ont signalé une boucle de connexion. Ce n’était pas tout le monde — juste assez de personnes pour déclencher une panique et une tempête Slack. Le load balancer avait été remplacé lors d’une mise à jour réseau, et le comportement par défaut des en-têtes avait changé.

Sur l’origine, WordPress a commencé à voir les requêtes comme HTTP. Il répondait par des redirections vers HTTPS (parce que home était https), mais il définissait aussi des cookies d’une manière qui ne correspondait pas aux attentes du navigateur. L’histoire des cookies d’auth est devenue incohérente entre les requêtes. Les utilisateurs se connectaient, étaient redirigés, puis traités comme des inconnus et renvoyés.

La correction fut ennuyeuse : assurer que X-Forwarded-Proto: https était correctement défini à la périphérie, et que l’origine lui faisait confiance de façon stable. Une fois que WordPress a eu une vue stable du schéma, la boucle a disparu.

Leçon : dans un monde proxifié, « HTTPS » n’est pas un fait — c’est une affirmation transmise par des en-têtes. Si vous ne gérez pas explicitement cette affirmation, votre application se fabriquera sa propre réalité.

Incident #2 : L’optimisation qui a mal tourné (mettre tout en cache)

Une autre organisation avait une initiative performance. Quelqu’un a activé une règle CDN agressive pour mettre en cache plus de HTML, y compris des « pages à faible risque ». wp-login.php ressemblait à « juste une autre page » dans l’ensemble de règles. Première erreur.

En quelques heures, les taux de réussite de connexion ont chuté. Pas à zéro — juste assez pour être déroutant. Le CDN servait des pages de connexion mises en cache contenant des nonces obsolètes et des cibles de redirection incohérentes. Pire encore, certaines réponses mises en cache n’incluaient pas correctement Set-Cookie, selon la manière dont le borde traitait les en-têtes « non cachables ».

L’incident est devenu politique parce que le changement était présenté comme un « travail de performance », et le travail de performance est censé être héroïque. Au lieu de ça, il a transformé l’authentification en théâtre probabiliste.

La correction a été de créer des règles de bypass explicites pour tous les endpoints liés à l’auth et tout ce qui définit des cookies sensibles. Ils ont ensuite ajouté un moniteur synthétique qui exécutait un flux de connexion et alertait sur des chaînes de redirection inattendues.

Leçon : le cache n’est pas un marteau universel. C’est un scalpel. Si vous vous en servez comme d’un marteau, vous finirez par atteindre votre propre système de connexion.

Incident #3 : La bonne pratique ennuyeuse qui a sauvé la mise (immuabilité de la config)

Une entreprise exécutait WordPress sur plusieurs serveurs applicatifs. Ils avaient une pratique stricte : la configuration, y compris les salts et les clés, était gérée centralement et déployée identiquement à chaque release. Pas d’éditions manuelles. Pas de « correctifs rapides » sur des nœuds individuels.

Ils ont quand même eu un incident — un ingénieur a ajouté un nouveau nœud sous pression. Le nœud venait d’une image plus ancienne et avait initialement un wp-config.php non assorti. Dans beaucoup d’environnements, cela aurait généré des boucles de connexion aléatoires selon le backend qui servait l’utilisateur.

Voici ce qui les a sauvés : leur pipeline de déploiement détectait la dérive. Le nouveau nœud a échoué à un contrôle de checksum de configuration et n’est jamais entré dans la pool du load balancer. La boucle de connexion n’a jamais atteint les clients ; elle est restée un problème de staging où elle appartenait.

Ils ont corrigé l’image, redéployé, et ont poursuivi. Pas de poursuite nocturne « pourquoi cela n’arrive-t-il qu’à certains utilisateurs ».

Leçon : le correctif d’auth le plus fiable est de prévenir l’incohérence. Le deuxième plus fiable est d’empêcher les nœuds incohérents de servir du trafic.

FAQ

Pourquoi WordPress continue-t-il de me rediriger vers la page de connexion après m’être connecté ?

Parce que WordPress ne reçoit pas ou n’accepte pas un cookie d’auth valide à la requête suivante. C’est généralement causé par un mismatch d’URL/schéma, des problèmes de scope de cookie, du cache, des en-têtes proxy, ou un plugin qui interfère avec les en-têtes.

Est-ce que vider les cookies est la vraie solution ?

Vider les cookies est une étape de diagnostic. Si cela corrige le problème une fois, vous avez probablement changé les salts/keys récemment ou eu un mismatch transitoire de cookie. Si cela ne corrige jamais le problème, la cause est dans la pile, pas dans le navigateur.

Un CDN ou un WAF peut-il provoquer une boucle de connexion ?

Absolument. S’il met en cache wp-login.php, supprime Set-Cookie, ou challenge les requêtes POST, vous pouvez vous retrouver coincé dans une boucle. Contournez la périphérie pour confirmer, puis ajoutez des règles de bypass explicites.

Quelle est la différence entre home et siteurl, et pourquoi cela compte-t-il ?

siteurl est l’emplacement des fichiers core de WordPress ; home est ce que le site considère comme son URL publique. Si ces valeurs diffèrent (surtout en schéma/hôte), les redirections et le scope des cookies peuvent casser l’authentification.

Je suis derrière un load balancer. Quel en-tête est le plus important ?

X-Forwarded-Proto. S’il est faux ou non approuvé, WordPress peut croire qu’il est en HTTP alors que le client est en HTTPS, entraînant des redirections et des flags de cookie incorrects.

Est-ce que cela peut être un plugin même si le site public fonctionne correctement ?

Oui. Les pages publiques peuvent fonctionner tandis que les endpoints admin/auth échouent parce que les plugins s’accrochent au login, aux redirections, aux contrôles de sécurité et à la gestion des en-têtes. Désactivez les plugins pour le prouver.

Pourquoi cela n’arrive-t-il qu’à certains utilisateurs dans un environnement load-balanced ?

Généralement à cause d’une dérive de configuration (salts/keys différents) ou d’hypothèses d’état. Si un backend rejette les cookies créés par un autre backend, vous obtenez un comportement « fonctionne parfois ». Rendez la configuration identique et évitez les hacks stateful.

Réinitialiser les salts WordPress résoudra-t-il la boucle ?

Réinitialiser les salts invalide toutes les sessions, ce qui peut « corriger » des boucles causées par des cookies incohérents ou compromis. Mais si la cause racine est les en-têtes proxy, le cache ou le mismatch d’URL, cela n’aidera pas — vos utilisateurs seront simplement déconnectés puis toujours coincés.

Que faire si je n’ai pas accès à wp-admin ni à WP-CLI ?

Renommez le dossier des plugins via SSH pour désactiver tous les plugins : wp-content/plugins → plugins.disabled. Si cela corrige la connexion, réintroduisez les plugins avec précaution. Si non, concentrez-vous sur home/siteurl et la détection proxy/HTTPS.

Conclusion : prochaines étapes pour prévenir la réapparition

Corriger une boucle de connexion WordPress relève moins de l’héroïsme que du refus de se laisser tromper par sa propre pile. Suivez les cookies. Suivez les redirections. Confirmez ce que WordPress croit être l’URL canonique, et confirmez ce que le navigateur fait réellement.

Étapes pratiques :

1. Faites correspondre exactement home et siteurl (schéma + hôte).
2. Assurez-vous que votre proxy/CDN n’effectue pas de cache ou de modification sur wp-login.php et /wp-admin/, et ne supprime jamais Set-Cookie.
3. Vérifiez la détection HTTPS derrière les proxies via les en-têtes forwardés.
4. Désactivez plugins/thèmes pour isoler la sortie d’en-têtes et les hooks d’auth ; réactivez-les un par un.
5. Standardisez wp-config.php (en particulier salts/keys) sur tous les nœuds et gardez l’heure synchronisée.

Si vous faites ces cinq choses, la boucle de connexion redeviendra ce qu’elle devrait être : une histoire que vous racontez à d’autres ingénieurs, pas un lieu où vous vivez.