Boucle de redirection : comment la trouver et corriger ERR_TOO_MANY_REDIRECTS

Une boucle de redirection est une chaîne de redirections HTTP qui n'aboutit jamais : l'URL A envoie le navigateur vers l'URL B, B le renvoie vers A, et après une vingtaine de sauts environ le navigateur arrête d'essayer et affiche ERR_TOO_MANY_REDIRECTS. Rien n'est cassé sur la page de destination. Deux règles sont simplement en désaccord sur l'endroit où l'URL est censée se trouver, et chacune ne cesse d'annuler l'autre.

Une redirection en boucle est l'une des rares erreurs web qui désigne elle-même sa propre cause, à condition de regarder au bon endroit. Pas le navigateur, pas la page d'erreur, et certainement pas le cache : la chaîne de redirection. Chaque saut porte un en-tête Location, et les deux adresses qui se répètent sont les deux règles à réconcilier. Ce guide parcourt le diagnostic en une seule commande, les causes derrière presque chaque cycle de redirection que j'ai eu à démêler, et la correction qui ne crée pas discrètement une seconde boucle ailleurs. Si la famille des redirections elle-même reste floue, les types de redirections d'URL en est la carte ; ceci en est la version dépannage.

Ce que signifie vraiment ERR_TOO_MANY_REDIRECTS

Les navigateurs suivent les redirections en votre nom, mais pas indéfiniment. Chaque client conserve un budget de sauts et abandonne la requête une fois celui-ci épuisé : Chrome s'arrête à 20 et ne vous laisse pas le modifier, Firefox expose la même valeur par défaut sous network.http.redirection-limit, et curl en autorise 50 avant de se plaindre. La norme laisse le chiffre ouvert. La RFC 9110 dit seulement qu'un client doit détecter et intervenir dans les redirections cycliques, ce qui est la façon polie de la spécification de dire que chaque navigateur a besoin d'un disjoncteur.

Cette distinction compte pour le diagnostic, car l'erreur ne prouve pas du tout qu'il y a un cycle. Une chaîne de vingt-et-un sauts distincts sans répétition déclenche exactement le même message que deux URL qui se renvoient la balle indéfiniment. Les deux méritent d'être corrigées, mais une seule des deux a une paire d'adresses à réconcilier. La référence de MDN sur les redirections couvre les deux formes, et la différence pratique apparaît dès que vous affichez la chaîne.

Encore une chose que la page d'erreur cache : une redirection permanente est mise en cache par le navigateur. Si la boucle a été construite à partir de réponses 301, les visiteurs continuent de boucler localement même après que vous ayez corrigé le serveur, jusqu'à ce que cette entrée de cache expire ou qu'ils la vident. Ce seul fait explique pourquoi je teste les changements de redirection avec un 302 et ne les promeus en 301 qu'une fois la chaîne correcte, une habitude que 301 contre 302 défend en détail.

Tracer la chaîne de redirection en une seule commande

Oubliez le navigateur. La lecture la plus rapide de n'importe quelle boucle de redirection, c'est le terminal, car curl affiche chaque saut au lieu de les regrouper en une seule page d'erreur :

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Vous obtenez une ligne de statut et un en-tête Location par saut, dans l'ordre. Lisez de haut en bas et l'un de ces trois schémas apparaît. Deux URL qui alternent signifient un véritable cycle, et la paire désigne les deux règles fautives. Une longue succession d'URL distinctes signifie une chaîne empilée au fil des années par différentes personnes, chaque saut légitime pris isolément. Et une chaîne qui se résout correctement dans le terminal mais échoue toujours dans un navigateur signifie que la boucle est pilotée par un cookie, puisque curl n'envoie aucun cookie par défaut.

Ce dernier cas mérite sa propre vérification, car c'est celui qui pousse les gens à accuser leur DNS pendant tout un après-midi :

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Avec un pot de cookies attaché, une boucle de connexion ou de consentement se reproduit en ligne de commande, là où vous pouvez réellement voir quel endpoint n'arrête pas de définir puis de rejeter la session. Dans le navigateur, la vue équivalente est le panneau Réseau avec "Preserve log" activé, qui empêche les sauts précédents d'être effacés quand la page navigue. Si vous préférez ne pas ouvrir de terminal du tout, notre vérificateur de liens trace la chaîne dans le navigateur et affiche le code de statut à chaque saut.

Les causes derrière presque chaque cycle de redirection

Une fois que vous pouvez voir la chaîne, la cause est généralement l'une d'une poignée récurrente. La paire d'URL qui se répète vous indique quelle couche examiner : le schéma qui bascule d'avant en arrière pointe vers la terminaison TLS, le nom d'hôte qui bascule pointe vers une règle d'hôte canonique, et un chemin qui gagne et perd sans cesse une barre oblique pointe vers l'ordre des réécritures.

Des règles https derrière un proxy qui termine le TLS

C'est la redirection infinie la plus courante sur le web moderne, et elle est apparue dès que les proxys ont commencé à terminer le TLS devant les origines. Le proxy accepte une requête HTTPS du visiteur, puis récupère votre origine en HTTP simple. Votre origine voit une requête non sécurisée, fait ce que vous lui avez demandé, et redirige vers HTTPS. Le proxy sert cette redirection, se fait redemander, récupère de nouveau l'origine en HTTP, et ainsi de suite. Cloudflare documente exactement cet échec sous son mode de chiffrement flexible, et tous les autres proxys ont le même piège sous un nom différent.

Il existe deux solutions propres. Basculer le proxy sur un mode de chiffrement complet pour qu'il parle à votre origine via TLS, ce qui est la bonne réponse dans presque tous les cas. Ou, si le saut vers l'origine doit vraiment rester en clair, faire en sorte que la règle de l'origine lise l'en-tête X-Forwarded-Proto plutôt que la connexion brute, afin qu'elle cesse de rediriger des requêtes déjà sécurisées en périphérie.

www et apex en désaccord sur l'hôte qui l'emporte

Une règle d'hôte canonique, ça va. Deux d'entre elles, écrites à des moments différents par des personnes différentes, c'est une boucle. La version classique a une configuration serveur qui envoie l'apex vers www tandis que la configuration applicative renvoie www vers l'apex, et les deux sont certaines d'avoir raison. Vous le verrez instantanément dans la chaîne : example.com vers www.example.com vers example.com, indéfiniment.

Choisissez un seul hôte, imposez-le à un seul endroit précis, et supprimez l'autre règle plutôt que d'essayer de les faire s'accorder. La même logique s'applique à une réécriture de barre oblique finale ou de minuscules : quand deux règles normalisent la même URL dans des directions opposées, vous obtenez un cycle de redirection même si chaque règle est individuellement saine.

Le paramètre d'URL du CMS ou de l'application qui ne correspond plus

La plupart des applications stockent leur propre adresse canonique, et ce champ est une règle de redirection avec un nom sympathique. Changez de domaine, migrez vers un nouvel environnement, ou restaurez un instantané de base de données depuis un autre hôte, et l'application se met à rediriger chaque requête vers une adresse qui redirige en retour. Comme le paramètre vit dans la base de données plutôt que dans la config de votre serveur web, il survit à l'audit de configuration que vous venez de faire, ce qui le rend si pénible à trouver.

La signature, c'est une chaîne qui quitte votre nom d'hôte actuel et n'y revient jamais. Corrigez l'adresse stockée pour qu'elle corresponde au domaine que vous servez réellement, puis videz tout cache applicatif ou de page qui a capturé la mauvaise adresse.

Les boucles de cookie et de session qui n'affectent que les utilisateurs connectés

Ici, les règles sont innocentes et c'est l'état qui pose problème. Une barrière redirige les visiteurs non authentifiés vers une page de connexion, la page de connexion renvoie les visiteurs authentifiés, et un cookie de session illisible sur le domaine cible laisse chaque côté convaincu que c'est à l'autre de s'en occuper. Les bannières de consentement provoquent la même forme quand la redirection qui pose le cookie de consentement est elle-même bloquée.

L'indice est le même que dans la section précédente : une fenêtre privée toute propre fonctionne, ou curl sans pot de cookies se résout normalement. Vérifiez le domaine et la portée Path du cookie, ses attributs Secure et SameSite par rapport au schéma que vous servez réellement, et s'il est posé sur l'apex tout en étant lu sur www.

Les boucles de redirection sont rarement mystérieuses une fois la chaîne à l'écran, mais elles dévorent un après-midi entier quand vous devinez au lieu de tracer. Si vous préférez posséder la couche de redirection plutôt que d'argumenter avec elle, le plan gratuit d'Elido vous donne des liens dont la destination est une valeur unique stockée que vous pouvez repointer, avec chaque saut journalisé.

Corriger sans créer une seconde boucle

La réparation elle-même est courte, et l'ordre compte plus que la syntaxe. Changez une règle, puis retracez. Changer trois règles et recharger ne vous apprend rien sur celle qui comptait, et j'ai vu une équipe passer une heure de cette façon sur une boucle causée par une règle qu'elle avait déjà corrigée dès la première tentative.

1. Supprimez ou inversez exactement l'une des deux règles désignées par la chaîne, pour qu'une requête puisse atteindre un 200 en un seul saut.
2. Relancez le tracé curl -sIL et confirmez que la chaîne compte désormais une redirection au maximum, sans nom d'hôte répété.
3. Videz le cache du navigateur, ou testez dans une fenêtre privée, car tout 301 servi précédemment reste mis en cache localement et simulera un échec qui n'existe plus.
4. Ce n'est qu'ensuite que vous devez promouvoir les redirections temporaires en permanentes, une fois la forme de la chaîne stabilisée.

Deux pièges se trouvent au bout de cette liste. HSTS en est un : une fois qu'un hôte a envoyé un en-tête Strict-Transport-Security, les navigateurs mettent d'eux-mêmes à niveau chaque requête vers HTTPS, si bien qu'une règle d'origine qui force aussi HTTPS devient redondante et peut transformer une mauvaise configuration de proxy en une boucle que vous ne pouvez pas reproduire sans effacer l'entrée HSTS. L'autre piège est la mise en cache en amont de la boucle. Un CDN qui a mis en cache un 301 continuera volontiers à le servir après que l'origine a cessé d'en envoyer un, ce qui explique pourquoi une purge fait partie de la correction plutôt que de venir après elle. Les longues chaînes qui ne bouclent jamais méritent d'être raccourcies dans la même passe : chaque saut supplémentaire est une occasion de plus pour qu'une chaîne de requête soit perdue, ce qui explique exactement comment les paramètres UTM disparaissent dans GA4, et cela explique en partie pourquoi les liens courts n'ont pas à nuire au SEO tant qu'ils restent à un seul saut de profondeur.

Quand la boucle se trouve sur un lien court

Les liens courts ajoutent un endroit de plus où un cycle peut se former, et ce n'est pas la redirection du raccourcisseur. Un lien court est un unique saut stocké : le slug entre, la destination sort. La boucle apparaît quand la destination pointe en retour, ce qui arrive plus souvent qu'on ne le pense. Quelqu'un modifie un lien de campagne pour qu'il pointe vers une page de destination, la page de destination a une ancienne règle qui redirige vers l'URL courte parce que c'était l'adresse de partage canonique le trimestre dernier, et maintenant les deux se renvoient la balle. Les deux sauts se comportent exactement comme configuré.

Deux autres variantes apparaissent dans la même chaîne. L'une est une paire de liens courts qui pointent l'un vers l'autre après une modification en masse, généralement issue d'un import de tableur où la colonne destination contenait des URL courtes au lieu d'URL finales. L'autre est un domaine personnalisé qui se résout encore vers un hôte qui redirige en retour vers le raccourcisseur, ce qui relève d'un reliquat DNS plutôt que d'un problème de lien, et les domaines personnalisés pour liens courts couvre à quoi les enregistrements devraient ressembler. Dans les trois cas, la solution consiste à régler la destination sur la page finale plutôt que sur une autre redirection, ce que vous pouvez faire sans toucher à quoi que ce soit déjà imprimé ou publié.

Comme la destination est stockée plutôt qu'intégrée à l'URL, rien de tout cela ne nécessite de réimpression. C'est tout l'argument en faveur des liens gérés, et lien court qui ne fonctionne pas est le guide de triage plus large quand le symptôme n'est pas spécifiquement une boucle.

Empêcher la prochaine boucle de voir le jour

Les boucles de redirection sont un bug de dérive de configuration, donc les corrections durables sont les plus ennuyeuses. Gardez la décision d'hôte canonique à un seul endroit et traitez toute seconde règle qui touche au schéma ou au nom d'hôte comme un bug dès qu'elle apparaît. Tracez les nouvelles redirections avec curl -sIL avant de les annoncer, pas après que quelqu'un signale une page blanche. Si les liens comptent pour le chiffre d'affaires, mettez-y un contrôle : un tracé programmé qui échoue quand la chaîne dépasse un saut détecte la dérive bien avant qu'un client ne le fasse, et la surveillance des redirections de liens montre à quoi cela ressemble une fois connecté à de vraies alertes.

L'habitude plus large consiste à traiter les destinations comme des données que l'on peut auditer. La prévention de la pourriture des liens couvre la même discipline pour les liens qui cessent discrètement de se résoudre, et c'est la même vérification hebdomadaire dans les deux cas. Honnêtement, la plupart des boucles que j'ai vues ont été livrées par deux personnes compétentes qui ont chacune corrigé le même problème dans une couche différente, à un mois d'intervalle. Écrivez la règle une seule fois et la boucle cesse d'être possible.

Lire la série pilier

Cet article appartient au cluster engineering. Pour la forme du chemin de redirection lui-même, atteindre un p95 sous 15 ms pour les redirections couvre ce que coûte un seul saut bien élevé, et les types de redirections d'URL couvre quel code de statut appartient où avant de commencer à empiler des règles.

À lire aussi sur le blog

• Types de redirections d'URL : 301, 302, 307, 308, et plus
• Redirections 301 contre 302 : laquelle les liens courts doivent-ils utiliser
• Lien court qui ne fonctionne pas ? Diagnostiquez-le en une seule commande
• Liens courts en domaine personnalisé : DNS, TLS, et la périphérie
• Vulnérabilités de redirection ouverte et comment les prévenir
• Surveillance des liens courts avec Sentry et Datadog