Comment corriger l'erreur 'ERR_TOO_MANY_REDIRECTS'

ERR_TOO_MANY_REDIRECTS signifie que le navigateur a suivi une chaîne de redirections qui ne se résout jamais — le plus souvent URL A → URL B → URL A — et a abandonné après avoir atteint sa limite interne de sauts.

Si vous avez rencontré cette erreur, vous avez probablement modifié un paramètre de proxy ou de SSL, puis observé chaque requête rebondir indéfiniment entre deux URLs au lieu de se charger. C’est une erreur particulièrement frustrante, précisément parce que la page fonctionnait parfaitement une heure auparavant et que rien ne semble manifestement cassé. Il ne s’agit ni d’un bug du navigateur ni d’un incident passager ; cette erreur signale qu’au moins deux règles de redirection dans votre stack sont en désaccord sur la destination d’une URL. Ce guide adopte une approche diagnostic-first : vous tracez la boucle avant de toucher à la configuration, puis vous corrigez la véritable cause racine, qui est pour la plupart des développeurs une incompatibilité de protocole derrière un proxy ou un CDN, et non un plugin WordPress.

Que signifie ‘ERR_TOO_MANY_REDIRECTS’ ?

Une boucle de redirection se produit lorsque votre site répond continuellement à une URL par une redirection vers une autre qui finit par pointer en retour vers la première, si bien que le navigateur n’atteint jamais une réponse finale 200. Les navigateurs limitent le nombre de sauts qu’ils acceptent de suivre : Chromium et Firefox s’arrêtent tous deux à 20, et Safari s’arrête plus tôt, après quoi ils abandonnent la requête et affichent une erreur.

Le message affiché varie selon le navigateur, mais toutes les formulations suivantes décrivent la même situation :

Les redirections elles-mêmes sont des réponses 3xx ordinaires, généralement 301 ou 302, chacune portant un en-tête Location. Dans une boucle, les deux mêmes valeurs Location alternent jusqu’à ce que le navigateur abandonne.

Diagnostiquez d’abord : tracez la chaîne de redirections

Avant de modifier la moindre configuration, tracez la chaîne depuis la ligne de commande. curl -I -L https://yourdomain.com affiche les en-têtes de réponse pour chaque saut, et une boucle se manifeste par la répétition des deux mêmes URLs dans les lignes Location: successives. Dans le manuel de curl, -I (--head) récupère uniquement les en-têtes et -L (--location) suit chaque en-tête Location vers l’URL suivante.

Une origine en boucle produit une sortie de ce type :

HTTP/2 301
location: https://app.example.com/

HTTP/2 301
location: http://app.example.com/

HTTP/2 301
location: https://app.example.com/
...
curl: (47) Maximum (50) redirects followed

L’alternance http:// ↔ https:// est ici la signature d’une boucle due à une incompatibilité de protocole. Si vous souhaitez également les corps de réponse, utilisez curl -sSL -o /dev/null -D - https://yourdomain.com, qui affiche tous les en-têtes tout en ignorant le corps.

Alternatives sans installation : l’onglet Network des DevTools du navigateur affiche la même chaîne de redirections 301/302 avec chaque Location, et l’extension Redirect Path ou un vérificateur de redirections en ligne restituera la chaîne pour une URL donnée. Quelle que soit la sortie que vous utilisez, repérez l’URL qui se répète : cette paire répétée est la boucle.

La cause n°1 chez les développeurs : les boucles HTTP↔HTTPS dues à la terminaison SSL

La boucle de redirection la plus courante que rencontrent les développeurs n’est pas causée par un plugin. Il s’agit d’une incompatibilité de protocole : un proxy ou un CDN termine le TLS et transfère du HTTP brut à votre origine, votre application voit http, redirige vers https, et le cycle se répète indéfiniment. Le navigateur communique en HTTPS avec le point d’entrée ; le point d’entrée communique en HTTP avec votre application ; votre application « utilement » redirige vers HTTPS.

Sur Cloudflare, configurer SSL/TLS en mode Flexible alors que votre origine force également HTTPS garantit une boucle, car Flexible envoie toujours du HTTP à l’origine. Le déclencheur est souvent l’option distincte « Always Use HTTPS » activée par-dessus le mode Flexible. La solution : installez un certificat sur l’origine, puis passez en mode Full (strict). Les modes disponibles sont Off, Flexible, Full, Full (strict) et Strict — et non les « trois modes » décrits dans les anciens guides.

Derrière votre propre proxy ou répartiteur de charge, configurez l’application pour qu’elle fasse confiance à l’en-tête de protocole transmis plutôt que de rediriger à nouveau. Le proxy doit envoyer X-Forwarded-Proto avec le schéma d’origine du navigateur, et l’application doit le lire plutôt que le saut en texte brut. Dans Express, activez trust proxy afin que req.protocol et req.secure reflètent la valeur transmise :

// Trust the first proxy hop, then req.secure reflects X-Forwarded-Proto
app.set('trust proxy', 1);

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(301, `https://${req.headers.host}${req.originalUrl}`);
  }
  next();
});

Sans trust proxy, req.secure reste false derrière un proxy qui termine le TLS, et ce middleware exact entre en boucle. Dans Nginx effectuant la redirection à l’origine, conditionnez la règle sur le schéma transmis afin qu’elle ne se déclenche pas pour du trafic déjà arrivé en HTTPS :

# Only redirect when the edge saw plain HTTP
if ($http_x_forwarded_proto = "http") {
  return 301 https://$host$request_uri;
}

Une boucle en production qui ne se déclenche que pour les utilisateurs connectés ou uniquement derrière le CDN est invisible lors d’une exécution anonyme de curl. Un enregistrement de session de la session concernée montre quelles deux URLs rebondissaient dans le contexte réel des cookies et de la configuration de l’utilisateur, reproduisant ainsi la condition que les journaux serveur décrivent sans vous permettre de l’observer directement.

Boucles liées aux cookies et aux gardes d’authentification

Les cookies périmés et les redirections d’authentification mal configurées constituent la deuxième grande catégorie. Un cookie contenant un ancien état de redirection, ou une politique HSTS mise en cache par le navigateur, peut forcer un seul client dans une boucle tandis que tous les autres chargent le site normalement ; c’est le symptôme du « ça échoue dans ma fenêtre normale, mais ça fonctionne en navigation privée ». Commencez par vider les cookies et les données du site pour le domaine concerné.

La version programmatique est un garde d’authentification qui boucle sur sa propre page de connexion. Si /login est elle-même soumise à la règle « rediriger les utilisateurs non authentifiés vers /login », chaque visite rebondit vers /login. Excluez la route de connexion du garde. Le même problème survient lorsqu’un gestionnaire de connexion redirige vers une page protégée dont le garde renvoie immédiatement l’utilisateur parce que le cookie de session n’a jamais été défini (effet secondaire fréquent de l’incompatibilité req.secure mentionnée plus haut, où un cookie Secure est refusé sur le saut HTTP du proxy).

Erreurs dans les règles de redirection : deux couches en désaccord

Une boucle de redirection est presque toujours causée par deux couches en désaccord sur l’URL canonique (framework, serveur web et CDN appliquant chacun une règle différente). La correction durable consiste donc à confier les redirections HTTP→HTTPS et www/non-www à une seule couche. Cas classiques : une couche force www, une autre le supprime ; une règle dont la destination correspond encore à sa propre condition ; ou la même redirection dupliquée entre le framework, l’hébergeur et le CDN.

Les frameworks constituent une couche de redirection à part entière, pas une fonctionnalité secondaire :

• Next.js définit les redirections via async redirects() dans next.config.js, où permanent: true émet un 308 et false émet un 307. Notez qu’à partir de Next.js 16, l’ancienne convention de fichier middleware est renommée en Proxy (proxy.ts) ; un fichier middleware.ts existant fonctionne encore pour les cas d’usage Edge runtime, mais est déprécié et sera supprimé dans une version future, donc la logique de redirection ou d’authentification qui s’y trouve doit être migrée vers proxy.ts.
• Nginx utilise une directive return 301 : protégez-la, comme indiqué plus haut, pour qu’elle ne se redéclenche pas derrière un proxy.
• Express utilise des middlewares ; conservez exactement un middleware de redirection HTTPS dans la chaîne.
• WordPress est un exemple du même schéma : une incompatibilité entre les paramètres WordPress Address et Site Address n’est que deux couches en désaccord, résolue en les faisant correspondre.

Côté serveur, Apache peut également générer une erreur distincte « request exceeded the limit of 10 internal redirects », dont la limite de réécriture interne de 10 est distincte de la limite de 20 sauts du navigateur — un indice utile indiquant que la boucle se trouve dans .htaccess, et non côté client. Sur Cloudflare, placez la redirection HTTP→HTTPS dans une Redirect Rule dans le moteur de règles moderne ; les Page Rules sont progressivement abandonnées au profit du moteur de règles moderne.

Comment prévenir les boucles de redirection ?

La plupart des boucles sont introduites par un changement de configuration, donc effectuez les modifications de redirection de manière délibérée. Suivez cette liste de contrôle :

1. Une seule couche gère chaque redirection. Décidez si la canonicalisation HTTPS et www/non-www relève du CDN, du serveur web ou de l’application, et supprimez les doublons dans les deux autres.
2. Faites confiance au proxy, ne redirigez pas à nouveau. Derrière tout saut qui termine le TLS, lisez X-Forwarded-Proto plutôt que de forcer HTTPS aveuglément.
3. Retracez la chaîne après chaque modification. Exécutez curl -I -L sur l’URL concernée après tout changement lié à HTTPS, au domaine ou à la structure des URLs, et confirmez qu’elle se termine par un unique 200.

Le chemin le plus rapide pour sortir d’une boucle de redirection est toujours le traçage, jamais la supposition. Exécutez curl -I -L sur l’URL défaillante, identifiez les deux URLs qui rebondissent dans les en-têtes Location, puis corrigez la couche qui redirige à contre-courant — le plus souvent un proxy qui transmet du HTTP à une origine qui insiste pour recevoir du HTTPS.

FAQ

Pourquoi la boucle de redirection disparaît-elle en navigation privée mais pas dans ma fenêtre normale ?

La navigation privée démarre sans cookies stockés ni politique HSTS mise en cache, donc une boucle qui persiste en navigation normale mais disparaît en fenêtre privée pointe vers un état côté client, et non vers une règle serveur. Un cookie périmé contenant un ancien état de redirection, ou une politique HSTS mise en cache forçant HTTPS sur une origine mal configurée, ne créera une boucle que pour le profil concerné, tandis que les autres utilisateurs chargeront le site normalement. Videz les cookies et les données du site pour le domaine, et si vous suspectez HSTS, inspectez chrome://net-internals/#hsts.

Quelle est la différence entre Cloudflare Flexible et Full (strict) SSL pour les boucles de redirection ?

Flexible envoie toujours du HTTP brut de Cloudflare vers votre origine ; donc si l'origine force la redirection HTTP vers HTTPS, la requête boucle indéfiniment. Full (strict) envoie du HTTPS vers l'origine et valide un certificat de confiance, correspondant à ce qu'attend l'origine et brisant ainsi la boucle. Installez d'abord un certificat valide sur l'origine, puis passez le mode SSL/TLS de Flexible à Full (strict). L'option distincte « Always Use HTTPS » activée par-dessus Flexible est un déclencheur courant.

Pourquoi curl et le navigateur affichent-ils des comportements de redirection différents pour la même URL ?

curl s'exécute en tant que client anonyme sans cookies, sans politique HSTS mise en cache et sans session de connexion, donc il ne reproduit que les boucles causées par des règles serveur ou CDN s'appliquant à toutes les requêtes. Les boucles qui dépendent d'un cookie spécifique, d'une session authentifiée ou d'un point d'entrée CDN particulier n'apparaîtront pas dans une trace curl anonyme. Pour celles-là, capturez le contexte réel de l'utilisateur : les DevTools du navigateur sur la session concernée, ou un enregistrement de session montrant quelles deux URLs rebondissaient dans le contexte des cookies et de l'état d'authentification de cet utilisateur.

Une redirection Next.js 16 définie dans next.config.js s'applique-t-elle à la navigation côté client avec Link ou router.push ?

Avec le Pages Router, les redirections définies dans la fonction redirects() de next.config.js ne sont pas appliquées au routage côté client via Link ou router.push, sauf si un fichier Proxy (anciennement middleware) est présent et correspond au chemin. Les redirections de next.config.js s'exécutent côté serveur pour les chargements de page complets et les requêtes initiales, donc les transitions côté client peuvent les contourner. Dans Next.js 16, la convention de fichier middleware a été renommée en Proxy (proxy.ts) ; un fichier middleware.ts existant doit être migré, car la logique de redirection et d'authentification qui s'y trouve risque de ne plus s'exécuter.