ERR_TOO_MANY_REDIRECTS : ce qui cause une boucle de redirection et comment la corriger

Ce que signifie ERR_TOO_MANY_REDIRECTS

Une redirection dit au navigateur « la page que vous voulez se trouve ailleurs, allez-y à la place ». Une seule redirection, ou même deux ou trois en séquence, est normale : un domaine nu qui redirige vers www, ou une vieille URL qui redirige vers son remplacement. Une boucle se produit quand une URL redirige vers une seconde URL qui redirige en retour vers la première, ou vers elle-même. Comme le navigateur n'atteint jamais une page qui renvoie réellement du contenu, il coupe la chaîne au lieu de rester bloqué pour toujours.

Comment l'erreur apparaît

Chrome et Edge affichent « This page isn't working - redirected you too many times » avec le code d'erreur ERR_TOO_MANY_REDIRECTS. Firefox affiche « The page isn't redirecting properly ». Safari dit « Safari can't open the page because too many redirects occurred ».

curl avec l'option -L suit les redirections de la même façon qu'un navigateur, et afficher chaque saut montre exactement où la boucle se répète :

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Ce schéma, http vers https puis retour vers http, est la forme la plus courante que prend cette erreur. curl s'arrête sur sa propre limite par défaut (50 redirections) plutôt que de la suivre indéfiniment, et les lignes location qui se répètent rendent la boucle évidente sans avoir besoin d'ouvrir un navigateur du tout.

Ce qui provoque une boucle de redirection

• Une incompatibilité HTTP-vers-HTTPS entre un proxy ou un CDN et l'origine. C'est le cas classique. Si le mode SSL/TLS de Cloudflare est réglé sur Flexible, Cloudflare termine le TLS à la bordure et se connecte à l'origine en HTTP simple. Si le serveur d'origine a aussi une règle qui redirige chaque requête HTTP vers HTTPS (un réglage de sécurité par défaut courant), l'origine renvoie le navigateur vers HTTPS, Cloudflare redescend en HTTP au saut suivant, et les deux réglages se battent indéfiniment.
• Des règles www et non-www qui pointent l'une vers l'autre. Une règle redirige le domaine nu vers www, et une règle séparée, souvent ajoutée plus tard par un autre administrateur ou une extension, redirige www en retour vers le domaine nu.
• Une incompatibilité de siteurl ou home WordPress. Si l'URL configurée du site dans la base de données ne correspond pas à l'URL que les visiteurs utilisent réellement (une URL de préproduction oubliée, une incompatibilité de schéma après l'ajout de SSL), WordPress continue de rediriger vers la valeur configurée.
• Des cookies que le serveur attend mais ne reçoit jamais, ou une redirection de connexion qui échoue silencieusement. Une page qui redirige les visiteurs non authentifiés vers une étape de connexion, qui redirige ensuite en retour vers la même page parce que le cookie de session n'a jamais été fixé (souvent bloqué par les règles de cookies tiers d'un navigateur ou un attribut Secure/SameSite manquant), boucle indéfiniment.
• Des règles de barre oblique finale ou de préfixe de langue qui entrent en conflit. Une règle ajoute une barre oblique finale, une autre la retire ; une règle ajoute un préfixe de langue selon la locale du navigateur, une autre le retire pour les URL canoniques, et les deux s'annulent mutuellement.
• Une couche de mise en cache servant une redirection obsolète. Un CDN ou un reverse proxy a mis en cache un vieux 301 qui pointait vers une URL qui, depuis modifiée, redirige en retour vers l'originale.

Comment savoir de qui vient la faute

Si la boucle se produit pour chaque visiteur sur chaque réseau, c'est un problème de configuration du serveur ou du CDN, pas quelque chose de local. Si cela ne se produit que pour vous, videz d'abord les cookies du site puisqu'un cookie de session mauvais ou expiré cause une grande part des boucles à visiteur unique. Lancer une vérification HTTP depuis plusieurs emplacements règle cela en une seule requête : si la même chaîne de redirection (ou le même échec) apparaît depuis chaque emplacement, la correction se situe côté serveur.

Comment corriger ERR_TOO_MANY_REDIRECTS

Si vous êtes visiteur

1. Videz les cookies du site. Dans Chrome, cliquez sur le cadenas ou l'icône de réglage à côté de la barre d'adresse, ouvrez les réglages du site, et videz les cookies et données de site pour ce domaine uniquement.
2. Essayez une fenêtre incognito ou privée. Cela écarte une extension de navigateur ou un cookie stocké comme cause sans toucher à votre profil habituel.
3. Essayez un autre réseau, comme des données mobiles au lieu du Wi-Fi. Certains proxys d'entreprise ou de FAI réécrivent les requêtes d'une façon qui crée une boucle seulement sur ce réseau.
4. Videz le cache du navigateur au cas où une réponse de redirection elle-même aurait été mise en cache d'avant que le site ne soit corrigé.

Si vous gérez le site

1. Vérifiez le mode SSL de votre CDN par rapport à la règle de redirection de votre origine. Dans Cloudflare, ouvrez SSL/TLS et réglez le mode sur Full ou Full (strict), pas Flexible, chaque fois que l'origine redirige HTTP vers HTTPS. Full permet encore à l'origine d'utiliser un certificat autosigné ; Full (strict) en exige un valide.
2. Faites confiance à l'en-tête de protocole transmis plutôt que de rediriger aveuglément. Quand un proxy se trouve devant votre application, l'origine doit rediriger en fonction de X-Forwarded-Proto, pas de la connexion brute, qui ressemble toujours à du HTTP vue depuis derrière le proxy. Sur nginx :

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   et assurez-vous que le CDN ou l'équilibreur de charge fixe bien cet en-tête sur chaque requête.
3. Vérifiez vos règles de redirection dans l'ordre, y compris .htaccess, les blocs server de nginx, le middleware au niveau de l'application, et toute règle de page CDN, à la recherche de deux règles qui pointent l'une vers l'autre. Un motif Apache courant qui boucle derrière un proxy :

   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   échoue de la même façon que le cas nginx ci-dessus, puisque %{HTTPS} lit la connexion que le proxy fait, pas celle que le visiteur a faite ; vérifiez plutôt %{HTTP:X-Forwarded-Proto}.
4. Corrigez l'URL du site WordPress si cela s'applique : dans wp-admin > Settings > General, confirmez que l'adresse WordPress et l'adresse du site correspondent toutes deux à l'URL que les visiteurs utilisent réellement, protocole inclus. Si le panneau d'administration lui-même est inaccessible à cause de la boucle, fixez WP_HOME et WP_SITEURL directement dans wp-config.php.
5. Choisissez une forme canonique unique et redirigez tout le reste vers elle une seule fois, pas en chaîne : www ou non-www, barre oblique finale ou pas, une règle par décision plutôt que plusieurs règles empilées par différents outils au fil du temps.
6. Purgez le cache du CDN après avoir corrigé la règle, puisqu'un 301 ou 302 mis en cache continue d'envoyer l'ancienne réponse jusqu'à ce qu'il expire ou soit purgé.

Erreurs associées

• Les codes de statut de redirection 3xx expliquent ce que signifient chacun des 301, 302, 303, 307 et 308.
• 301 face à 302 couvre le moment où une redirection doit être permanente plutôt que temporaire, ce qui compte pour les moteurs de recherche et la mise en cache, pas seulement pour les boucles.

Comment prévenir ERR_TOO_MANY_REDIRECTS

Une boucle de redirection est presque toujours introduite par un changement de configuration : un nouveau CDN, un nouveau certificat SSL, une mise à jour d'extension, ou une migration qui a touché l'URL du site. Une vérification HTTP qui surveille le code de réponse et suit les redirections selon un calendrier détecte une boucle dès qu'elle apparaît, depuis plus de 300 points de contrôle dans 158 villes, plutôt que d'attendre un ticket de support. HostTracker surveille des sites web depuis 2004 et peut alerter par e-mail, SMS, appel vocal, Slack, Telegram et bien plus dès qu'une vérification commence à échouer.

Questions fréquentes

Combien de redirections un navigateur autorise-t-il avant d'abandonner ?

Chrome et les navigateurs basés sur Chromium s'arrêtent autour de 20. La limite par défaut de curl avec -L est de 50. Le nombre exact varie selon le client, mais chacun d'eux finira par s'arrêter plutôt que de suivre une boucle pour toujours.

Pourquoi la boucle ne se produit-elle que juste après mon passage à Cloudflare (ou un autre CDN) ?

Presque toujours le mode SSL/TLS. Le mode Flexible parle en HTTP simple à l'origine ; si l'origine insiste sur HTTPS, les deux côtés se redirigent mutuellement indéfiniment. Passer à Full ou Full (strict) résout généralement le problème immédiatement.

Une extension de navigateur peut-elle causer cela ?

Oui, en particulier les extensions qui forcent HTTPS, réécrivent les requêtes, ou gèrent les cookies. Tester dans une fenêtre incognito avec les extensions désactivées écarte cela rapidement.

Cela affecte-t-il le SEO ?

Oui. Les robots des moteurs de recherche abandonnent une boucle de redirection de la même façon qu'un navigateur, et une URL en boucle ne sera pas indexée ou sortira de l'index si elle fonctionnait auparavant.

Je ne vois l'erreur que sur une page spécifique, pas sur tout le site. Qu'est-ce qui est différent ?

Cherchez une règle spécifique à la page : une page nécessitant une connexion, une vieille redirection mise en cache pour cette seule URL, ou une incompatibilité de barre oblique finale qui n'existe que sur cette route. Comparez la chaîne de redirection exacte pour cette URL à celle d'une page qui fonctionne avec curl -sIL.

Une seule redirection (comme non-www vers www) est-elle quelque chose à corriger ?

Non, une seule redirection en elle-même est normale et attendue. Seule une chaîne qui se répète et n'atteint jamais une réponse 200 finale est le problème que cette erreur décrit.