ERR_TOO_MANY_REDIRECTS: come si spezza un ciclo di reindirizzamenti

Il browser mostra "ERR_TOO_MANY_REDIRECTS" (su Chrome) o "la pagina non reindirizza in modo corretto" (su Firefox): il sito chiede di andare a un altro indirizzo, quell'indirizzo rimanda indietro, e il ciclo non si chiude mai. In pratica due regole di reindirizzamento si contraddicono a vicenda.

La verifica più rapida

Prima di guardare qualsiasi file di configurazione, guarda la catena vera. Da un terminale Linux o macOS:

curl -IL --max-redirs 10 https://tuodominio.it

-I chiede solo gli header, -L segue i redirect, --max-redirs 10 ferma il comando dopo 10 salti invece di girare all'infinito. Se il sito è in loop, vedrai la stessa coppia di URL alternarsi (es. http://tuodominio.it → https://tuodominio.it → http://tuodominio.it...) finché curl non si ferma da solo con un errore di troppi redirect. La riga che conta è quella con Location:, che ti dice dove sta mandando il browser a ogni passo.

Le quattro cause, in ordine di frequenza

1. Regola HTTPS doppia: server e applicazione in conflitto

Capita quando sia il webserver sia il CMS (WordPress, un .htaccess, una regola nginx) forzano il passaggio a HTTPS, ma uno dei due parte da una condizione sbagliata (es. non riconosce l'header che indica che la connessione è già cifrata dietro un proxy).

Come si capisce se è la tua: nella catena di curl -IL l'URL cambia solo protocollo (http↔https), mai dominio.

Come si risolve, su Ubuntu 24.04 con Nginx e PHP-FPM: controlla se c'è una regola di redirect sia nel blocco server Nginx (return 301 https://...) sia nel codice applicativo (su WordPress spesso in wp-config.php con $_SERVER['HTTPS']). Tienine una sola, preferibilmente a livello server.

Su cPanel: verifica in "Domini" se "Forza HTTPS" è attivo insieme a un redirect scritto a mano nel file .htaccess del dominio: sono le due regole che litigano.

Su Plesk: il redirect automatico si attiva da Siti Web e Domini → impostazioni di Hosting → "Reindirizzamento permanente SEO-mantenuto (301)"; se c'è anche una regola manuale in .htaccess o nel file nginx aggiuntivo del dominio, va tolta una delle due.

2. www e non-www configurati in due posti diversi

Un punto redirige www→non-www, un altro (CDN, DNS, pannello) redirige il contrario.

Come si capisce se è la tua: nella catena compare un cambio di host (www.tuodominio.it ↔ tuodominio.it) oltre o al posto del cambio di protocollo.

Come si risolve: scegli una sola versione canonica e verifica che la regola sia scritta in un solo punto della catena (DNS/CDN oppure webserver, mai entrambi). Su Nginx controlla che non ci siano due blocchi server che si rimandano a vicenda; su Plesk/cPanel controlla sia le impostazioni di hosting sia eventuali regole aggiunte a mano nei file di configurazione aggiuntivi.

3. CDN in modalità "flessibile" davanti a un server che reindirizza

Se la CDN parla in HTTP col tuo server mentre promette HTTPS al visitatore (modalità spesso chiamata "flexible"), e il tuo server a sua volta forza l'HTTPS su ogni richiesta che non riconosce come già cifrata, il server rimanda alla CDN che rimanda al server: loop infinito.

Come si capisce se è la tua: togli temporaneamente la CDN (punta il DNS dritto all'IP del server) e rifai curl -IL. Se il loop sparisce, la causa è lì.

Come si risolve: nel pannello della CDN cambia la modalità di cifratura verso "completa" o "full (strict)", così la CDN parla HTTPS anche col tuo server, invece di "flessibile". Se il problema persiste anche con la CDN disattivata, la causa è nel server, non nel fornitore.

4. Indirizzo del sito sbagliato nelle impostazioni dell'applicazione

Su WordPress, Nextcloud e altri CMS l'URL del sito è salvato anche a livello di applicazione (database o file di configurazione), non solo nel webserver. Se quell'URL non combacia col dominio reale (es. resta http:// dopo un passaggio a HTTPS, o punta ancora al vecchio dominio dopo una migrazione), l'applicazione reindirizza da sola verso l'indirizzo sbagliato, in conflitto con le regole del server.

Come si capisce se è la tua: il loop appare solo su certe pagine (es. l'area di amministrazione) e non su una pagina HTML statica messa nella stessa cartella.

Come si risolve: su WordPress correggi siteurl e home nella tabella wp_options (o nel file wp-config.php se li hai forzati lì) in modo che corrispondano esattamente al dominio e al protocollo giusti.

Dove guardare se i comandi non bastano

Se vuoi vedere cosa succede lato server mentre fai la richiesta, su Ubuntu 24.04 con Nginx il log d'errore è, per impostazione predefinita, in /var/log/nginx/error.log, secondo la documentazione ufficiale di Nginx: su RHEL, Debian e Ubuntu il percorso di default è /var/log/nginx/error.log. Seguilo in tempo reale con:

sudo tail -f /var/log/nginx/error.log

Su cPanel i log sono consultabili da "Metrics" → "Errors" nel pannello; su Plesk da Siti Web e Domini → Registri → error_log, come descritto nella documentazione ufficiale di Plesk.

Come verificare che è risolto

Rilancia curl -IL --max-redirs 10 https://tuodominio.it: la catena deve terminare con un solo HTTP/1.1 200 (o HTTP/2 200), senza tornare mai su un URL già visto. Controlla anche la versione www e quella http, se il dominio le accetta entrambe: devono convergere tutte sullo stesso indirizzo finale.

Quando chiamare l'assistenza del fornitore

Se il loop sparisce solo disattivando la CDN ma non capisci perché, apri un ticket al fornitore della CDN allegando: l'output di curl -IL fatto passando dalla CDN, lo stesso comando fatto puntando l'IP del server (bypassando la CDN), e la modalità di cifratura attualmente impostata nel pannello. Senza questi tre elementi l'assistenza ti chiederà di ripeterli comunque, perdendo tempo che col sito giù non hai.