Erreur ERR_TOO_MANY_REDIRECTS : causes et solutions

ERR_TOO_MANY_REDIRECTS signifie que le navigateur est pris dans une boucle de redirection : le serveur l’envoie de l’URL A vers l’URL B, puis de nouveau vers A, jusqu’à ce que Chrome ou Firefox abandonne après 20 sauts. La correction consiste presque toujours à supprimer l’une de deux règles contradictoires : le mode Flexible de Cloudflare combiné à une redirection HTTPS forcée sur le serveur, des adresses de site incohérentes (http ou https, avec ou sans www) entre WordPress et le panneau d’hébergement, ou des redirections en double dans .htaccess ou Nginx. Côté visiteur, il suffit généralement d’effacer les cookies du site ; côté propriétaire, il faut suivre la chaîne avec curl -IL.

Ce que signifie l’erreur et comment chaque navigateur l’affiche

Une redirection est une réponse du serveur avec le statut 301, 302, 307 ou 308 et un en-tête Location qui pointe vers la nouvelle URL. Un ou deux sauts sont normaux, par exemple de http://www.example.com vers https://example.com. Le problème commence quand la chaîne se referme en cercle ou devient trop longue : le navigateur cesse alors de la suivre.

Les messages sont cités tels que les affiche l’interface anglaise. Un navigateur en français affiche un texte traduit, mais le code ERR_TOO_MANY_REDIRECTS reste le même. Si Chrome conseille d’effacer les cookies, ce n’est pas un hasard : certaines boucles viennent des cookies. Le site vérifie la langue, la région ou l’état de connexion et vous renvoie sans cesse vers la même page.

Solutions rapides pour les visiteurs

• Ouvrez la page dans une fenêtre de navigation privée (Ctrl+Maj+N dans Chrome, Ctrl+Maj+P dans Firefox). Si elle s’affiche, la cause se trouve dans vos cookies ou votre cache.
• Supprimez uniquement les cookies de ce site : dans Chrome, cliquez sur l’icône à gauche de la barre d’adresse, ouvrez la section des cookies et données de site, puis supprimez les données du site.
• Videz les images et fichiers en cache (Ctrl+Maj+Suppr). Les navigateurs mémorisent les redirections 301 et peuvent rejouer une ancienne redirection alors que le propriétaire l’a déjà corrigée.
• Désactivez les extensions qui réécrivent les URL : VPN, proxys, bloqueurs de publicité, modules qui forcent HTTPS.
• Essayez depuis un téléphone en données mobiles. Si l’erreur apparaît partout, le problème vient du site : indiquez au propriétaire l’heure et l’URL exacte.

Causes fréquentes d’une boucle de redirection

Une boucle naît presque toujours de deux règles qui tirent l’URL dans des directions opposées :

Les redirections en cache sont un piège à part : le navigateur conserve les 301, une extension de cache ou un CDN peut servir une réponse enregistrée, et HSTS fait passer le navigateur en HTTPS de lui-même. Vérifiez donc toujours une correction dans une fenêtre privée ou avec curl.

Comment suivre la chaîne de redirections

Ne devinez pas, regardez où le serveur vous envoie réellement. curl est fourni avec Linux, macOS et Windows 10/11 (tapez curl.exe dans PowerShell) :

curl -sSIL --max-redirs 10 http://example.com/ | grep -iE "^(HTTP|location|server)"

Une boucle typique avec Cloudflare en mode Flexible :

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/2 301
location: https://example.com/
server: cloudflare
HTTP/2 301
location: https://example.com/
server: cloudflare
...
curl: (47) Maximum (10) redirects followed

Si Location répète sans cesse l’URL demandée, le serveur redirige vers lui-même. server: cloudflare indique que la réponse passe par Cloudflare : vérifiez alors le mode de chiffrement. Une alternance http/https ou www/sans www montre quelles deux règles s’affrontent. Pour tester l’origine sans Cloudflare, associez le domaine à l’IP de votre serveur :

curl -sSIL --max-redirs 10 --resolve example.com:443:203.0.113.10 https://example.com/

Dans le navigateur, ouvrez les DevTools (F12), allez dans l’onglet Network, activez Preserve log et rechargez la page. Chaque ligne en 301, 302, 307 ou 308 correspond à un saut. Une ligne 307 Internal Redirect avec Non-Authoritative-Reason: HSTS a été générée par le navigateur lui-même à cause d’une politique HSTS enregistrée, pas par le serveur.

Corriger ERR_TOO_MANY_REDIRECTS avec Cloudflare

En mode Flexible, Cloudflare accepte le visiteur en HTTPS mais se connecte à votre serveur en HTTP non chiffré. Si le serveur force HTTPS (réglage du panneau, .htaccess, Nginx ou extension WordPress), il répond par une redirection vers https://. Cloudflare la transmet au navigateur, le navigateur revient en HTTPS, et Cloudflare rappelle l’origine en HTTP. La documentation de Cloudflare cite ce scénario comme la première cause d’ERR_TOO_MANY_REDIRECTS.

1. Vérifiez que l’origine dispose d’un certificat valide (voir notre guide sur le certificat SSL sur un hébergement mutualisé). Dans le panneau de contrôle, un certificat Let’s Encrypt gratuit s’obtient en général en quelques minutes depuis les paramètres du domaine.
2. Dans Cloudflare, ouvrez SSL/TLS → Overview → Configure et choisissez Full (strict). Le mode Full simple ne sert qu’avec un certificat auto-signé sur l’origine.
3. Si la zone utilise Automatic SSL/TLS, vérifiez le mode réellement appliqué et passez en Custom SSL/TLS si nécessaire.
4. Passez en revue les Rules : les Redirect Rules et les anciennes Page Rules ne doivent pas contredire le serveur (par exemple Cloudflare qui envoie vers www alors que le serveur le retire).
5. Purgez le cache (Caching → Configuration → Purge Everything) si vous mettez le HTML en cache. Sans en-têtes de cache, Cloudflare conserve une 301 jusqu’à 120 minutes par défaut.

L’inverse arrive aussi : mode Full alors que le serveur ou WordPress redirige de HTTPS vers HTTP. Supprimez cette redirection et corrigez l’URL du site. Always Use HTTPS (SSL/TLS → Edge Certificates) est sans risque dans tous les modes, tant que rien sur l’origine n’envoie les visiteurs vers http. Pour une vue d’ensemble, lisez notre article sur le moment où un CDN vaut vraiment la peine.

WordPress : URL du site, extensions et wp-config.php

WordPress redirige les visiteurs vers les valeurs « Adresse web de WordPress (URL) » et « Adresse web du site (URL) », stockées sous siteurl et home dans wp_options. Si elles indiquent http://example.com alors que le serveur force HTTPS, ou www.example.com alors que le panneau retire www, vous obtenez une boucle. Vérifiez-les et corrigez-les avec WP-CLI :

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

Pas d’accès à l’administration ni à SSH ? Définissez l’URL dans wp-config.php, au-dessus de /* That's all, stop editing! */. Ces constantes remplacent les valeurs de la base de données :

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

Derrière votre propre reverse proxy ou répartiteur de charge, PHP ne voit que du HTTP, et WordPress avec FORCE_SSL_ADMIN ou une extension SSL redirige en boucle. La documentation WordPress conseille de prendre en compte X-Forwarded-Proto ; ajoutez ce code au-dessus de require_once ABSPATH . 'wp-settings.php'; :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Avec Cloudflare, passer en Full (strict) reste la solution la plus propre. Les autres suspects habituels sont les extensions : extensions SSL (par exemple Really Simple Security), gestionnaires de redirections, extensions multilingues, caches de page et extensions de sécurité qui déplacent la page de connexion. Désactivez-les toutes, testez, puis réactivez-les une par une :

wp plugin deactivate --all
# no SSH: rename wp-content/plugins to plugins-off in the file manager
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

Sans SSH, renommez le dossier wp-content/plugins en plugins-off dans le gestionnaire de fichiers. La dernière commande affiche un aperçu du remplacement des anciennes URL en http après une migration vers HTTPS ; retirez --dry-run pour l’appliquer. Une boucle sur la barre oblique finale (/page/ et /page) signifie qu’une règle du serveur contredit la structure des permaliens : n’en gardez qu’une.

Règles serveur : .htaccess, Nginx et panneau de contrôle

Apache .htaccess

L’erreur classique est une règle sans condition qui redirige même les requêtes déjà en HTTPS. Cette version vérifie le protocole et l’hôte, et traite http et www en un seul saut (cible sans www). Placez-la avant # BEGIN WordPress :

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

Si Apache se trouve derrière un proxy qui termine le HTTPS, la variable HTTPS vaut toujours off. Ne redirigez alors que les requêtes arrivées en HTTPS ni directement, ni via le proxy :

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx

La redirection HTTPS ne doit figurer que dans le bloc server qui écoute le port 80. Une boucle apparaît quand return 301 se retrouve dans un bloc listen 443 ou dans un bloc commun qui écoute les deux ports :

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    root /var/www/example.com;
    # rest of the site config
}

Pour retrouver les redirections existantes, puis vérifier et recharger la configuration après une modification :

sudo grep -RnE "return 30[1278]|rewrite .* (permanent|redirect)" /etc/nginx/
sudo nginx -t && sudo systemctl reload nginx

Derrière Cloudflare Flexible ou un répartiteur de charge, if ($scheme = http) est toujours vrai. Vérifiez plutôt $http_x_forwarded_proto ou, mieux encore, passez Cloudflare en Full (strict).

Panneau de contrôle

• La redirection HTTPS automatique écrit en général return 301 https://$host$request_uri; uniquement dans le bloc HTTP : à elle seule, cette option ne peut pas créer de boucle. La boucle apparaît en combinaison avec Cloudflare Flexible.
• La redirection de domaine force la version avec ou sans www. Elle doit correspondre à l’URL WordPress.
• L’option HSTS envoie souvent max-age=31536000 : les navigateurs retiennent pendant un an que le site n’est accessible qu’en HTTPS. Activez-la une fois HTTPS stable.

Éviter les boucles et protéger le SEO

• Une règle par tâche. Définissez HTTPS et le choix avec ou sans www à un seul endroit ; WordPress doit simplement s’y conformer.
• Un saut, pas une chaîne. http://www.example.com doit mener directement à https://example.com. Google suit au maximum 10 sauts, et chaque saut supplémentaire ajoute de la latence.
• Tester en 302, déployer en 301. Les navigateurs mettent les 301 en cache : une mauvaise règle permanente survit à la correction.
• Activer HSTS en dernier, quand HTTPS fonctionne sur tous les noms d’hôte utilisés.
• Préparer les migrations. Établissez le plan de redirections avant le déménagement, voir nos conseils pour une migration d’hébergement sans pertes.

FAQ

Pourquoi l’erreur n’apparaît-elle que dans un seul navigateur ?

En général à cause des cookies, d’une 301 en cache ou d’une politique HSTS enregistrée. Si le site fonctionne en navigation privée, supprimez ses données. Dans Chrome, vous pouvez effacer une entrée HSTS sur chrome://net-internals/#hsts, rubrique Delete domain security policies.

Pourquoi l’erreur est-elle apparue juste après l’activation de Cloudflare ?

Presque toujours à cause du mode Flexible : Cloudflare dialogue avec l’origine en HTTP et l’origine renvoie les visiteurs vers HTTPS. Installez un certificat sur le serveur et sélectionnez Full (strict).

Comment accéder à wp-admin si la boucle le touche aussi ?

Passez par le gestionnaire de fichiers du panneau ou par FTP : définissez WP_HOME et WP_SITEURL dans wp-config.php et renommez wp-content/plugins. Connectez-vous, corrigez les URL dans Réglages → Général, puis restaurez le dossier des extensions.

ERR_TOO_MANY_REDIRECTS nuit-elle au SEO ?

Googlebot ne peut pas récupérer la page, la Search Console signale donc une erreur de redirection. Une courte panne est sans conséquence ; une boucle qui dure des semaines peut faire sortir des pages de l’index.

La redirection HTTPS doit-elle être en 301 ou en 302 ?

Utilisez une 301 (ou une 308) pour un déplacement définitif. Utilisez une 302 pendant les tests, car les navigateurs ne la gardent pas longtemps en cache.

Conclusion

ERR_TOO_MANY_REDIRECTS signifie toujours que deux règles se contredisent. Suivez la chaîne avec curl, identifiez qui redirige (Cloudflare, le serveur ou WordPress) et gardez exactement une règle pour HTTPS et une pour www. La plupart des cas se règlent en passant Cloudflare en Full (strict) ou en corrigeant l’URL de WordPress. Avec les offres d’hébergement mutualisé RichHost, Let’s Encrypt gratuit et HTTPS forcé s’activent dans notre propre panneau de contrôle avec assistant IA, si bien que Cloudflare Full (strict) fonctionne sans configuration supplémentaire.