ERR_TOO_MANY_REDIRECTS: cosa causa un loop di redirect e come risolverlo

Cosa significa ERR_TOO_MANY_REDIRECTS

Un redirect dice al browser "la pagina che vuoi è altrove, vai lì invece." Un singolo redirect, o anche due o tre in sequenza, è normale: un dominio nudo che inoltra a www, o un vecchio URL che inoltra al suo sostituto. Un loop avviene quando un URL reindirizza a un secondo URL che reindirizza indietro al primo, o a se stesso. Dato che il browser non raggiunge mai una pagina che restituisce effettivamente contenuto, interrompe la catena e mostra l'errore invece di restare bloccato per sempre.

Come appare l'errore

Chrome ed Edge mostrano "This page isn't working - redirected you too many times" con il codice di errore ERR_TOO_MANY_REDIRECTS. Firefox mostra "The page isn't redirecting properly." Safari dice "Safari can't open the page because too many redirects occurred."

curl con il flag -L segue i redirect nello stesso modo di un browser, e stampare ogni salto mostra esattamente dove il loop si ripete:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Quel pattern, http verso https e di nuovo indietro verso http, è la forma più comune in assoluto che questo errore assume. curl si ferma al proprio limite predefinito (50 redirect) invece di seguirlo per sempre, e le righe location ripetute rendono il loop evidente senza bisogno di aprire affatto un browser.

Cosa causa un loop di redirect

• Un mismatch HTTP-verso-HTTPS tra un proxy o una CDN e l'origine. Questo è il caso classico. Se la modalità SSL/TLS di Cloudflare è impostata su Flexible, Cloudflare termina il TLS all'edge e si connette all'origine via HTTP semplice. Se il server di origine ha anche una regola che reindirizza ogni richiesta HTTP verso HTTPS (un'impostazione di sicurezza predefinita comune), l'origine rimanda il browser verso HTTPS, Cloudflare declassa di nuovo verso HTTP al salto successivo, e le due impostazioni si scontrano per sempre.
• Regole www e non-www che puntano l'una all'altra. Una regola reindirizza il dominio nudo verso www, e una regola separata, spesso aggiunta in seguito da un amministratore o plugin diverso, reindirizza www di nuovo verso il dominio nudo.
• Un mismatch di siteurl o home di WordPress. Se l'URL configurato del sito nel database non corrisponde all'URL che i visitatori usano effettivamente (un URL di staging rimasto, un mismatch di schema dopo aver aggiunto SSL), WordPress continua a reindirizzare verso il valore configurato.
• Cookie che il server si aspetta ma non riceve mai, o un redirect di login che fallisce silenziosamente. Una pagina che reindirizza i visitatori non autenticati verso un passaggio di login, che poi reindirizza indietro verso la stessa pagina perché il cookie di sessione non è mai stato impostato (spesso bloccato dalle regole sui cookie di terze parti di un browser o da un attributo Secure/SameSite mancante), va in loop all'infinito.
• Regole di barra finale o prefisso di lingua in conflitto. Una regola aggiunge una barra finale, un'altra la rimuove; una regola aggiunge un prefisso di lingua basato sulla locale del browser, un'altra lo rimuove per gli URL canonici, e le due si annullano a vicenda.
• Un livello di cache che serve un redirect obsoleto. Una CDN o un reverse proxy hanno messo in cache un vecchio 301 che puntava a un URL che, da allora cambiato, reindirizza indietro verso l'originale.

Come capire di chi è la colpa

Se il loop avviene per ogni visitatore su ogni rete, è un problema di configurazione del server o della CDN, non qualcosa di locale. Se avviene solo per te, cancella prima i cookie per il sito dato che un cookie di sessione difettoso o scaduto causa una gran parte dei loop a singolo visitatore. Eseguire un controllo HTTP da più postazioni risolve la questione in una sola richiesta: se la stessa catena di redirect (o lo stesso fallimento) compare da ogni postazione, la correzione è dal lato server.

Come correggere ERR_TOO_MANY_REDIRECTS

Se sei un visitatore

1. Cancella i cookie per il sito. In Chrome, clicca sull'icona del lucchetto o delle impostazioni accanto alla barra degli indirizzi, apri le impostazioni del sito, e cancella cookie e dati del sito solo per quel dominio.
2. Prova una finestra in incognito o privata. Questo esclude un'estensione del browser o un cookie memorizzato come causa senza toccare il tuo profilo normale.
3. Prova una rete diversa, come i dati mobili invece del Wi-Fi. Alcuni proxy aziendali o a livello di ISP riscrivono le richieste in modi che creano un loop solo su quella rete.
4. Cancella la cache del browser nel caso in cui una risposta di redirect stessa fosse stata messa in cache da prima che il sito venisse corretto.

Se gestisci il sito

1. Controlla la modalità SSL della tua CDN contro la regola di redirect della tua origine. In Cloudflare, apri SSL/TLS e imposta la modalità su Full o Full (strict), non Flexible, ogni volta che l'origine reindirizza HTTP verso HTTPS. Full permette comunque all'origine di usare un certificato autofirmato; Full (strict) ne richiede uno valido.
2. Fidati dell'header del protocollo inoltrato invece di reindirizzare ciecamente. Quando un proxy sta davanti alla tua app, l'origine deve reindirizzare in base a X-Forwarded-Proto, non alla connessione grezza, che appare sempre come HTTP da dietro il proxy. Su nginx:

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   e assicurati che la CDN o il load balancer stiano effettivamente impostando quell'header su ogni richiesta.
3. Controlla le tue regole di redirect in ordine, incluso .htaccess, i blocchi server di nginx, il middleware a livello applicativo, e qualunque page rule della CDN, per due regole che puntano l'una all'altra. Un pattern comune di Apache che va in loop dietro un proxy:

   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   fallisce nello stesso modo del caso nginx sopra, dato che %{HTTPS} legge la connessione che il proxy fa, non quella che il visitatore ha fatto; controlla invece %{HTTP:X-Forwarded-Proto}.
4. Correggi l'URL del sito WordPress se si applica: in wp-admin > Settings > General, conferma che sia il WordPress Address sia il Site Address corrispondano all'URL che i visitatori usano effettivamente, protocollo incluso. Se il pannello admin stesso è inaccessibile a causa del loop, imposta WP_HOME e WP_SITEURL direttamente in wp-config.php.
5. Scegli una forma canonica unica e reindirizza tutto il resto verso di essa una sola volta, non in catena: www o non-www, barra finale o no, una regola per decisione invece di più regole sovrapposte nel tempo da strumenti diversi.
6. Svuota la cache della CDN dopo aver corretto la regola, dato che un 301 o 302 in cache continua a inviare la vecchia risposta finché non scade o viene svuotata.

Errori correlati

• I codici di stato redirect 3xx spiega cosa significano ciascuno 301, 302, 303, 307 e 308.
• 301 contro 302 tratta quando un redirect dovrebbe essere permanente rispetto a temporaneo, il che conta per i motori di ricerca e la cache, non solo per i loop.

Come prevenire ERR_TOO_MANY_REDIRECTS

Un loop di redirect è quasi sempre introdotto da un cambio di configurazione: una nuova CDN, un nuovo certificato SSL, un aggiornamento di plugin, o una migrazione che ha toccato l'URL del sito. Un controllo HTTP che osserva il codice di risposta e segue i redirect secondo una pianificazione coglie un loop nel momento in cui compare, da oltre 300 punti di controllo in 158 città, invece di aspettare un ticket di supporto. HostTracker monitora siti web dal 2004 e può avvisare via email, SMS, chiamata vocale, Slack, Telegram e altro nel momento in cui un controllo inizia a fallire.

Domande frequenti

Quanti redirect permette un browser prima di rinunciare?

Chrome e i browser basati su Chromium si fermano intorno a 20. Il limite predefinito di curl con -L è 50. Il numero esatto varia per client, ma tutti alla fine si fermeranno invece di seguire un loop per sempre.

Perché il loop avviene solo subito dopo essere passato a Cloudflare (o un'altra CDN)?

Quasi sempre la modalità SSL/TLS. La modalità Flexible parla HTTP semplice con l'origine; se l'origine insiste su HTTPS, le due parti si reindirizzano a vicenda all'infinito. Passare a Full o Full (strict) di solito lo risolve immediatamente.

Un'estensione del browser può causare questo?

Sì, in particolare estensioni che forzano HTTPS, riscrivono le richieste, o gestiscono i cookie. Testare in una finestra in incognito con le estensioni disattivate esclude questo rapidamente.

Questo colpisce la SEO?

Sì. I crawler dei motori di ricerca rinunciano su un loop di redirect nello stesso modo di un browser, e un URL in loop non verrà indicizzato o uscirà dall'indice se prima funzionava.

Vedo l'errore solo su una pagina specifica, non su tutto il sito. Cosa c'è di diverso?

Controlla una regola specifica per pagina: una pagina che richiede login, un vecchio redirect in cache per quel singolo URL, o un mismatch di barra finale che esiste solo su quella rotta. Confronta la catena di redirect esatta per quell'URL contro una pagina funzionante con curl -sIL.

Un singolo redirect (come non-www verso www) è qualcosa da correggere?

No, un redirect da solo è normale e atteso. Solo una catena che si ripete e non raggiunge mai una risposta 200 finale è il problema che descrive questo errore.