Il WordPress login loop si verifica quando le credenziali vengono accettate o sembrano accettate, ma il browser torna alla pagina di accesso senza aprire wp-admin. Nella maggior parte dei casi la sessione non viene conservata correttamente tramite cookie.
Questa guida approfondisce WordPress login loop con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Il problema può dipendere da home e siteurl incoerenti, HTTP e HTTPS, www e non-www, cache dell’area amministrativa, plugin di sicurezza o cookie con dominio errato.
Prima di cambiare la password bisogna verificare se WordPress segnala davvero credenziali non valide oppure se il redirect avviene dopo l’autenticazione.
Come riconoscere il problema
- Il login ricarica wp-login.php.
- Non appare un messaggio password errata.
- La finestra anonima funziona.
- Il problema nasce dopo migrazione o HTTPS.
- Un utente entra e un altro no.
Cause più frequenti
1. Cookie corrotti
La sessione locale contiene dati vecchi o duplicati. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. home e siteurl diversi
Protocollo o hostname non coincidono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Proxy HTTPS non riconosciuto
WordPress genera cookie o redirect per HTTP. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Cache di wp-login o wp-admin
Una pagina amministrativa viene servita dalla cache. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Plugin di sicurezza
Regole login, 2FA o cookie interferiscono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Database o sessione utente
Dati utente, ruoli o session token sono incoerenti. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Prova finestra anonima. Escludi cookie e cache locali. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla home e siteurl. Usa WP-CLI per leggere i valori. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Segui i redirect. Usa strumenti sviluppatore e controlla Location e Set-Cookie. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica HTTPS e proxy. Controlla Cloudflare SSL/TLS e intestazioni forwarded. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Escludi cache. wp-login.php e wp-admin non devono essere cacheati. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Disattiva plugin sospetto in modo reversibile. Rinomina la directory soltanto dopo backup o usa WP-CLI. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla error_log e ruoli. Cerca fatal error e metadati utente mancanti. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Elimina cookie del dominio. Ripeti l’accesso da una sessione nuova. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Allinea gli URL WordPress. Usa un solo protocollo e hostname canonico. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi HTTPS dietro proxy. Adotta una configurazione compatibile con la CDN. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Escludi l’amministrazione dalla cache. Pulisci page cache e CDN. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiorna o configura il plugin di sicurezza. Mantieni 2FA e protezioni operative. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Rigenera le sessioni. Disconnetti sessioni vecchie e reimposta password se necessario. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Verifica più utenti. Conferma se il problema è globale o legato a un account. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- wp-admin si apre dopo il login.
- Set-Cookie usa dominio e Secure corretti.
- Nessun redirect loop.
- La cache non memorizza pagine amministrative.
- 2FA e sicurezza continuano a funzionare.
Prevenzione
- Mantieni URL coerenti.
- Escludi wp-admin dalla cache.
- Testa migrazioni.
- Aggiorna plugin.
- Usa HTTPS end-to-end.
Errori da evitare
- Non modificare password ripetutamente senza diagnosi.
- Non usare Cloudflare Flexible con redirect incompatibili.
- Non disattivare sicurezza permanentemente.
- Non cancellare utenti dal database.
- Non condividere cookie o credenziali.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- URL di login
- orario
- utente senza password
- catena redirect
- modalità Cloudflare e valori home/siteurl
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su WordPress login loop
Cambiare password risolve il login loop?
Solo se le credenziali sono realmente errate; spesso il problema riguarda cookie o redirect.
Perché la finestra anonima funziona?
Parte senza i cookie e la cache della sessione normale.
La cache può coinvolgere wp-admin?
Sì, se configurata male. Login e amministrazione devono essere esclusi.
Cloudflare Flexible può causarlo?
Può creare incoerenze HTTP/HTTPS e redirect se l’origine forza HTTPS.
Quali valori devo controllare?
home, siteurl, URL finale, cookie e protocollo visto da WordPress.