Loop di redirect: come trovare e risolvere ERR_TOO_MANY_REDIRECTS

Un loop di redirect è una catena di redirect HTTP che non atterra mai da nessuna parte: l'URL A manda il browser all'URL B, B lo rimanda ad A, e dopo circa venti salti il browser smette di provarci e stampa ERR_TOO_MANY_REDIRECTS. Non c'è nulla di rotto sulla pagina di destinazione. Due regole sono semplicemente in disaccordo su dove debba stare l'URL, e ciascuna continua ad annullare l'altra.

Un redirect che fa loop è uno dei pochi errori web che indica da sé la propria causa, purché tu guardi la cosa giusta. Non il browser, non la pagina di errore, e di certo non la cache: la catena di redirect. Ogni salto porta un header Location, e i due indirizzi che continuano a ripetersi sono le due regole che devi riconciliare. Questa guida percorre la diagnosi in un solo comando, le cause dietro quasi ogni ciclo di redirect che ho dovuto sbrogliare, e la soluzione che non crea silenziosamente un secondo loop da qualche altra parte. Se la famiglia dei redirect in sé non è chiara, i tipi di redirect URL è la mappa; questa è la versione da troubleshooting.

Cosa significa davvero ERR_TOO_MANY_REDIRECTS

I browser seguono i redirect per tuo conto, ma non all'infinito. Ogni client mantiene un budget di salti e abbandona la richiesta quando si esaurisce: Chrome si ferma a 20 e non ti permette di cambiarlo, Firefox spedisce lo stesso valore predefinito sotto network.http.redirection-limit, e curl ne permette 50 prima di lamentarsi. Lo standard lascia il numero aperto. RFC 9110 dice solo che un client dovrebbe rilevare e intervenire nei redirect ciclici, che è il modo educato dello standard per dire che ogni browser ha bisogno di un interruttore automatico.

Questa distinzione conta per la diagnosi, perché l'errore non dimostra affatto che ci sia un ciclo. Una catena di ventuno salti distinti senza ripetizioni fa scattare esattamente lo stesso messaggio di due URL che rimbalzano all'infinito. Vale la pena risolvere entrambi, ma solo uno dei due ha una coppia di indirizzi da riconciliare. Il riferimento di MDN sui redirect copre entrambe le forme, e la differenza pratica emerge nel momento in cui stampi la catena.

Un'altra cosa che la pagina di errore nasconde: un redirect permanente viene messo in cache dal browser. Se il loop era costruito con risposte 301, i visitatori continuano a fare loop localmente anche dopo che hai sistemato il server, finché quella voce di cache non scade o non la cancellano. Questo singolo fatto è il motivo per cui testo le modifiche ai redirect con un 302 e le promuovo a 301 solo una volta che la catena è corretta, un'abitudine di cui 301 vs 302 redirect fa il caso completo.

Traccia la catena di redirect con un solo comando

Salta il browser. La lettura più veloce di qualsiasi loop di redirect è il terminale, perché curl stampa ogni salto invece di comprimerli in un'unica pagina di errore:

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Ottieni una riga di stato e un header Location per ogni salto, in ordine. Leggila dall'alto verso il basso e emerge uno di tre schemi. Due URL che si alternano significa un ciclo vero e proprio, e la coppia indica entrambe le regole colpevoli. Una lunga sequenza di URL distinti significa una catena che qualcuno ha accumulato negli anni, con ogni salto legittimo di per sé. E una catena che si risolve bene nel terminale ma continua a fallire nel browser significa che il loop è guidato dai cookie, dato che curl non invia cookie per impostazione predefinita.

Quest'ultimo caso merita un controllo a parte, perché è quello che fa incolpare il DNS per un intero pomeriggio:

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Con un cookie jar collegato, un loop di login o di consenso si riproduce sulla riga di comando, dove puoi effettivamente vedere quale endpoint continua a impostare e poi rifiutare la sessione. Nel browser, la vista equivalente è il pannello Network con "Preserve log" attivo, che impedisce ai salti precedenti di essere cancellati quando la pagina naviga. Se preferisci non aprire affatto un terminale, il nostro link checker traccia la catena nel browser e stampa il codice di stato a ogni salto.

Le cause dietro quasi ogni ciclo di redirect

Una volta che vedi la catena, la causa di solito è una tra poche possibili. La coppia di URL che si ripete ti dice quale livello guardare: lo schema che oscilla avanti e indietro punta alla terminazione TLS, l'hostname che oscilla punta a una regola di host canonico, e un percorso che continua a guadagnare e perdere una slash punta all'ordine delle regole di rewrite.

regole https dietro un proxy che termina il TLS

Questo è il redirect infinito più comune sul web moderno, ed è apparso nel momento in cui i proxy hanno iniziato a terminare il TLS davanti alle origini. Il proxy accetta una richiesta HTTPS dal visitatore, poi recupera la tua origine via HTTP semplice. La tua origine vede una richiesta non sicura, fa quello che le hai detto di fare, e reindirizza a HTTPS. Il proxy serve quel redirect, viene richiesto di nuovo, recupera di nuovo l'origine via HTTP, e il giro ricomincia. Cloudflare documenta esattamente questo guasto sotto la sua modalità di crittografia flessibile, e ogni altro proxy ha la stessa trappola sotto un nome diverso.

Ci sono due soluzioni pulite. Passa il proxy a una modalità di crittografia full così che parli con la tua origine via TLS, che è la risposta corretta in quasi tutti i casi. Oppure, se il salto verso l'origine deve davvero restare in chiaro, fai in modo che la regola dell'origine legga l'header X-Forwarded-Proto invece della connessione grezza, così smette di reindirizzare richieste che erano già sicure sull'edge.

www e apex in disaccordo su quale host debba vincere

Una regola di host canonico va bene. Due di esse, scritte in momenti diversi da persone diverse, sono un loop. La versione classica ha una configurazione server che manda l'apex a www mentre la configurazione dell'applicazione rimanda www all'apex, ed entrambe sono certe di avere ragione. Lo vedrai immediatamente nella catena: example.com verso www.example.com verso example.com, all'infinito.

Scegli un host, imponilo esattamente in un solo posto, ed elimina l'altra regola invece di provare a farle andare d'accordo. Lo stesso vale per un rewrite di trailing slash o di minuscolo: quando due regole normalizzano lo stesso URL in direzioni opposte, ottieni un ciclo di redirect anche se ogni regola presa singolarmente è sensata.

l'impostazione URL del CMS o dell'app che non corrisponde più

La maggior parte delle applicazioni memorizza il proprio indirizzo canonico, e quel campo è una regola di redirect con un nome amichevole. Cambia il dominio, spostati su un nuovo ambiente, o ripristina uno snapshot del database da un altro host, e l'app inizia a reindirizzare ogni richiesta verso un indirizzo che reindirizza indietro. Poiché l'impostazione vive nel database invece che nella configurazione del web server, sopravvive all'audit di configurazione che hai appena fatto, ed è questo che la rende così fastidiosa da trovare.

La firma è una catena che lascia il tuo hostname attuale e non vi torna mai. Correggi l'indirizzo memorizzato con il dominio che stai effettivamente servendo, poi svuota qualsiasi cache dell'applicazione o della pagina che ha catturato quello sbagliato.

loop di cookie e sessione che colpiscono solo gli utenti loggati

Qui le regole sono innocenti ed è lo stato a essere il problema. Un gate reindirizza i visitatori non autenticati verso una pagina di login, la pagina di login rimanda indietro quelli autenticati, e un cookie di sessione che non può essere letto sul dominio di destinazione lascia entrambe le parti convinte che debba occuparsene l'altra. I banner di consenso causano la stessa forma quando il redirect che imposta il cookie di consenso viene esso stesso bloccato.

L'indizio è lo stesso della sezione precedente: una finestra privata pulita funziona, oppure curl senza cookie jar si risolve normalmente. Controlla il dominio del cookie e lo scope Path, i suoi attributi Secure e SameSite rispetto allo schema che stai effettivamente servendo, e se viene impostato sull'apex mentre viene letto su www.

I loop di redirect sono raramente misteriosi una volta che la catena è sullo schermo, ma divorano un pomeriggio intero quando tenti di indovinare invece di tracciare. Se preferisci possedere il livello di redirect piuttosto che discuterci, il piano gratuito di Elido ti dà link la cui destinazione è un singolo valore memorizzato che puoi ripuntare, con ogni salto registrato.

Risolvilo senza creare un secondo loop

La riparazione in sé è breve, e l'ordine conta più della sintassi. Cambia una regola, poi ritraccia. Cambiarne tre e ricaricare non ti dice nulla su quale contasse davvero, e ho visto un team perdere un'ora in questo modo su un loop causato da una regola che avevano già corretto al primo tentativo.

1. Rimuovi o inverti esattamente una delle due regole indicate dalla catena, così che una richiesta possa raggiungere un 200 in un solo salto.
2. Riesegui la traccia curl -sIL e conferma che la catena ora conta al massimo un redirect, senza hostname ripetuti.
3. Cancella la cache del browser, oppure testa in una finestra privata, perché qualsiasi 301 servito in precedenza è ancora in cache localmente e simulerà un fallimento che non esiste più.
4. Solo a quel punto promuovi i redirect temporanei a permanenti, una volta che la forma della catena si è stabilizzata.

Alla fine di quella lista ci sono due trappole. Una è HSTS: una volta che un host ha inviato un header Strict-Transport-Security, i browser aggiornano da soli ogni richiesta a HTTPS, quindi una regola dell'origine che forza anche lei HTTPS diventa ridondante e può trasformare una configurazione errata del proxy in un loop che non riesci a riprodurre senza cancellare la voce HSTS. L'altra è la cache davanti al loop. Una CDN che ha messo in cache un 301 continuerà volentieri a servirlo dopo che l'origine ha smesso di inviarlo, ed è per questo che una purge appartiene alla soluzione e non a dopo di essa. Vale la pena sfoltire nello stesso passaggio anche le catene lunghe che non fanno mai loop: ogni salto in più è un'altra occasione perché una query string vada persa, che è esattamente il modo in cui i parametri UTM spariscono in GA4, ed è parte del motivo per cui gli short link non devono per forza danneggiare la SEO finché restano profondi un solo salto.

Quando il loop è su uno short link

Gli short link aggiungono un altro punto in cui un ciclo può formarsi, e non è il redirect dello shortener. Uno short link è un singolo salto memorizzato: entra lo slug, esce la destinazione. Il loop appare quando la destinazione punta indietro, il che succede più spesso di quanto sembri. Qualcuno modifica un link di campagna facendolo puntare a una landing page, la landing page ha una vecchia regola che reindirizza all'URL breve perché quello era l'indirizzo di condivisione canonico il trimestre scorso, e ora i due rimbalzano tra loro. Entrambi i salti si comportano esattamente come configurati.

Altre due varianti si presentano nella stessa catena. Una è una coppia di short link che puntano l'uno all'altro dopo una modifica in blocco, di solito da un'importazione da foglio di calcolo dove la colonna destinazione conteneva URL brevi invece di quelli finali. L'altra è un dominio personalizzato che si risolve ancora verso un host che reindirizza di nuovo allo shortener, il che è un residuo del DNS piuttosto che un problema di link, e i domini personalizzati per gli short link copre come dovrebbero apparire i record. In tutti e tre i casi, la soluzione è impostare la destinazione sulla pagina finale invece che su un altro redirect, cosa che puoi fare senza toccare nulla di già stampato o pubblicato.

Poiché la destinazione è memorizzata invece che incorporata nell'URL, niente di tutto questo richiede una ristampa. Questo è l'intero argomento a favore dei link gestiti, e short link non funziona è la guida di triage più ampia quando il sintomo non è specificamente un loop.

Impedisci che il prossimo venga spedito

I loop di redirect sono un bug da configuration-drift, quindi le soluzioni durature sono quelle noiose. Tieni la decisione sull'host canonico in un unico posto e tratta qualsiasi seconda regola che tocca schema o hostname come un bug non appena la vedi. Traccia i nuovi redirect con curl -sIL prima di annunciarli, non dopo che qualcuno segnala una pagina bianca. Se i link contano per il fatturato, mettici sopra un controllo: una traccia programmata che fallisce quando la catena supera un salto intercetta il drift molto prima di un cliente, e il monitoraggio dei redirect dei link mostra come appare quando è collegato ad avvisi reali.

L'abitudine più ampia è trattare le destinazioni come dati che puoi controllare. La prevenzione del link rot copre la stessa disciplina per i link che smettono silenziosamente di risolversi, ed è comunque lo stesso controllo settimanale. Onestamente, la maggior parte dei loop che ho visto sono stati spediti da due persone competenti che hanno ciascuna risolto lo stesso problema in un livello diverso, a un mese di distanza. Scrivi la regola una volta sola e il loop smette di essere possibile.

Leggi la serie cornerstone

Questo articolo si inserisce nel cluster engineering. Per la forma del percorso di redirect in sé, portare il p95 sotto i 15ms per i redirect copre quanto costa un singolo salto ben educato, e i tipi di redirect URL copre quale codice di stato appartiene a dove prima che tu inizi ad accumulare regole.

Articoli correlati sul blog

• Tipi di redirect URL: 301, 302, 307, 308 e altro
• 301 vs 302 redirect: quale dovrebbero usare gli short link
• Short link non funziona? Diagnosticalo con un solo comando
• Short link con dominio personalizzato: DNS, TLS e l'edge
• Vulnerabilità open redirect e come prevenirle
• Monitoraggio degli short link con Sentry e Datadog