Erreurs de redirection

À propos de cette catégorie d’erreurs

# Erreurs de redirection

Les erreurs de redirection se produisent lorsqu’une requête est envoyée d’une URL vers une autre, mais n’atteint jamais une page finale, ou lorsqu’elle passe par plus de redirections que nécessaire. Les symptômes courants incluent ERR_TOO_MANY_REDIRECTS, des changements répétés dans la barre d’adresse, une alternance entre des URL HTTP et HTTPS, ou une page qui ne se charge pas après plusieurs redirections.

Les redirections sont normalement utilisées à des fins légitimes : imposer HTTPS, sélectionner un nom d’hôte privilégié, déplacer une ancienne URL ou acheminer une requête vers un nouveau chemin. Une erreur apparaît généralement lorsque les décisions de redirection entrent en conflit entre plusieurs couches, ou lorsque des données mises en cache amènent un navigateur à répéter un résultat obsolète.

Principaux types d’erreurs de redirection

Boucles de redirection

Une boucle de redirection se produit lorsque la séquence revient finalement à une URL déjà demandée. Par exemple, une règle peut rediriger HTTP vers HTTPS tandis qu’une autre considère la requête HTTPS comme non sécurisée et la renvoie vers HTTP. Le navigateur suit le cycle jusqu’à ce qu’il s’arrête et signale un trop grand nombre de redirections.

Les boucles peuvent également alterner entre des noms d’hôte, des variantes avec ou sans slash final, des chemins, ou entre une URL d’application et une URL de proxy. Sur WordPress, une boucle peut commencer après une migration vers HTTPS lorsque l’adresse WordPress, l’adresse du site, le paramètre force-SSL, la gestion du proxy et la redirection du serveur ne décrivent pas la même URL publique. Consultez [Trop de redirections après le passage de WordPress à HTTPS](/wordpress-too-many-redirects-https) pour ce cas particulier.

Chaînes de redirections longues

Une chaîne de redirections contient plusieurs redirections successives avant que la requête n’atteigne sa destination finale. Une ancienne URL peut d’abord rediriger vers un chemin modifié, puis vers un nom d’hôte privilégié et enfin vers HTTPS. Les chaînes peuvent résulter de plusieurs migrations ou de règles qui se chevauchent.

Une chaîne est différente d’une boucle, car elle atteint finalement une réponse finale. Elle peut toutefois ralentir la navigation et rendre difficile l’identification de la règle responsable de la destination finale. La question de diagnostic utile est de déterminer si chaque redirection intermédiaire est encore nécessaire.

Règles de redirection en conflit

Le comportement des redirections peut être contrôlé par un reverse proxy ou un CDN, une plateforme d’hébergement, un serveur web, un système de gestion de contenu, le code de l’application ou un plugin. Ces couches peuvent ne pas être d’accord sur les points suivants :

• Si la requête d’origine utilisait HTTP ou HTTPS
• Quel est le nom d’hôte canonique
• Si un chemin doit comporter un slash final
• Si un ancien chemin doit être réécrit ou redirigé
• Quelle URL doit être considérée comme l’adresse finale de l’application

Un proxy peut recevoir une connexion HTTPS du visiteur et transmettre à l’origine une connexion utilisant un schéma différent. Si l’application n’est pas configurée pour interpréter correctement le schéma transmis, elle peut émettre une autre redirection HTTPS alors que le visiteur utilise déjà HTTPS.

Comportement lié au cache ou aux cookies

Un test en navigation privée peut aider à distinguer l’état propre au navigateur d’un problème de configuration partagé. Les cookies, les réponses mises en cache ou l’état de session de l’application peuvent conserver un ancien domaine, un ancien parcours de connexion ou une ancienne décision concernant le protocole. Cela ne prouve pas que la configuration du serveur est correcte ; cela montre seulement que le résultat peut dépendre de l’état stocké côté client.

Si la même URL boucle dans plusieurs navigateurs et sur différents appareils, donnez la priorité aux réponses de redirection et à la configuration partagée plutôt que d’effacer à répétition les données locales.

Comment diagnostiquer une erreur de redirection

1. Notez l’URL de départ et le symptôme exact. Relevez le schéma, le nom d’hôte, le chemin, le slash final, le message du navigateur et indiquez si l’adresse change de manière répétée.
2. Testez une nouvelle session de navigateur. Utilisez une fenêtre privée ou effacez les cookies et les données mises en cache du site concerné. Comparez si possible le résultat avec un autre navigateur ou appareil.
3. Retracez l’historique des redirections. Les outils de développement du navigateur ou un outil d’inspection des en-têtes HTTP peuvent afficher chaque réponse et sa cible Location. Identifiez le statut renvoyé à chaque étape et recherchez une URL répétée, une alternance de schémas, un changement de nom d’hôte ou une adresse intermédiaire inutile.
4. Classez le schéma observé. Une adresse répétée indique une boucle. Une séquence qui se termine sur une page indique une chaîne. Un passage de HTTP à HTTPS ou inversement suggère un problème de gestion du protocole ; un changement de nom d’hôte ou de chemin suggère des règles de canonisation ou de migration.
5. Vérifiez les paramètres de l’URL publique. Confirmez que l’URL du site configurée dans l’application correspond au schéma et au nom d’hôte que les visiteurs sont censés utiliser. Sur WordPress, comparez l’adresse WordPress et l’adresse du site au lieu de ne modifier qu’une seule valeur.
6. Examinez les couches de redirection de l’extérieur vers l’intérieur. Vérifiez le CDN ou le reverse proxy, les paramètres d’hébergement, les règles du serveur web, la configuration de l’application ainsi que les plugins de redirection ou SSL. Commencez par la couche qui a généré la réponse Location inattendue.
7. Isolez prudemment les changements récents. Si le problème a commencé après l’activation de HTTPS, la modification d’un domaine, la migration d’un site, la modification des permaliens ou l’installation d’un plugin, comparez ces changements avec la séquence de redirection. Désactivez ou modifiez une règle uniquement si vous y êtes autorisé et si vous pouvez restaurer la configuration précédente.
8. Testez à nouveau les URL d’origine et finale. Utilisez une nouvelle session après chaque modification contrôlée. Vérifiez que l’URL d’origine atteint la destination prévue et que l’URL finale ne redirige plus inutilement.

Points à vérifier en premier

L’erreur a commencé après l’activation de HTTPS

Commencez par la gestion du protocole. Vérifiez où HTTPS est terminé, si l’application reçoit les informations attendues sur la requête sécurisée et si plusieurs couches imposent HTTPS. Recherchez une règle qui redirige une requête déjà sécurisée vers HTTP ou qui amène l’application à émettre une seconde redirection HTTPS.

L’erreur a commencé après une modification de domaine ou une migration

Comparez les anciens et nouveaux noms d’hôte, le schéma, le chemin et le comportement du slash final. Examinez ensemble les redirections de migration et les paramètres d’URL de l’application. Un nom d’hôte partiellement mis à jour ou une redirection qui cible encore l’ancien domaine peut créer une boucle ou une chaîne longue.

Un seul navigateur ou utilisateur est concerné

Testez sans les cookies ni les données mises en cache du site concerné. Si le problème disparaît, recherchez un état de session ou de redirection conservé avant de modifier les règles partagées du serveur. S’il persiste dans plusieurs navigateurs et sur plusieurs appareils, concentrez-vous sur les en-têtes de réponse et sur la configuration commune du proxy, du serveur ou de l’application.

La chaîne de redirections atteint la page, mais elle est inhabituellement longue

Listez chaque URL intermédiaire et déterminez quelle règle l’a introduite. Consolidez si nécessaire les règles de migration obsolètes, tout en conservant les redirections intentionnelles et en vérifiant que les anciennes URL atteignent toujours la bonne destination finale.

Documentation des fournisseurs à consulter

Pour les détails propres à l’implémentation, consultez la documentation du serveur web, du reverse proxy ou du CDN, de la plateforme d’hébergement, du système de gestion de contenu ainsi que du plugin de redirection ou SSL impliqué dans la requête. Recherchez dans ces documents les informations sur la terminaison HTTPS, les en-têtes de protocole transmis, les redirections vers l’hôte canonique, la priorité des redirections et l’invalidation du cache. Le paramètre correct dépend de la couche qui reçoit la requête d’origine et de celle qui génère chaque redirection.