ERR_TOO_MANY_REDIRECTS: cos'è il redirect loop e come risolverlo su WordPress e Cloudflare

Chi gestisce un sito riceve prima o poi questa schermata: ERR_TOO_MANY_REDIRECTS (o "La pagina non viene reindirizzata correttamente"). Il sito non è down, non c'è un attacco in corso: due sistemi diversi si stanno rimbalzando la stessa richiesta perché entrambi vogliono decidere se la pagina va servita in HTTP o in HTTPS. Questa guida spiega come riprodurre l'errore da terminale e come trovare il colpevole, passo per passo, su WordPress e su Cloudflare.

Cos'è un redirect loop

Un redirect è una risposta del server con stato 301 o 302 e un'intestazione Location che dice al browser "vai altrove". Un loop si forma quando due componenti della catena si rimandano la richiesta a vicenda: A dice "vai su HTTPS", B dice "vai su HTTP", A rimanda di nuovo a HTTPS, e così all'infinito finché il browser si arrende e mostra l'errore.

Riprodurre l'errore con curl

Prima regola: non si indovina, si misura. Da terminale:

curl -IL https://tuosito.it

-I chiede solo le intestazioni (niente corpo della pagina), -L segue ogni redirect. L'output mostra un blocco di intestazioni per ogni salto: si legge la riga di stato (HTTP/1.1 301 Moved Permanently) e la riga Location subito sotto. Se il sito è davvero in loop, curl continuerà a seguire redirect fino al limite di default (50) e si fermerà da solo, oppure si può forzare un limite più basso per vedere subito lo schema che si ripete:

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

Per isolare solo le righe utili su una catena lunga:

curl -sIL https://tuosito.it | grep -iE '^(HTTP|location)'

Se la sequenza alterna http:// e https:// sullo stesso dominio, il problema è quasi certamente un conflitto HTTP/HTTPS tra due componenti della catena (proxy, pannello, applicazione).

Le cause più comuni

Causa	Dove si manifesta	Sintomo tipico
Cloudflare in modalità Flexible + sito che forza HTTPS	Siti dietro Cloudflare	Loop subito dopo aver attivato il proxy o un certificato
Cloudflare Full/Strict + origine che forza ancora HTTP	Siti dietro Cloudflare dopo un cambio di modalità	Loop dopo aver "sistemato" la modalità SSL
Regole .htaccess o plugin di redirect che si sommano	WordPress su Apache	Loop dopo aver installato un plugin SEO o SSL
WordPress Address diverso da Site Address	WordPress	Loop dopo un trasferimento di dominio o una migrazione
Cookie di sessione corrotti nel browser	Lato client	Il loop sparisce in una finestra anonima o su un altro browser

Controlli su WordPress

1. Impostazioni > Generali: WordPress Address (URL) e Site Address (URL) devono avere lo stesso schema e lo stesso host, entrambi https:// e entrambi senza www oppure entrambi con www. Un disallineamento qui genera un redirect canonico che si scontra con qualsiasi altra regola.
2. Plugin di redirect o SSL: i plugin che forzano HTTPS, gestiscono redirect SEO o puliscono contenuti misti sono tra le cause più comuni di loop quando si sommano a una regola già presente sul server o sul proxy. Si disattivano uno alla volta da Plugin > Plugin installati per isolare quello responsabile.
3. File .htaccess: se si è bloccati fuori dall'amministrazione, si accede via FTP o file manager dell'hosting, si rinomina .htaccess (per esempio in .htaccess-vecchio) e si ricarica il sito. Se il loop sparisce, il file conteneva una regola in conflitto; WordPress ne ricrea uno standard al primo salvataggio dei permalink da Impostazioni > Permalink.
4. Se nessuno dei tre punti risolve e si cancellano i cookie del dominio (o si prova in una finestra anonima) il sito torna accessibile, il problema è un cookie di sessione corrotto lato browser, non una configurazione del server.

Controlli su Cloudflare

La documentazione ufficiale Cloudflare elenca tre famiglie di cause: la modalità di cifratura SSL/TLS, le impostazioni della pagina Edge Certificates e le regole di redirect in conflitto.

Il caso più frequente: se il dominio ha la modalità di cifratura impostata su Flexible, Cloudflare invia richieste non cifrate al server di origine via HTTP, e si generano loop di redirect se il server di origine reindirizza automaticamente tutte le richieste HTTP verso HTTPS. Si corregge da SSL/TLS → Overview: si cambia la modalità da Flexible a Full o Full (Strict) (quest'ultima richiede un certificato valido installato sull'origine).

Esiste anche il caso opposto, meno noto: se la modalità è già Full o Full (Strict) ma sull'origine è rimasta attiva una vecchia regola che reindirizza da HTTPS a HTTP, il loop si forma comunque, stavolta nella direzione contraria. In questo caso la correzione non è sulla modalità Cloudflare ma sull'origine: va tolto il redirect residuo HTTPS→HTTP dal server.

Da controllare anche in SSL/TLS → Edge Certificates: il toggle Always Use HTTPS genera lo stesso tipo di loop se l'origine a sua volta reindirizza verso HTTP, e la stessa cosa vale per HSTS, che in quel caso va disattivato oppure richiede che la modalità di cifratura sia almeno Flexible. Infine, chi ha impostato Redirect Rules o Page Rules sul dominio deve verificare che non si sovrappongano a quelle già presenti sull'origine: è la causa più comune quando il loop coinvolge www e non-www o sottodomini diversi.

Per chi vuole forzare HTTPS senza toccare il server di origine, Cloudflare offre un meccanismo lato edge (Enforce HTTPS) che evita di dover gestire un redirect lato server, eliminando una delle due metà del conflitto alla radice.