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 piégé dans une boucle de redirection infinie. Au lieu de charger la page, le navigateur rebondit continuellement entre les URLs, et après avoir atteint sa limite de redirections, il abandonne et affiche cette erreur.

Chaque navigateur possède une limite de redirections intégrée pour empêcher les boucles infinies de consommer des ressources. Lorsqu'une page dépasse cette limite, la connexion est interrompue avec un message d'erreur.

Les codes de statut HTTP dans une boucle de redirection sont généralement 301 (redirection permanente) ou 302 (redirection temporaire). Une boucle typique fonctionne ainsi : votre navigateur demande l'URL A, le serveur répond avec un 301 vers l'URL B, l'URL B répond avec un 301 vers l'URL A, et le cycle se répète jusqu'à ce que le navigateur atteigne sa limite.

Quelles sont les causes des boucles de redirection ?

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

• Mauvaise configuration SSL/HTTPS — La cause la plus fréquente. Votre serveur force la redirection HTTP vers HTTPS, mais votre CDN ou répartiteur de charge se connecte à l'origine en HTTP, créant 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 requêtes à votre serveur d'origine en HTTP. Si votre origine possède également une redirection HTTP vers HTTPS, cela crée une boucle infinie entre Cloudflare et votre serveur

• Règles .htaccess conflictuelles — Plusieurs règles de redirection dans .htaccess qui se contredisent, comme une règle forçant www et une autre forçant sans www simultanément

• URLs WordPress non concordantes — L'adresse WordPress (URL) et l'adresse du site (URL) dans Réglages > Général ne correspondent pas, ou l'une utilise HTTP tandis que l'autre utilise HTTPS

• Cookies obsolètes du navigateur — D'anciens cookies contenant des instructions de redirection ou des données de session qui forcent le navigateur vers une URL qui n'existe plus ou a été déplacée

• 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 à la fois dans le bloc serveur et dans .htaccess

Comment diagnostiquer une boucle de redirection

Avant d'essayer des corrections, identifiez la chaîne de redirection exacte. Cela vous indique précisément quelles URLs sont impliquées et quelles règles de redirection causent la boucle.

Méthode 1 : Utiliser curl pour tracer les redirections

Le moyen le plus rapide de visualiser une chaîne de redirection est d'utiliser curl dans votre terminal. L'option -I récupère uniquement les en-têtes, -L suit les redirections et --max-redirs limite le nombre de redirections à 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 mêmes deux URLs alterner dans les en-têtes Location, vous avez confirmé 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).

Méthode 2 : Onglet Réseau des DevTools du navigateur

Vous pouvez également tracer les redirections visuellement dans Chrome DevTools :

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

• Étape 2 — Allez dans l'onglet Network et cochez Preserve log (cela conserve les entrées entre les redirections)

• Étape 3 — Chargez la page qui déclenche l'erreur

• Étape 4 — Observez la séquence de requêtes. Chaque redirection apparaît comme une entrée distincte avec le statut 301 ou 302. La colonne Location indique où chaque redirection pointe

L'onglet Network affiche la chaîne de redirection complète par ordre chronologique. Vous verrez le schéma : généralement deux ou trois URLs se répétant en boucle. Utilisez le HTTP Headers Checker de DNS Robot pour inspecter les en-têtes de réponse en dehors du cache de votre navigateur.

Méthode 3 : Vérificateur de redirections en ligne

Si vous n'avez pas accès au terminal, utilisez le Redirect Checker de DNS Robot pour tracer la chaîne de redirection complète. 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 vérification depuis un emplacement neutre sans que les cookies de votre navigateur n'affectent le résultat.

Correction 1 : Vider les cookies et le cache du navigateur

Commencez par la correction la plus simple. Les cookies obsolètes ou les redirections en cache dans votre navigateur peuvent provoquer des boucles même lorsque la configuration du serveur est correcte. C'est particulièrement courant après la migration d'un site de HTTP vers HTTPS : les anciens cookies peuvent encore référencer des URLs HTTP.

Vider les cookies dans Chrome

Videz les cookies du site concerné plutôt que tous les cookies : cela préserve vos connexions sur les autres sites :

• Étape 1 — Cliquez sur l'icône du cadenas (ou l'icône de réglage) dans la barre d'adresse à côté de l'URL

• Étape 2 — Cliquez sur Paramètres du site

• Étape 3 — Cliquez sur Effacer les données pour supprimer les cookies et les données en cache de ce site uniquement

• Étape 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 à chrome://settings/clearBrowserData, sélectionner Cookies et autres données de site et Images et fichiers en cache, définir la période sur Toutes les périodes, puis cliquer sur Effacer les données.

Vider les cookies dans Firefox et Safari

Firefox : Appuyez sur Ctrl+Shift+Delete (Mac : Cmd+Shift+Delete), sélectionnez Cookies et Cache, définissez la période sur Tout et cliquez sur Effacer maintenant.

Safari : Allez dans Safari > Réglages > Confidentialité > Gérer les données de sites web, recherchez le domaine concerné, sélectionnez-le et cliquez sur Supprimer. Ensuite, videz le cache avec Cmd+Option+E.

Correction 2 : Vérifier la configuration SSL/HTTPS

La mauvaise configuration SSL est la cause numéro 1 des boucles de redirection. Le scénario 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 généralement : votre CDN se connecte à l'origine en HTTP (car il gère la terminaison SSL), mais l'origine possède une redirection HTTP vers HTTPS. L'origine renvoie le CDN vers HTTPS, le CDN supprime HTTPS et renvoie du HTTP : boucle infinie.

• Vérifiez votre certificat SSL — Utilisez le SSL Checker de DNS Robot pour vérifier que votre certificat est valide, non expiré et couvre le bon domaine

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

• Vérifiez les paramètres de HTTPS forcé — Si vous avez à la fois une redirection au niveau du serveur (Nginx/Apache) ET une redirection au niveau du CDN pour forcer HTTPS, supprimez-en une

• Vérifiez l'en-tête X-Forwarded-Proto — Derrière un proxy, votre origine doit vérifier cet en-tête au lieu du protocole de connexion brut pour déterminer si la requête originale était en HTTPS

Correction 3 : Corriger les boucles de redirection Cloudflare

Cloudflare est le déclencheur le plus courant de ERR_TOO_MANY_REDIRECTS en raison du fonctionnement de ses modes SSL. La correction dépend 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 à Full ou Full (Strict). Cela indique à Cloudflare de se connecter à votre origine en HTTPS, éliminant ainsi la boucle HTTP vers HTTPS.

Correction Cloudflare étape par étape

• Étape 1 — Connectez-vous au tableau de bord Cloudflare

• Étape 2 — Sélectionnez votre domaine

• Étape 3 — Allez dans SSL/TLS > Overview

• Étape 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-signé

• Étape 5 — Allez dans SSL/TLS > Edge Certificates et vérifiez si Always Use HTTPS est activé. Si votre origine redirige déjà vers HTTPS, désactivez cette option pour éviter une double redirection

• Étape 6 — Vérifiez les Page Rules et Redirect Rules pour d'éventuelles redirections d'URL conflictuelles

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

Correction 4 : Corriger les règles de redirection .htaccess (Apache)

Sur les serveurs Apache, .htaccess est l'emplacement le plus courant pour les règles de redirection et l'endroit où les boucles de redirection naissent le plus souvent. Des règles conflictuelles, des redirections en double ou des conditions manquantes peuvent toutes créer des boucles.

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

• Vérifiez les conditions RewriteCond — Chaque RewriteRule qui redirige doit avoir un RewriteCond qui empêche son déclenchement sur les URLs déjà conformes. Sans cela, la règle s'exécute à chaque requête, y compris celle déjà redirigée

• Attention au drapeau [L] — Le drapeau [L] signifie 'dernière règle' mais uniquement pour le passage en cours. Si un autre .htaccess existe dans un sous-répertoire, il s'exécute à nouveau. Utilisez [END] sur Apache 2.4+ à la place

• Vérifiez les en-têtes de proxy — Derrière un CDN, utilisez %{HTTP:X-Forwarded-Proto} au lieu de %{HTTPS} pour détecter 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 règle cause la boucle, renommez temporairement .htaccess en .htaccess.bak et testez si le site se charge. Si c'est le cas, le problème se trouve dans votre fichier .htaccess. Réactivez les règles une par une jusqu'à trouver celle qui pose problème.

Correction 5 : Corriger les boucles de redirection WordPress

Les boucles de redirection WordPress proviennent généralement de trois sources : des URLs non concordantes dans les Réglages, des conflits de plugins ou des valeurs incorrectes dans wp-config.php. Si vous ne pouvez pas accéder au tableau de bord WordPress à cause de la boucle de redirection, vous devrez corriger le problème directement via la base de données ou les fichiers de configuration.

Vérifier les paramètres d'URL WordPress

WordPress possède deux paramètres d'URL qui doivent correspondre : Adresse web de WordPress (URL) et Adresse web du site (URL) dans Réglages > Général. 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 accéder au tableau de bord, définissez 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';
}

Désactiver 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 règles de redirection qui entrent en conflit avec la configuration de votre serveur ou CDN.

Si vous ne pouvez pas accéder au tableau de bord, désactivez 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 désactivation des plugins corrige l'erreur, réactivez-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 gère déjà cette tâche.

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

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

Nginx : Rechercher les conflits de redirection

Les boucles de redirection Nginx surviennent généralement lorsque le bloc serveur HTTP redirige vers HTTPS, mais quelque chose dans le bloc HTTPS redirige vers HTTP. Vérifiez 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 : Vérifier les redirections VirtualHost

Sous Apache, vérifiez à la fois la configuration VirtualHost et .htaccess. Une redirection dans la configuration VirtualHost plus une redirection dans .htaccess crée 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'à un seul endroit. La bonne pratique est de gérer les redirections HTTPS dans la configuration VirtualHost (pas dans .htaccess) car les règles VirtualHost sont traitées une fois par requête tandis que .htaccess est traité à chaque requête.

Correction 7 : Dépannage spécifique au navigateur

Si l'erreur n'apparaît que dans un seul navigateur, il s'agit probablement d'une redirection en cache ou d'un conflit d'extension plutôt que d'un problème 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 précédemment envoyé un en-tête HSTS mais n'utilise plus correctement HTTPS, Chrome continuera à rediriger vers HTTPS même après avoir vidé les cookies.

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

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

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

• Tester en Navigation privée — Ouvrez une fenêtre de Navigation privée (Ctrl+Shift+N) et testez l'URL. Si cela fonctionne en Navigation privée 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 vérifiez qu'il est défini sur 20 (par défaut). Si une extension a modifié cette valeur à un nombre très bas, les redirections peuvent échouer prématurément. Essayez aussi de supprimer les données du site : Paramètres > Vie privée et sécurité > Gérer les données > recherchez le domaine > Supprimer la sélection.

Safari : Safari affiche "too many redirects occurred" et fournit un message d'erreur moins détaillé que Chrome. Allez dans Safari > Réglages > Confidentialité > Gérer les données de sites web, trouvez le domaine et supprimez ses données. Si le problème persiste, essayez Safari > Effacer l'historique (choisissez tout l'historique).

Comment prévenir les boucles de redirection

Une fois l'erreur corrigée, suivez ces bonnes pratiques pour éviter que les boucles de redirection ne se reproduisent :

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

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

• Testez toujours avec curl — Après avoir ajouté une règle de redirection, exécutez curl -ILs https://votresite.com | grep -i 'HTTP/\|location:' pour vérifier que la chaîne de redirection se termine par une réponse 200

• Surveillez avec des outils — Utilisez régulièrement le HTTP Headers Checker de DNS Robot pour vérifier que votre site renvoie une réponse 200 propre sans redirections inattendues

• Documentez vos redirections — Tenez un registre de toutes les règles de redirection dans la configuration serveur, .htaccess, les règles CDN et les paramètres applicatifs. Quand plusieurs membres de l'équipe gèrent un site, les redirections non documentées sont la cause numéro 1 des boucles

• Purgez le cache CDN après les modifications — Après avoir modifié une règle de redirection, purgez immédiatement 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 à votre classement dans les moteurs de recherche. Le robot d'exploration de Google (Googlebot) suit jusqu'à 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 chaînes de redirection doivent être aussi courtes que possible. Chaque saut de redirection supplémentaire ajoute environ 100 à 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 indexées et disparaissent complètement des résultats de recherche

• Gaspillage du budget de crawl — Googlebot dépense son budget de crawl limité à suivre des redirections au lieu d'explorer du contenu réel

• Pénalité 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 à 5 % de leur valeur PageRank à chaque saut