L’errore 401 Unauthorized indica che la richiesta non contiene credenziali valide per la risorsa. La risposta dovrebbe comunicare il metodo di autenticazione atteso tramite l’header WWW-Authenticate.
Questa guida approfondisce errore 401 Unauthorized con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
A differenza del 403, un 401 può essere risolto presentando credenziali corrette. Il testo Unauthorized non significa necessariamente che l’utente non esista: token scaduti, cookie non inviati e proxy che rimuovono header producono lo stesso codice.
La protezione può essere applicata dal web server tramite Basic Authentication, da WordPress, da una API, da Cloudflare Access o da un sistema esterno.
Come riconoscere il problema
- Il browser mostra una finestra username e password.
- Una API restituisce 401 dopo la scadenza del token.
- Il sito funziona ma un endpoint protetto no.
- Dopo un cambio dominio il cookie non viene inviato.
- Un proxy o CDN modifica l’header Authorization.
Cause più frequenti
1. Credenziali errate
Username, password o token non corrispondono alla risorsa. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Token scaduto o revocato
API key, bearer token o sessione non sono più validi. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Basic Auth configurata
Una directory o staging richiede autenticazione web server. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Cookie con dominio o Secure errato
La sessione non viene inviata all’hostname o al protocollo richiesto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Header Authorization rimosso
Proxy, rewrite o configurazione FastCGI possono non inoltrare l’header. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Nonce o Application Password WordPress
L’integrazione usa un metodo non supportato o credenziali revocate. 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
- Leggi WWW-Authenticate. Identifica Basic, Bearer o altro schema previsto. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Prova un nuovo login. Genera una sessione e credenziali aggiornate. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla la richiesta. Verifica che Authorization o cookie siano realmente inviati. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta accesso diretto e proxy. Determina se la CDN rimuove o modifica header. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla .htaccess e protezione directory. Cerca AuthType, AuthUserFile e regole correlate. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica API e permessi. Controlla endpoint, utente, scope e metodo di autenticazione. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Leggi log applicativi. Cerca token expired, invalid signature e user not authenticated. 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
- Aggiorna le credenziali. Reimposta password o genera un token con privilegi minimi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi il client. Invia lo schema e l’header previsti dalla documentazione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Allinea cookie e URL. Usa HTTPS, hostname corretto e dominio cookie coerente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Inoltra Authorization. Correggi proxy o configurazione del web server senza esporre il token. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Rimuovi Basic Auth solo se non serve. Mantieni protetti staging e aree riservate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Revoca token vecchi. Elimina credenziali duplicate e non più usate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Verifica 401 e 403 separatamente. Dopo autenticazione controlla anche i permessi dell’utente. 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
- Le credenziali valide producono accesso.
- Credenziali errate continuano a essere rifiutate.
- L’header Authorization raggiunge l’applicazione.
- Cookie e token usano HTTPS.
- I privilegi restano limitati al necessario.
Prevenzione
- Usa token con scadenza.
- Proteggi le credenziali.
- Monitora accessi falliti.
- Documenta Basic Auth.
- Revoca account dismessi.
Errori da evitare
- Non inserire password nella URL.
- Non disattivare autenticazione per test permanenti.
- Non pubblicare token nei log condivisi.
- Non confondere 401 e 403.
- Non assegnare privilegi amministrativi non necessari.
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 o endpoint
- schema di autenticazione
- orario
- codice e header WWW-Authenticate
- client utilizzato senza password
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 errore 401 Unauthorized
Qual è la differenza tra 401 e 403?
Il 401 richiede autenticazione valida; il 403 indica che l’accesso resta negato anche dopo l’identificazione.
Devo inviare la password al supporto?
No. Sono sufficienti metodo, endpoint, orario e messaggio di errore.
Un token scaduto genera 401?
Sì, è una delle cause più comuni nelle API.
Cloudflare può causare 401?
Può applicare Access o inoltrare una risposta generata dall’origine.
Perché funziona dal browser ma non dall’API?
Il browser può usare cookie di sessione mentre l’API richiede token o Application Password.