ERR_TOO_MANY_REDIRECTS : corriger une boucle de redirection

TL;DRERR_TOO_MANY_REDIRECTS signifie que le site vous renvoie d'une adresse à l'autre sans jamais afficher de page : Chrome abandonne après 20 redirections. Côté visiteur, supprimez les cookies du site et testez en navigation privée. Côté propriétaire, la cause est presque toujours un HTTPS forcé deux fois (Cloudflare en mode Flexible plus une redirection serveur), des URL WordPress incohérentes ou des règles .htaccess ou nginx qui se contredisent.

Vous tapez l'adresse d'un site, la page semble charger, puis Chrome affiche « Cette page ne fonctionne pas » avec le code ERR_TOO_MANY_REDIRECTS. Firefox parle de « La page n'est pas redirigée correctement ». Dans les deux cas, le navigateur a été renvoyé d'une adresse à l'autre sans jamais atteindre une page finale. Ce guide vous donne d'abord les gestes simples côté visiteur, puis la méthode de diagnostic et les corrections côté propriétaire du site.

📌 Ce que signifie ERR_TOO_MANY_REDIRECTS#

Une redirection est une réponse HTTP de la famille 3xx (301, 302, 307, 308) accompagnée d'un en-tête Location qui indique au navigateur où aller. C'est un mécanisme normal : passer de http:// à https://, ou de example.com à www.example.com, se fait par redirection.

Le problème apparaît quand la destination renvoie à son tour vers l'adresse de départ, ou vers une autre adresse qui finit par revenir au point de départ. Le navigateur suit, encore et encore. Chrome fixe une limite de 20 redirections pour une même requête : au-delà, il abandonne et affiche l'erreur (code réseau interne -310). Le site n'est pas « en panne » au sens strict : le serveur répond, mais ses réponses se contredisent.

📌 Côté visiteur : les solutions simples#

Si vous n'êtes pas le propriétaire du site, vos marges de manœuvre sont limitées, mais une cause est réellement de votre côté : les cookies. Un cookie périmé ou contradictoire (session, langue, choix de version mobile) peut provoquer une boucle sur votre seul navigateur.

1. Supprimez les cookies du site concerné. Dans Chrome, cliquez sur l'icône à gauche de l'adresse, puis « Cookies et données des sites », et supprimez les données de ce domaine. Inutile d'effacer tous vos cookies.
2. Testez en navigation privée. Si la page s'ouvre en fenêtre privée, le problème vient de vos cookies ou d'une extension.
3. Désactivez temporairement vos extensions, en particulier celles qui forcent le HTTPS, bloquent des scripts ou modifient les en-têtes.
4. Videz le cache du navigateur. Une redirection 301 est mise en cache par le navigateur : une ancienne boucle corrigée depuis peut continuer à s'afficher chez vous.
5. Essayez un autre navigateur ou un autre appareil, par exemple votre téléphone en 4G. Si l'erreur persiste partout, le problème est côté serveur et seul le propriétaire du site peut le corriger.

📌 Côté propriétaire : diagnostiquer la boucle avec curl#

Avant de toucher à la configuration, il faut voir la chaîne exacte des redirections. Le navigateur la masque, curl la montre. La commande suivante suit les redirections (-L), n'affiche que les en-têtes (-I) et s'arrête au bout de 10 sauts :

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

Une boucle se repère tout de suite : la même ligne location revient, ou deux adresses alternent, et curl termine par curl: (47) Maximum (10) redirects followed. Un site sain affiche une ou deux redirections puis un HTTP/2 200.

Pour examiner un seul saut, sans suivre la redirection, utilisez le format de sortie de curl :

curl -sI -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://example.com/

Si votre site passe par Cloudflare ou un autre proxy, interrogez aussi directement le serveur d'origine en contournant le DNS public. Remplacez 203.0.113.10 par l'adresse IP de votre serveur :

curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/
curl -sI --resolve www.example.com:80:203.0.113.10 http://www.example.com/

Si l'origine répond 200 en HTTPS mais 301 vers HTTPS quand on l'appelle en HTTP, et que le proxy l'appelle en HTTP, vous tenez votre boucle. Enfin, regardez le corps de la réponse ou les en-têtes x-redirect-by : WordPress ajoute par exemple X-Redirect-By: WordPress quand c'est lui qui redirige, ce qui permet de distinguer une redirection applicative d'une redirection du serveur web.

📌 Les causes les plus fréquentes#

🌐 HTTPS forcé deux fois : Cloudflare « Flexible » + redirection serveur#

C'est la cause la plus courante après l'ajout d'un site sur Cloudflare. En mode de chiffrement « Flexible », Cloudflare reçoit le visiteur en HTTPS mais contacte votre serveur en HTTP. Votre serveur, configuré pour forcer le HTTPS, répond par une 301 vers https://. Cloudflare transmet cette réponse au visiteur, qui revient en HTTPS, et Cloudflare recontacte l'origine en HTTP. La documentation de Cloudflare décrit exactement ce scénario.

La correction durable : installer un certificat sur le serveur (Let's Encrypt ou certificat d'origine Cloudflare) et passer le mode SSL/TLS sur « Full (strict) ». Si vous ne pouvez pas installer de certificat tout de suite, retirez la redirection HTTPS du serveur et laissez Cloudflare la faire avec l'option « Always Use HTTPS ». Attention : cette option, combinée à une redirection inverse de HTTPS vers HTTP sur le serveur, produit elle aussi une boucle.

Le mode « Flexible » ne chiffre que la moitié du trajet : entre Cloudflare et votre serveur, le trafic circule en clair. Le passage en « Full (strict) » corrige la boucle et la sécurité en même temps. Pour installer le certificat côté serveur, voyez notre guide pour passer son site en HTTPS.

🌐 WordPress : siteurl et home mal renseignés#

WordPress stocke deux adresses : home (l'adresse du site) et siteurl (l'adresse des fichiers de WordPress). Si elles indiquent http:// alors que le serveur force https://, ou www alors que le serveur retire le www, WordPress et le serveur se contredisent. Avec WP-CLI, vérifiez et corrigez :

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

Sans accès en ligne de commande, vous pouvez forcer les deux valeurs dans wp-config.php, au-dessus de la ligne « That's all, stop editing! ». Pas de barre oblique finale :

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

Derrière un proxy ou un répartiteur de charge qui termine le HTTPS, WordPress peut aussi croire qu'il est servi en HTTP et rediriger sans fin, notamment vers /wp-admin. La documentation WordPress propose d'indiquer à PHP que la requête d'origine était en HTTPS, à placer dans wp-config.php :

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

Ne faites confiance à cet en-tête que si votre serveur n'est joignable que par le proxy. Pensez aussi aux extensions : une extension de redirection ou de « SSL » qui force le HTTPS en plus du serveur crée une redirection en double. Si l'administration est inaccessible, renommez le dossier de l'extension par FTP pour la désactiver. Si le site affiche ensuite une page blanche, notre guide erreur 500 WordPress prend le relais.

📌 Règles .htaccess ou nginx contradictoires#

Une règle ajoute le www, une autre plus bas le retire. Une règle force le HTTPS dans le .htaccess alors que le virtual host le fait déjà avec une condition différente. Chaque règle prise seule est correcte, ensemble elles tournent en rond. Le bon réflexe : une seule adresse canonique (par exemple https://www.example.com), et une seule redirection qui y mène directement depuis toutes les autres variantes.

📌 Cookies, sessions et HSTS#

Certaines boucles n'apparaissent qu'une fois connecté : la page de connexion redirige vers le compte, qui ne trouve pas la session et renvoie vers la connexion. La cause est souvent un cookie posé pour example.com alors que le site est servi sur www.example.com, ou un cookie marqué Secure sur une page servie en HTTP. Testez avec et sans cookie dans curl (-H 'Cookie: …') pour le confirmer.

Autre piège : si votre site envoie l'en-tête Strict-Transport-Security (HSTS), le navigateur passe lui-même en HTTPS avant toute requête. Une redirection serveur de HTTPS vers HTTP crée alors une boucle impossible à contourner côté visiteur, tant que la durée HSTS n'est pas écoulée.

📌 Des configurations nginx et Apache correctes#

Voici une configuration nginx qui envoie toutes les variantes vers https://www.example.com en une seule redirection, sans jamais rediriger le bloc final :

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www/example/public;
    # aucune redirection ici : c'est l'adresse finale
}

Testez avant de recharger : nginx -t && systemctl reload nginx.

Sous Apache, l'équivalent dans un .htaccess à la racine du site tient en quatre lignes. La condition [OR] réunit les deux cas (HTTP, ou nom d'hôte différent) dans une seule redirection :

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

Derrière un proxy qui contacte Apache en HTTP, %{HTTPS} vaut toujours off et cette règle boucle. Dans ce cas, testez l'en-tête transmis par le proxy à la place de la première condition : RewriteCond %{HTTP:X-Forwarded-Proto} !https [OR]. Vérifiez la syntaxe avec apache2ctl configtest si vous modifiez le virtual host.

⚡ Après la correction : vérifier et purger les caches#

1. Relancez curl -sSIL sur chaque variante : http://example.com, http://www.example.com, https://example.com et https://www.example.com. Chacune doit aboutir à un 200 en une redirection au plus.
2. Purgez le cache de Cloudflare ou de votre CDN, puis celui de votre extension de cache WordPress ou PrestaShop.
3. Testez dans une fenêtre privée : votre propre navigateur garde en mémoire les anciennes redirections 301.
4. Surveillez la Search Console dans les jours qui suivent : les pages en erreur de redirection doivent disparaître du rapport d'indexation.

Si l'erreur a cédé la place à une autre, notre page codes d'erreur HTTP regroupe les diagnostics, et notre article sur ERR_SSL_PROTOCOL_ERROR couvre les problèmes de certificat qui surgissent souvent juste après un passage en « Full (strict) ».

📌 Besoin d'aide ?#

Une boucle de redirection se corrige en quelques minutes quand on sait où regarder, mais elle met le site hors ligne pour tous les visiteurs tant qu'elle dure. Websource héberge un grand nombre de sites et accompagne ses clients dès la commande : configuration HTTPS, redirections www, réglages Cloudflare et migration (offerte en offres Premium et Advanced, sur devis en Standard). Découvrez nos offres d'hébergement web, ou décrivez-nous votre problème depuis notre formulaire de contact.

❓ Questions fréquentes#

📌 ERR_TOO_MANY_REDIRECTS vient-il de mon ordinateur ou du site ?#

Testez en navigation privée et sur un autre appareil en 4G. Si la page s'ouvre ailleurs, ce sont vos cookies ou une extension : supprimez les cookies du site. Si l'erreur apparaît partout, la configuration du site est en cause.

⚠️ Pourquoi l'erreur est-elle apparue juste après l'activation de Cloudflare ?#

Le mode SSL Flexible fait contacter votre serveur en HTTP. Si votre serveur force le HTTPS, il renvoie une 301 à chaque requête et la boucle démarre. Installez un certificat sur le serveur et passez en Full (strict).

🌐 Comment corriger la boucle si je n'ai plus accès à l'administration WordPress ?#

Définissez WP_HOME et WP_SITEURL dans wp-config.php avec l'adresse exacte du site, ou corrigez les options home et siteurl avec WP-CLI. Si une extension de redirection est en cause, renommez son dossier par FTP pour la désactiver.

⚠️ J'ai corrigé la configuration mais l'erreur s'affiche encore, pourquoi ?#

Les redirections 301 sont mises en cache par le navigateur et souvent par le CDN. Purgez le cache de Cloudflare et de vos extensions, puis testez en navigation privée ou avec curl, qui n'utilise aucun cache.

📌 Combien de redirections un site peut-il enchaîner sans risque ?#

Visez une seule redirection entre une variante d'adresse et la page finale. Chrome tolère jusqu'à 20 sauts et Google suit jusqu'à 10 redirections, mais chaque saut ajoute du temps de chargement.

Article publié le 11/11/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.