Login loop in WordPress Multisite: cookie, dominio e HTTPS da controllare
- Wordpress
- 4 settembre 2026
Indice dei contenuti
Le credenziali sono corrette, il login sembra riuscire, ma WordPress Multisite riporta nuovamente alla schermata di accesso oppure aggiunge reauth=1 all’URL. Reimpostare la password spesso non cambia nulla, perché il problema può riguardare il cookie di autenticazione e il rapporto fra dominio richiesto, URL memorizzati, HTTPS e configurazione della rete.
In un Multisite la diagnosi è più delicata rispetto a un’installazione singola: sito principale, sottositi, dominio mappato, proxy e certificati devono concordare su quale host e protocollo stiano gestendo la sessione.
Perché WordPress Multisite torna alla pagina di login
WordPress autentica l’utente attraverso cookie firmati. Il browser li invia soltanto quando dominio, percorso, protocollo e altre condizioni corrispondono. Se il cookie viene impostato per un host ma la richiesta successiva arriva su un altro, WordPress non trova una sessione valida e richiede nuovamente l’accesso.
Le cause possibili includono:
- dominio principale e dominio mappato non coerenti;
- differenza fra versione
wwwe senzawww; - redirect ripetuti fra HTTP e HTTPS;
- costanti cookie personalizzate non adatte alla rete;
- proxy che non comunica correttamente il protocollo originale;
- URL del sottosito errati;
- cache che conserva redirect o pagine di login;
- cookie vecchi nel browser dopo una migrazione.
Il loop è il sintomo comune, ma la correzione dipende dal punto esatto in cui host o protocollo cambiano.
Come controllare cookie e redirect del login
Gli strumenti di sviluppo del browser permettono di osservare la richiesta di login, la risposta Set-Cookie e i redirect successivi. Bisogna verificare quale dominio riceve il cookie, se è marcato Secure, quale path utilizza e verso quale URL viene inviato il browser.
La documentazione ufficiale sull’accesso WordPress descrive i cookie di autenticazione e segnala il domain mismatch fra le possibili cause dell’errore relativo ai cookie bloccati. Nel Multisite è importante non modificare una costante isolata senza comprendere l’intera topologia.
Una verifica ordinata comprende:
- cancellare i cookie soltanto dopo averne annotato dominio e path;
- ripetere il login osservando ogni risposta HTTP;
- identificare il primo redirect verso un host o protocollo inatteso;
- confrontare URL del network e del sottosito;
- verificare configurazione proxy, web server e certificati;
- controllare eventuali regole di cache o sicurezza sul login.
Provare in navigazione privata può confermare l’effetto di cookie precedenti, ma non dimostra che la configurazione del server sia corretta per tutti gli utenti.
Domain mapping, DNS e certificati SSL
Dal WordPress 4.5 il domain mapping è una funzione nativa. La guida ufficiale al domain mapping Multisite richiede che i domini puntino al server, che il server li associ alla stessa installazione e che ogni dominio disponga del certificato SSL necessario.
Il percorso completo è quindi:
- il DNS risolve il dominio verso l’infrastruttura corretta;
- il virtual host accetta quel nome e usa la document root prevista;
- il certificato copre il dominio richiesto;
- WordPress associa l’host al sottosito corretto;
- il cookie viene impostato e restituito per il contesto giusto.
Un errore in uno di questi livelli può apparire come problema WordPress anche se nasce prima dell’applicazione. Per questo modificare direttamente le tabelle della rete senza controllare DNS e server può peggiorare la situazione.
HTTPS dietro reverse proxy o CDN
Quando TLS termina su un proxy, WordPress deve riconoscere che la richiesta originale era HTTPS. Se l’applicazione interpreta la connessione interna come HTTP, può generare redirect verso HTTPS mentre il proxy continua a inoltrare la richiesta in modo non coerente. Il risultato può essere un loop oppure cookie Secure gestiti nel contesto sbagliato.
La correzione dipende dall’infrastruttura e dagli header realmente impostati. Fidarsi indiscriminatamente di header forniti dal client è rischioso; bisogna configurare proxy e applicazione in modo coordinato. Anche la cache della CDN deve escludere correttamente le pagine amministrative e le risposte personalizzate per utenti autenticati.
L’articolo sulla migrazione WordPress con DNS, SSL ed email approfondisce i livelli infrastrutturali che possono cambiare durante un trasferimento.
Costanti Multisite e cookie: perché evitare tentativi casuali
Nel file wp-config.php una rete Multisite usa costanti che descrivono dominio, percorso e tipo di installazione. Possono inoltre essere presenti personalizzazioni per i cookie. Copiare una configurazione trovata online senza adattarla alla rete può spostare il problema da un sottosito all’altro.
La documentazione sul domain mapping indica una possibile definizione di COOKIE_DOMAIN per specifici problemi di login sui domini mappati. Non è però una prescrizione universale: reti a sottodomini, sottocartelle, domini distinti e proxy hanno comportamenti differenti.
Prima di cambiare le costanti occorre confrontare:
- configurazione corrente del network;
- valori registrati per sito e rete;
- domini effettivamente usati dagli utenti;
- cookie osservati nel browser;
- regole del web server;
- comportamento in HTTP e HTTPS.
Qualsiasi modifica dovrebbe essere testata su una copia coerente o con un piano di ripristino, perché un errore può impedire l’accesso all’intera rete.
Quando il loop dipende da plugin, cache o sicurezza
Plugin di sicurezza, single sign-on, gestione ruoli e cache possono aggiungere redirect o modificare l’autenticazione. Il test non consiste necessariamente nel disattivarli tutti in produzione. È preferibile ricostruire la catena di redirect e verificare hook e log, quindi riprodurre il comportamento in staging.
Se il loop riguarda un solo sottosito o un solo dominio mappato, il confronto con un sito funzionante della stessa rete è particolarmente utile. Se coinvolge l’intero network dopo una migrazione, diventano prioritari URL, costanti, proxy e sostituzioni nel database.
Quando serve assistenza per un login loop Multisite
Il supporto tecnico è indicato quando il problema coinvolge più domini, compare dopo una migrazione, dipende da un reverse proxy oppure impedisce l’accesso al Network Admin. Sono scenari in cui browser, WordPress e infrastruttura devono essere analizzati insieme.
Se la tua rete WordPress Multisite torna continuamente al login, posso verificare cookie, redirect, domain mapping, SSL, proxy e configurazione della rete senza applicare modifiche casuali ai dati. Trovi i riferimenti nella pagina di assistenza WordPress.
