Causes sous-jacentes et solutions pour l’erreur “Too Many Redirects”

L’erreur "Too Many Redirects" — affichée dans les navigateurs sous la forme ERR_TOO_MANY_REDIRECTS et correspondant à une boucle de redirection HTTP — se produit lorsqu’un serveur web et un client entrent dans une chaîne circulaire de redirections qui ne se résout jamais vers une destination finale. Le navigateur abandonne la requête après avoir dépassé son seuil de redirections (généralement 20 sauts dans Chrome) et affiche cette erreur au lieu de charger la page.

Il ne s’agit pas d’un vague problème réseau. C’est une défaillance déterministe causée par une mauvaise configuration spécifique dans vos règles serveur, paramètres SSL, valeurs de base de données CMS, configuration CDN ou données de redirection mises en cache. Chaque instance a une cause racine traçable, et chaque cause racine a une correction précise. Ce guide les passe toutes en revue avec la profondeur technique nécessaire pour résoudre le problème de façon permanente — que vous exploitiez un site WordPress, une application personnalisée ou une pile serveur brute dans un environnement VPS Hosting.

Ce qui se passe réellement lors d’une boucle de redirection

Lorsqu’un navigateur demande une URL, le serveur peut répondre avec un code de statut 301 Moved Permanently, 302 Found ou 307 Temporary Redirect pointant vers un nouvel emplacement. Le navigateur suit cet en-tête de localisation, effectue une autre requête et s’attend à recevoir une réponse 200 OK à un moment donné dans la chaîne.

Une boucle de redirection se forme lorsque :

• L’URL A redirige vers l’URL B, et l’URL B redirige vers l’URL A (boucle à deux sauts)
• L’URL A redirige vers l’URL B, qui redirige vers l’URL C, qui redirige vers l’URL A (boucle à plusieurs sauts)
• Une seule URL se redirige vers elle-même (boucle auto-référentielle)

Les navigateurs ne bouclent pas indéfiniment. Chrome et Firefox terminent tous deux après environ 20 redirections et affichent ERR_TOO_MANY_REDIRECTS. Safari affiche "Safari Can't Open the Page." Le comportement HTTP sous-jacent est identique pour tous.

Causes racines et corrections précises

1. Règles de redirection mal configurées dans .htaccess ou Nginx

La cause techniquement la plus courante est la présence de règles de réécriture conflictuelles ou circulaires dans la couche de configuration du serveur.

Exemple de boucle défectueuse dans .htaccess Apache :

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Cette règle redirige /page vers /page — une boucle auto-référentielle. De même, deux règles qui redirigent entre /old-url et /new-url dans des directions opposées provoqueront le même échec.

Comment diagnostiquer :

Ouvrez votre fichier .htaccess et tracez manuellement chaque directive RewriteRule et Redirect. Recherchez toute règle dont le modèle cible peut correspondre à la source d’une autre règle.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Pour Nginx, le problème équivalent apparaît dans les blocs server ou location :

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Auditez votre configuration Nginx avec :

nginx -T | grep -A3 "return 301|rewrite"

Correction : Assurez-vous que chaque règle de redirection a une source et une destination uniques et non chevauchantes. Utilisez le drapeau [L] dans Apache pour arrêter le traitement des règles dès qu’une correspondance est trouvée. Dans Nginx, préférez return 301 à rewrite pour plus de clarté et pour éviter un chaînage involontaire.

2. Mauvaise configuration de la redirection HTTP vers HTTPS

C’est la cause la plus courante dans les environnements d’hébergement modernes, notamment après l’ajout d’un Certificat SSL sans mise à jour de la configuration au niveau de l’application.

Le schéma de défaillance ressemble à ceci :

• Le serveur web force tout le trafic HTTP vers HTTPS via .htaccess ou la configuration Nginx
• L’application (par exemple WordPress) a son option siteurl ou home définie sur http:// dans la base de données
• L’application redirige ensuite les requêtes HTTPS vers HTTP
• La boucle est : HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Redirection HTTPS correcte dans .htaccess Apache :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Redirection HTTPS correcte dans Nginx :

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Piège critique : Si vous êtes derrière un équilibreur de charge ou un proxy inverse (y compris Cloudflare), le serveur backend peut ne pas voir HTTPS directement. Le proxy termine le SSL et transmet la requête en HTTP à votre origine. Votre serveur voit alors %{HTTPS} = off et redirige à nouveau vers HTTPS — créant une boucle.

La correction consiste à vérifier l’en-tête X-Forwarded-Proto à la place :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Incompatibilité du mode SSL entre Cloudflare et le CDN

Si vous utilisez Cloudflare ou un autre CDN devant votre serveur d’origine, le mode de chiffrement SSL/TLS doit correspondre au statut réel du certificat de votre origine.

Le scénario de boucle Cloudflare le plus courant : le mode SSL est défini sur Flexible, et le serveur d’origine a une règle .htaccess forçant HTTP vers HTTPS. Cloudflare envoie HTTP à l’origine, l’origine redirige vers HTTPS, Cloudflare reçoit cette redirection, envoie à nouveau HTTP — boucle infinie.

Correction : Définissez le mode SSL Cloudflare sur Full (Strict) et assurez-vous que votre origine dispose d’un certificat valide. Alternativement, si vous devez utiliser Flexible, supprimez entièrement la redirection HTTP→HTTPS de votre serveur d’origine et laissez Cloudflare la gérer via une règle de page ou le bouton "Always Use HTTPS".

Désactivez également les Automatic HTTPS Rewrites dans Cloudflare si votre origine gère déjà les redirections — avoir les deux actifs double la logique de redirection.

4. Incompatibilité des paramètres d’URL WordPress

WordPress stocke ses URL canoniques dans deux champs de base de données : siteurl (l’URL d’installation du cœur WordPress) et home (l’URL publique). Lorsque ces valeurs entrent en conflit avec les règles de redirection du serveur ou entre elles, une boucle est presque inévitable.

Vérifier les valeurs actuelles via WP-CLI :

wp option get siteurl
wp option get home

Ou interroger directement la base de données :

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Les deux valeurs doivent utiliser le même protocole (https://) et le même format de domaine (avec ou sans www) que celui appliqué par votre configuration serveur.

Correction via WP-CLI :

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Correction via wp-config.php (remplace les valeurs de la base de données, utile en cas de blocage hors du panneau d’administration) :

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Conflits de plugins : Les plugins de gestion des redirections (Redirection, Simple 301 Redirects, le module de redirection de Yoast SEO) peuvent créer des règles de redirection stockées en base de données qui entrent en conflit avec les règles au niveau du serveur. Renommez temporairement le répertoire des plugins pour isoler le problème :

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Réactivez les plugins un par un après avoir confirmé que la boucle a disparu.

5. Cache navigateur et redirections 301 mises en cache

Les navigateurs mettent en cache les réponses 301 Moved Permanently de manière agressive — par conception. Si une redirection 301 a été précédemment servie pour une URL et que la cible de redirection a ensuite été modifiée, le navigateur peut toujours suivre l’ancienne redirection mise en cache, qui peut pointer vers une destination désormais en boucle.

Il s’agit d’un scénario particulièrement trompeur car la boucle peut ne pas se reproduire sur un navigateur récent ou un autre appareil, amenant les administrateurs à conclure à tort que le serveur fonctionne correctement.

Étapes de diagnostic :

1. Ouvrez l’URL dans une fenêtre de navigation privée/incognito (sans données en cache)
2. Testez avec curl pour contourner entièrement le cache du navigateur :

curl -I -L --max-redirs 10 https://example.com

1. Utilisez un traceur de chaîne de redirections en ligne (par exemple redirect-checker.org ou httpstatus.io) pour voir chaque saut côté serveur

Correction : Videz le cache du navigateur et les cookies pour le domaine concerné. Dans Chrome : Paramètres > Confidentialité et sécurité > Effacer les données de navigation > sélectionnez Images et fichiers en cache + Cookies.

Pour la mise en cache côté serveur (Varnish, Redis, OPcache ou un plugin de cache comme W3 Total Cache) :

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Conflits de redirection www vs. non-www

Une source souvent négligée de boucles de redirection est la gestion incohérente du sous-domaine www. Si votre serveur redirige www.example.com vers example.com et redirige simultanément example.com vers www.example.com, vous avez une boucle.

Vérifiez votre configuration DNS et de redirection actuelle :

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Configuration Apache correcte (non-www canonique) :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Assurez-vous que cette règle n’est pas associée à une autre règle qui redirige la version non-www vers www.

7. Cookies corrompus ou conflictuels

Certaines applications utilisent des cookies pour gérer l’état des redirections (par exemple, redirections de connexion, détection de la langue, frameworks de tests A/B). Si un cookie stocke une cible de redirection qui déclenche elle-même une autre redirection, la boucle est pilotée par la logique applicative plutôt que par la configuration du serveur.

Diagnostic : Testez l’URL avec tous les cookies effacés pour ce domaine. Dans Chrome DevTools (F12), allez dans Application > Storage > Cookies, sélectionnez le domaine et supprimez toutes les entrées. Rechargez la page.

Si l’erreur disparaît après avoir effacé les cookies, le problème se trouve dans la logique de session ou de redirection de votre application, et non dans la configuration du serveur.

Comparaison : scénarios courants de boucles de redirection et leurs corrections

Procédure de diagnostic systématique

Avant de toucher à un fichier de configuration, suivez cette séquence pour isoler la cause :

Étape 1 — Reproduire sans cache :

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Cela affiche chaque saut de redirection et le code de réponse final. Si vous voyez les mêmes URL se répéter, vous avez confirmé la boucle et identifié les URL impliquées.

Étape 2 — Vérifier les journaux d’erreurs du serveur :

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Étape 3 — Isoler la couche :

• Si la boucle disparaît lorsque vous commentez les règles .htaccess, le problème se trouve dans la configuration Apache
• Si elle disparaît lorsque vous contournez Cloudflare (test via IP directe), le problème se trouve dans les paramètres CDN
• Si elle disparaît lorsque vous renommez le répertoire des plugins, le problème se trouve dans un plugin WordPress
• Si elle disparaît en navigation privée mais pas en mode normal, le problème est lié au cache du navigateur ou aux cookies

Étape 4 — Valider la liaison du certificat SSL :

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Un certificat invalide ou mal associé peut provoquer des échecs de redirection HTTPS qui se manifestent sous forme de boucles.

Prévenir les boucles de redirection en production

Une fois résolues, ces pratiques préviennent la récurrence :

• Utilisez une seule règle de redirection canonique qui gère à la fois HTTP→HTTPS et www→non-www en un seul passage, et non deux règles séparées susceptibles d’interagir
• Testez les chaînes de redirection avant de déployer en utilisant curl -L ou un vérificateur de redirections en ligne après tout changement de configuration
• Définissez les redirections 301 uniquement lorsqu’elles sont permanentes — utilisez 302 pendant les tests pour que les navigateurs ne mettent pas la redirection en cache
• Documentez chaque règle de redirection dans votre .htaccess ou votre configuration Nginx avec des commentaires en ligne expliquant l’intention
• Surveillez avec des outils de disponibilité qui suivent les chaînes de redirections et alertent lorsque le nombre de sauts dépasse un seuil

Pour les équipes gérant plusieurs sites sur un VPS avec cPanel, le module Redirects de cPanel fournit une interface visuelle pour gérer les règles de redirection, mais il écrit dans .htaccess — vérifiez toujours le résultat manuellement après avoir utilisé l’interface graphique.

Si vous exploitez un site à fort trafic ou plusieurs domaines, un Serveur Dédié vous donne un contrôle total sur la configuration Nginx ou Apache au niveau système, éliminant les contraintes des environnements partagés qui peuvent compliquer le débogage des redirections.

Pour les sites utilisant des Panneaux de contrôle VPS comme Plesk ou DirectAdmin, les règles de redirection peuvent être gérées via l’interface du panneau ainsi que directement dans les fichiers de configuration — vérifiez les deux emplacements pour vous assurer qu’ils ne se contredisent pas.

Liste de contrôle technique des points clés

Utilisez ceci comme liste de contrôle préalable lors du diagnostic de ERR_TOO_MANY_REDIRECTS :

• [ ] Exécutez curl -v -L --max-redirs 25 pour cartographier la chaîne de redirection complète avant de toucher à une configuration
• [ ] Confirmez que siteurl et home dans WordPress correspondent au protocole et au domaine appliqués par votre serveur
• [ ] Vérifiez que le mode SSL Cloudflare est Full (Strict) si votre origine dispose d’un certificat valide
• [ ] Vérifiez que la configuration .htaccess ou Nginx utilise X-Forwarded-Proto au lieu de %{HTTPS} lorsqu’elle est derrière un proxy
• [ ] Assurez-vous que les redirections www et non-www sont unidirectionnelles — une seule forme canonique
• [ ] Désactivez temporairement tous les plugins liés aux redirections et réactivez-les un par un
• [ ] Videz le cache du navigateur et testez en navigation privée pour exclure les réponses 301 mises en cache
• [ ] Inspectez les cookies de l’application pour détecter un état de redirection susceptible de piloter une boucle
• [ ] Validez que le certificat SSL est valide et correctement associé au domaine
• [ ] Après correction, utilisez temporairement 302 avant de passer à 301 pour éviter de mettre en cache à nouveau une redirection défectueuse

FAQ

Quelle est la différence entre ERR_TOO_MANY_REDIRECTS et un code de statut HTTP 310 ?

ERR_TOO_MANY_REDIRECTS est une erreur côté client déclenchée par le navigateur après avoir dépassé sa limite de suivi de redirections (généralement 20). HTTP 310 est un code de statut rarement utilisé signifiant "Too Many Redirects" au niveau du protocole. En pratique, presque toutes les erreurs de boucle de redirection rencontrées en production sont des erreurs ERR_TOO_MANY_REDIRECTS côté navigateur — et non une réponse 310 émise par le serveur.

Pourquoi la boucle de redirection n’apparaît-elle que sur certains navigateurs ou appareils et pas sur d’autres ?

La raison la plus courante est une redirection 301 mise en cache dans le navigateur qui pointe vers une destination désormais invalide. Étant donné que les réponses 301 sont mises en cache indéfiniment par défaut, un navigateur ayant précédemment visité l’URL peut suivre une chaîne de redirection obsolète. Tester en navigation privée ou sur un nouvel appareil contourne ce cache et révèle le comportement actuel du serveur.

Comment corriger une boucle de redirection dans WordPress lorsque je ne peux pas accéder au panneau d’administration ?

Ajoutez les lignes suivantes directement dans wp-config.php pour remplacer les valeurs d’URL de la base de données, puis accédez au panneau d’administration pour corriger correctement les paramètres :

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Alternativement, mettez à jour les valeurs directement dans la base de données en utilisant wp-cli ou une requête MySQL directe sur la table wp_options.

Une boucle de redirection peut-elle affecter le classement SEO ?

Oui. Une boucle de redirection ne renvoie aucune réponse 200 OK, ce qui signifie que Googlebot ne peut pas explorer ni indexer l’URL concernée. Si la boucle affecte votre page d’accueil ou vos pages de destination clés, elle entraînera une désindexation au fil du temps. De plus, tout capital de liens 301 transitant par l’URL en boucle est effectivement perdu. Il est essentiel de résoudre la boucle rapidement et de vérifier l’explorabilité dans Google Search Console.

Comment empêcher Cloudflare de provoquer des boucles de redirection avec ma configuration SSL ?

Définissez le mode de chiffrement SSL/TLS de Cloudflare sur Full (Strict) dans le tableau de bord SSL/TLS. Cela garantit que Cloudflare communique avec votre origine via HTTPS en utilisant un certificat validé, éliminant la boucle HTTP↔HTTPS que le mode Flexible crée lorsque le serveur d’origine applique également HTTPS. De plus, désactivez "Automatic HTTPS Rewrites" si votre origine ou .htaccess gère déjà la redirection HTTP vers HTTPS, afin d’éviter une logique de double redirection.