ERR_TOO_MANY_REDIRECTS : comment corriger cette erreur (tous les navigateurs)

Qu'est-ce que ERR_TOO_MANY_REDIRECTS ?

ERR_TOO_MANY_REDIRECTS est une erreur du navigateur qui se produit lorsqu'un site web est pris dans une boucle de redirection infinie. Au lieu de charger la page, le navigateur rebondit continuellement entre les URLs, et apres avoir atteint sa limite de redirections, il abandonne et affiche cette erreur.

Chaque navigateur possede une limite de redirections integree pour empecher les boucles infinies de consommer des ressources. Lorsqu'une page depasse cette limite, la connexion est interrompue avec un message d'erreur.

Les codes de statut HTTP dans une boucle de redirection sont generalement 301 (redirection permanente) ou 302 (redirection temporaire). Une boucle typique fonctionne ainsi : votre navigateur demande l'URL A, le serveur repond avec un 301 vers l'URL B, l'URL B repond avec un 301 vers l'URL A, et le cycle se repete jusqu'a ce que le navigateur atteigne sa limite.

Quelles sont les causes des boucles de redirection ?

Les boucles de redirection se produisent lorsque deux regles de redirection ou plus entrent en conflit. Le serveur envoie le navigateur vers une URL, et cette URL renvoie le navigateur en arriere. Voici les causes les plus courantes :

• Mauvaise configuration SSL/HTTPS — La cause la plus frequente. Votre serveur force la redirection HTTP vers HTTPS, mais votre CDN ou repartiteur de charge se connecte a l'origine en HTTP, creant une boucle : CDN -> HTTP -> le serveur redirige vers HTTPS -> le CDN supprime HTTPS -> HTTP -> boucle

• Cloudflare Flexible SSL — Le mode Flexible SSL de Cloudflare envoie les requetes a votre serveur d'origine en HTTP. Si votre origine possede egalement une redirection HTTP vers HTTPS, cela cree une boucle infinie entre Cloudflare et votre serveur

• Regles .htaccess conflictuelles — Plusieurs regles de redirection dans .htaccess qui se contredisent, comme une regle forcant www et une autre forcant sans www simultanement

• URLs WordPress non concordantes — L'adresse WordPress (URL) et l'adresse du site (URL) dans Reglages > Generaux ne correspondent pas, ou l'une utilise HTTP tandis que l'autre utilise HTTPS

• Cookies obsoletes du navigateur — D'anciens cookies contenant des instructions de redirection ou des donnees de session qui forcent le navigateur vers une URL qui n'existe plus ou a ete deplacee

• Redirections en cache du CDN ou proxy — Votre CDN a mis en cache une ancienne redirection 301 qui entre maintenant en conflit avec la configuration actuelle de votre serveur

• Conflits de configuration serveur — Des fichiers de configuration Nginx ou Apache avec des blocs de redirection concurrents, comme une redirection a la fois dans le bloc serveur et dans .htaccess

Comment diagnostiquer une boucle de redirection

Avant d'essayer des corrections, identifiez la chaine de redirection exacte. Cela vous indique precisement quelles URLs sont impliquees et quelles regles de redirection causent la boucle.

Methode 1 : Utiliser curl pour tracer les redirections

Le moyen le plus rapide de visualiser une chaine de redirection est d'utiliser curl dans votre terminal. L'option -I recupere uniquement les en-tetes, -L suit les redirections et --max-redirs limite le nombre de redirections a suivre :

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Si vous voyez les memes deux URLs alterner dans les en-tetes Location, vous avez confirme une boucle de redirection. Notez les codes de statut HTTP : 301 signifie redirection permanente (mise en cache par les navigateurs), 302 signifie temporaire (pas de mise en cache).

Methode 2 : Onglet Reseau des DevTools du navigateur

Vous pouvez egalement tracer les redirections visuellement dans Chrome DevTools :

• Etape 1 — Ouvrez Chrome DevTools avec F12 ou Ctrl+Shift+I (Mac : Cmd+Option+I)

• Etape 2 — Allez dans l'onglet Network et cochez Preserve log (cela conserve les entrees entre les redirections)

• Etape 3 — Chargez la page qui declenche l'erreur

• Etape 4 — Observez la sequence de requetes. Chaque redirection apparait comme une entree distincte avec le statut 301 ou 302. La colonne Location indique ou chaque redirection pointe

L'onglet Network affiche la chaine de redirection complete par ordre chronologique. Vous verrez le schema : generalement deux ou trois URLs se repetant en boucle. Utilisez le HTTP Headers Checker de DNS Robot pour inspecter les en-tetes de reponse en dehors du cache de votre navigateur.

Methode 3 : Verificateur de redirections en ligne

Si vous n'avez pas acces au terminal, utilisez le Redirect Checker de DNS Robot pour tracer la chaine de redirection complete. Entrez l'URL et il affichera chaque saut, code de statut et destination finale, ou confirmera qu'une boucle existe. Cet outil est pratique car il effectue la verification depuis un emplacement neutre sans que les cookies de votre navigateur n'affectent le resultat.

Correction 1 : Vider les cookies et le cache du navigateur

Commencez par la correction la plus simple. Les cookies obsoletes ou les redirections en cache dans votre navigateur peuvent provoquer des boucles meme lorsque la configuration du serveur est correcte. C'est particulierement courant apres la migration d'un site de HTTP vers HTTPS : les anciens cookies peuvent encore referencer des URLs HTTP.

Vider les cookies dans Chrome

Videz les cookies du site concerne plutot que tous les cookies : cela preserve vos connexions sur les autres sites :

• Etape 1 — Cliquez sur l'icone du cadenas (ou l'icone de reglage) dans la barre d'adresse a cote de l'URL

• Etape 2 — Cliquez sur Parametres du site

• Etape 3 — Cliquez sur Effacer les donnees pour supprimer les cookies et les donnees en cache de ce site uniquement

• Etape 4 — Rechargez la page

# Chrome keyboard shortcut to open Clear Browsing Data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Vous pouvez aussi aller a chrome://settings/clearBrowserData, selectionner Cookies et autres donnees de site et Images et fichiers en cache, definir la periode sur Toutes les periodes, puis cliquer sur Effacer les donnees.

Vider les cookies dans Firefox et Safari

Firefox : Appuyez sur Ctrl+Shift+Delete (Mac : Cmd+Shift+Delete), selectionnez Cookies et Cache, definissez la periode sur Tout et cliquez sur Effacer maintenant.

Safari : Allez dans Safari > Reglages > Confidentialite > Gerer les donnees de sites web, recherchez le domaine concerne, selectionnez-le et cliquez sur Supprimer. Ensuite, videz le cache avec Cmd+Option+E.

Correction 2 : Verifier la configuration SSL/HTTPS

La mauvaise configuration SSL est la cause numero 1 des boucles de redirection. Le scenario le plus courant est un conflit entre votre CDN/proxy et votre serveur d'origine sur l'utilisation de HTTP ou HTTPS.

Voici ce qui se passe generalement : votre CDN se connecte a l'origine en HTTP (car il gere la terminaison SSL), mais l'origine possede une redirection HTTP vers HTTPS. L'origine renvoie le CDN vers HTTPS, le CDN supprime HTTPS et renvoie du HTTP : boucle infinie.

• Verifiez votre certificat SSL — Utilisez le SSL Checker de DNS Robot pour verifier que votre certificat est valide, non expire et couvre le bon domaine

• Faites correspondre les protocoles — Si votre CDN gere la terminaison SSL, supprimez la redirection HTTP vers HTTPS sur votre origine, ou configurez le CDN pour se connecter a l'origine en HTTPS

• Verifiez les parametres de HTTPS force — Si vous avez a la fois une redirection au niveau du serveur (Nginx/Apache) ET une redirection au niveau du CDN pour forcer HTTPS, supprimez-en une

• Verifiez l'en-tete X-Forwarded-Proto — Derriere un proxy, votre origine doit verifier cet en-tete au lieu du protocole de connexion brut pour determiner si la requete originale etait en HTTPS

Correction 3 : Corriger les boucles de redirection Cloudflare

Cloudflare est le declencheur le plus courant de ERR_TOO_MANY_REDIRECTS en raison du fonctionnement de ses modes SSL. La correction depend du mode de chiffrement SSL/TLS que vous utilisez.

La correction pour 90 % des boucles de redirection Cloudflare : changez votre mode de chiffrement SSL/TLS de Flexible a Full ou Full (Strict). Cela indique a Cloudflare de se connecter a votre origine en HTTPS, eliminant ainsi la boucle HTTP vers HTTPS.

Correction Cloudflare etape par etape

• Etape 1 — Connectez-vous au tableau de bord Cloudflare

• Etape 2 — Selectionnez votre domaine

• Etape 3 — Allez dans SSL/TLS > Overview

• Etape 4 — Changez le mode de chiffrement en Full (Strict) si vous avez un certificat SSL valide sur votre origine, ou Full si vous avez un certificat auto-signe

• Etape 5 — Allez dans SSL/TLS > Edge Certificates et verifiez si Always Use HTTPS est active. Si votre origine redirige deja vers HTTPS, desactivez cette option pour eviter une double redirection

• Etape 6 — Verifiez les Page Rules et Redirect Rules pour d'eventuelles redirections d'URL conflictuelles

• Etape 7 — Purgez le cache Cloudflare : allez dans Caching > Configuration > Purge Everything

Correction 4 : Corriger les regles de redirection .htaccess (Apache)

Sur les serveurs Apache, .htaccess est l'emplacement le plus courant pour les regles de redirection et l'endroit ou les boucles de redirection naissent le plus souvent. Des regles conflictuelles, des redirections en double ou des conditions manquantes peuvent toutes creer des boucles.

• Recherchez les redirections HTTPS en double — Si votre panneau d'hebergement (cPanel, Plesk) force HTTPS, supprimez la redirection manuelle dans .htaccess

• Verifiez les conditions RewriteCond — Chaque RewriteRule qui redirige doit avoir un RewriteCond qui empeche son declenchement sur les URLs deja conformes. Sans cela, la regle s'execute a chaque requete, y compris celle deja redirigee

• Attention au drapeau [L] — Le drapeau [L] signifie 'derniere regle' mais uniquement pour le passage en cours. Si un autre .htaccess existe dans un sous-repertoire, il s'execute a nouveau. Utilisez [END] sur Apache 2.4+ a la place

• Verifiez les en-tetes de proxy — Derriere un CDN, utilisez %{HTTP:X-Forwarded-Proto} au lieu de %{HTTPS} pour detecter le protocole d'origine

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Si vous ne savez pas quelle regle cause la boucle, renommez temporairement .htaccess en .htaccess.bak et testez si le site se charge. Si c'est le cas, le probleme se trouve dans votre fichier .htaccess. Reactivez les regles une par une jusqu'a trouver celle qui pose probleme.

Correction 5 : Corriger les boucles de redirection WordPress

Les boucles de redirection WordPress proviennent generalement de trois sources : des URLs non concordantes dans les Reglages, des conflits de plugins ou des valeurs incorrectes dans wp-config.php. Si vous ne pouvez pas acceder au tableau de bord WordPress a cause de la boucle de redirection, vous devrez corriger le probleme directement via la base de donnees ou les fichiers de configuration.

Verifier les parametres d'URL WordPress

WordPress possede deux parametres d'URL qui doivent correspondre : Adresse web de WordPress (URL) et Adresse web du site (URL) dans Reglages > Generaux. Si l'une utilise http:// et l'autre https://, ou si l'une inclut www. et l'autre non, vous obtiendrez une boucle de redirection.

Si vous ne pouvez pas acceder au tableau de bord, definissez les URLs directement dans wp-config.php :

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Desactiver les plugins pour trouver les conflits

Les plugins de redirection et de cache sont souvent en cause. Des plugins comme Redirection, Yoast SEO, Really Simple SSL, WP Super Cache et W3 Total Cache peuvent ajouter des regles de redirection qui entrent en conflit avec la configuration de votre serveur ou CDN.

Si vous ne pouvez pas acceder au tableau de bord, desactivez tous les plugins via FTP ou SSH :

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Si la desactivation des plugins corrige l'erreur, reactivez-les un par un pour identifier le plugin fautif. Les coupables les plus courants sont les plugins SSL qui ajoutent des redirections HTTP vers HTTPS alors que votre serveur ou CDN gere deja cette tache.

Correction 6 : Corriger les redirections au niveau serveur (Nginx et Apache)

Les fichiers de configuration serveur peuvent contenir des regles de redirection qui entrent en conflit avec les redirections au niveau applicatif (WordPress, .htaccess) ou les parametres du CDN.

Nginx : Rechercher les conflits de redirection

Les boucles de redirection Nginx surviennent generalement lorsque le bloc serveur HTTP redirige vers HTTPS, mais quelque chose dans le bloc HTTPS redirige vers HTTP. Verifiez la configuration de votre site :

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Apache : Verifier les redirections VirtualHost

Sous Apache, verifiez a la fois la configuration VirtualHost et .htaccess. Une redirection dans la configuration VirtualHost plus une redirection dans .htaccess cree une double redirection qui peut boucler :

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Supprimez les redirections en double : ne conservez la redirection qu'a un seul endroit. La bonne pratique est de gerer les redirections HTTPS dans la configuration VirtualHost (pas dans .htaccess) car les regles VirtualHost sont traitees une fois par requete tandis que .htaccess est traite a chaque requete.

Correction 7 : Depannage specifique au navigateur

Si l'erreur n'apparait que dans un seul navigateur, il s'agit probablement d'une redirection en cache ou d'un conflit d'extension plutot que d'un probleme serveur.

Chrome : Effacer le HSTS et le pool de sockets

Chrome met en cache les politiques HSTS (HTTP Strict Transport Security) qui forcent HTTPS. Si un site a precedemment envoye un en-tete HSTS mais n'utilise plus correctement HTTPS, Chrome continuera a rediriger vers HTTPS meme apres avoir vide les cookies.

• Effacer le cache HSTS — Allez a chrome://net-internals/#hsts, entrez le domaine dans Delete domain security policies et cliquez sur Delete

• Vider les pools de sockets — Allez a chrome://net-internals/#sockets et cliquez sur Flush socket pools pour effacer toute connexion en cache

• Effacer le cache DNS — Allez a chrome://net-internals/#dns et cliquez sur Clear host cache

• Tester en Navigation privee — Ouvrez une fenetre de Navigation privee (Ctrl+Shift+N) et testez l'URL. Si cela fonctionne en Navigation privee mais pas en mode normal, une redirection en cache ou une extension est la cause

Corrections pour Firefox et Safari

Firefox : Tapez about:config dans la barre d'adresse, recherchez network.http.redirection-limit et verifiez qu'il est defini sur 20 (par defaut). Si une extension a modifie cette valeur a un nombre tres bas, les redirections peuvent echouer prematurement. Essayez aussi de supprimer les donnees du site : Parametres > Vie privee et securite > Gerer les donnees > recherchez le domaine > Supprimer la selection.

Safari : Safari affiche "too many redirects occurred" et fournit un message d'erreur moins detaille que Chrome. Allez dans Safari > Reglages > Confidentialite > Gerer les donnees de sites web, trouvez le domaine et supprimez ses donnees. Si le probleme persiste, essayez Safari > Effacer l'historique (choisissez tout l'historique).

Comment prevenir les boucles de redirection

Une fois l'erreur corrigee, suivez ces bonnes pratiques pour eviter que les boucles de redirection ne se reproduisent :

• Redirigez a un seul endroit — Choisissez une seule couche pour votre redirection HTTPS : le CDN, le serveur web ou l'application. Ne redirigez jamais a plusieurs niveaux simultanement

• Utilisez 302 pendant les tests — Pendant le debogage, utilisez des redirections 302 (temporaires) au lieu de 301 (permanentes). Les navigateurs mettent en cache les 301 de maniere agressive, rendant les tests difficiles. Passez a 301 une fois que vous confirmez que la redirection fonctionne correctement

• Testez toujours avec curl — Apres avoir ajoute une regle de redirection, executez curl -ILs https://votresite.com | grep -i 'HTTP/\|location:' pour verifier que la chaine de redirection se termine par une reponse 200

• Surveillez avec des outils — Utilisez regulierement le HTTP Headers Checker de DNS Robot pour verifier que votre site renvoie une reponse 200 propre sans redirections inattendues

• Documentez vos redirections — Tenez un registre de toutes les regles de redirection dans la configuration serveur, .htaccess, les regles CDN et les parametres applicatifs. Quand plusieurs membres de l'equipe gerent un site, les redirections non documentees sont la cause numero 1 des boucles

• Purgez le cache CDN apres les modifications — Apres avoir modifie une regle de redirection, purgez immediatement le cache de votre CDN. Les anciennes 301 en cache peuvent persister pendant des jours

Impact SEO des boucles de redirection

Les boucles de redirection nuisent directement a votre classement dans les moteurs de recherche. Le robot d'exploration de Google (Googlebot) suit jusqu'a 10 redirections par URL avant d'abandonner. Si Googlebot rencontre une boucle de redirection, il marque la page comme erreur d'exploration et cesse de l'indexer.

Selon la documentation de Google sur les redirections, les chaines de redirection doivent etre aussi courtes que possible. Chaque saut de redirection supplementaire ajoute environ 100 a 500 ms de latence et gaspille votre budget de crawl : le nombre de pages que Google explorera sur votre site par jour.

• Perte d'indexation — Les pages prises dans des boucles de redirection ne sont pas indexees et disparaissent completement des resultats de recherche

• Gaspillage du budget de crawl — Googlebot depense son budget de crawl limite a suivre des redirections au lieu d'explorer du contenu reel

• Penalite de vitesse de page — Chaque redirection 301 ajoute un aller-retour complet (100-500 ms). Trois redirections peuvent ajouter plus d'une seconde au temps de chargement

• Dilution du link equity — Les backlinks pointant vers une URL en redirection perdent environ 1 a 5 % de leur valeur PageRank a chaque saut

Questions frequemment posees