Errore 'ERR_TOO_MANY_REDIRECTS' WordPress

L’errore ERR_TOO_MANY_REDIRECTS (o 'redirect loop') impedisce l’accesso al sito: il browser rileva un ciclo infinito di redirect e blocca la navigazione. Su WordPress capita spesso dopo cambio URL, SSL o configurazioni multisito. Vediamo come diagnosticare e rompere il loop.

Cause comuni

1) siteurl/home in wp_options diversi dall’URL reale del browser, 2) plugin SSL che forza HTTPS mentre il reverse proxy invia HTTP, 3) plugin SEO che redirige www→non-www mentre il server fa l’opposto, 4) htaccess con regola RewriteRule mal configurata, 5) certificato SSL non valido che fa redirigere a una pagina di errore in loop, 6) plugin di manutenzione che redirige a pagina in maintenance ma poi redirige di nuovo.

Diagnosi con WP Error Monitor

L’agent traccia le redirect chain registrandosi sul filter wp_redirect. Quando rileva più di 5 redirect in 10 secondi sullo stesso sito, genera evento con tutta la catena: source URL → target URL per ogni hop. In dashboard vedi il loop visualizzato come grafo, che rende immediato capire dove si chiude il cerchio.

Rompere il loop

Procedura di emergenza: 1) accedi via SFTP a wp-config.php, 2) aggiungi define('WP_HOMÈ,'https://sito.it') e define('WP_SITEURL’,'https://sito.it') con l’URL corretto. Questo bypass le wp_options sovrascrivendole. 3) se persiste, rinomina .htaccess in .htaccess.bak, 4) disattiva plugin via 'wp plugin deactivate --all’ da SSH, 5) accedi e reinstalla un plugin alla volta.

Cloudflare e SSL mode

Cloudflare ha 4 modalità SSL: Off (no HTTPS), Flexible (browser-CF in HTTPS, CF-origin in HTTP, causa loop su WP che vuole HTTPS), Full (browser-CF-origin in HTTPS ma cert'origin non verificato), Full Strict (HTTPS dappertutto, cert'origin verificato). La modalità raccomandata è Full Strict con cert Let's Encrypt o cert'Origin Cloudflare. Flexible causa quasi sempre redirect loop con WordPress che ha siteurl in HTTPS.

Trusted proxy headers

Quando WordPress è dietro reverse proxy (Cloudflare, nginx, AWS ALB), il header HTTPS dell’utente arriva come X-Forwarded-Proto: https, mentre la request a PHP arriva in HTTP. Senza configurazione, WP pensa di essere in HTTP e redirige a HTTPS, creando loop. Soluzione: aggiungi in wp-config.php il controllo HTTP_X_FORWARDED_PROTO https con set HTTPS=on.

Debug catena con curl verbose

Per investigare redirect loop manualmente, usa curl con flag -I -L -v: 'curl -I -L -v https://sito.it/'. Output mostra ogni hop con status, location header, cookie set. Esempio loop: '301 -> https://sito.it/ -> 301 -> https://sito.it/' (stesso URL: infinito). Il flag -L max-redirs default 50 limita iterazioni. Output ti dice esattamente dove si chiude il cerchio. WP Error Monitor traccia automaticamente questo se snippet client side è attivo, ma curl manuale è utile per riproduzione controllata e share del log con dev team.

DNS e propagazione cache

A volte il loop è colpa di DNS in propagazione: il dominio risolve a IP vecchio (server con vecchia config) per alcuni utenti, IP nuovo per altri. Verifica con 'dig @1.1.1.1 sito.it' vs 'dig @8.8.8.8 sito.it': se rispondono IP diversi, propagazione in corso. Tempo tipico: 1-24h dipende da TTL DNS impostato. Strategia: prima di cambiare server, riduci TTL a 300s 48h prima del cambio, poi cambia IP, attendi 1h che cache si svuoti, alza TTL di nuovo. WP Error Monitor traccia 'origin_ip' negli eventi per identificare se hit arrivano a server giusto.

Test del fix in staging prima di prod

Prima di applicare fix per redirect loop in produzione, esegui sempre test in staging gemellato: imposta in wp-config.php di staging gli stessi WP_HOME/WP_SITEURL che vuoi mettere in prod, verifica accessibilità' homepage e admin, test login utente normale e admin, test wp-redirect su action tipiche (post add-to-cart, login). Solo dopo aver verificato staging applichi in prod. Tempo aggiuntivo: 10-15 minuti per test, che salva da rischio rollback panic. Se non hai staging gemellato, ti consigliamo di implementarlo prima di toccare config sensibili in prod.

Procedura passo-passo

1. Apri WP Error Monitor e filtra 'category = redirect_loop'.
2. Esamina la catena di redirect mostrata nel grafo.
3. Identifica il punto in cui il ciclo si chiude (URL A → B → A).
4. Aggiungi WP_HOME e WP_SITEURL in wp-config.php se siteurl/home sono incoerenti.
5. Verifica .htaccess: rinominalo temporaneamente per escludere riscritture rotte.
6. Disattiva via WP-CLI tutti i plugin: wp plugin deactivate --all.
7. Riattivali uno alla volta per individuare il colpevole.
8. Quando trovato, contatta autore plugin o sostituiscilo.
9. Configura Cloudflare SSL mode su Full Strict.
10. Aggiungi snippet X-Forwarded-Proto in wp-config.php.

Errori comuni e come risolverli

• Errore solo dietro Cloudflare: Imposta SSL/TLS mode 'Full (Strict)' su Cloudflare e installa certificato Origin.
• Loop tra www e non-www: Decidi una versione canonica e configurala sia in WP che in webserver.
• Loop solo su admin: Probabile plugin auth che forza redirect in admin: disattiva il plugin via SFTP rinominando la cartella.
• Loop solo per alcuni utenti: Cache CDN serve vecchia redirect: svuota cache Cloudflare.
• Loop dopo abilitazione 'Always Use HTTPS': Rimuovi anche redirect lato WP per evitare doppio redirect.

Domande frequenti

D: Posso bloccare i redirect via plugin?
R: Sì, con add_filter('wp_redirect', '__return_falsè) in mu-plugin di debug, ma rompe altre funzionalità.

D: Cloudflare causa spesso questo errore?
R: Sì, se il Page Rule 'Always Use HTTPS' è attivo mentre il server WordPress non sa di essere in HTTPS. Aggiungi snippet HTTP_X_FORWARDED_PROTO.

D: Quanti redirect è normale avere?
R: 1-2 è accettabile, 3+ indica configurazione subottimale.

D: Posso usare Flexible SSL con WordPress?
R: Sconsigliato: causa quasi sempre loop. Usa Full o Full Strict.

D: Come testare X-Forwarded-Proto?
R: curl con header X-Forwarded-Proto https e verifica response.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.