Eroare HTTP 401 Unauthorized: Ghid Complet de Diagnosticare și Remediere

Codul de stare HTTP 401 Unauthorized înseamnă că serverul a primit cererea dvs., dar refuză să o proceseze deoarece acreditările de autentificare valide lipsesc, sunt incorecte sau au expirat. Spre deosebire de eroarea 403 Forbidden — unde serverul vă recunoaște, dar refuză accesul pe baza permisiunilor — un 401 semnalează în mod specific o eroare de autentificare: serverul nu știe cine ești sau nu poate verifica acest lucru.

Această distincție contează. Un răspuns 401 include întotdeauna un antet WWW-Authenticate în răspunsul serverului, instruind clientul ce schemă de autentificare să utilizeze. Dacă acel antet lipsește, este posibil să aveți de-a face cu un server configurat greșit, mai degrabă decât cu o problemă de acreditări. Cunoașterea modului exact de eșec înainte de a începe depanarea economisește timp semnificativ.

Cum arată de fapt un răspuns 401

Eroarea apare sub mai multe variante de mesaj, în funcție de software-ul serverului, framework sau CDN din fața aplicației:

• 401 Unauthorized
• HTTP Error 401 – Unauthorized
• 401 Unauthorized: Access is denied due to invalid credentials
• Authorization Required

401 Authorization Required (frecvent în NGINX)
HTTP 401 (clienți API, Postman, curl)

Toate acestea corespund aceluiași cod de stare definit de RFC 9110. Variația în formulare este pur cosmetică — determinată de serverul web, proxy-ul invers sau framework-ul aplicației care generează răspunsul.
Anatomia tehnică a unei erori 401
Înțelegerea a ceea ce se întâmplă la nivelul protocolului previne presupunerile. Când un client trimite o cerere către o resursă protejată fără acreditări, serverul răspunde cu:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token"
Content-Type: application/json
Antetul WWW-Authenticate reprezintă provocarea serverului. Acesta îi spune clientului exact ce schemă — Basic, Bearer, Digest, NTLM sau o schemă personalizată — este necesară. Un client care ignoră acest antet și reîncearcă fără a-și ajusta cererea va intra într-o buclă indefinită.
401 vs. 403 vs. 407: Cunoașterea diferenței



Cod de stare
Denumire
Cauza principală
Antet `WWW-Authenticate`








—
—
—
—








401
Unauthorized
Acreditări de autentificare lipsă sau invalide
Obligatoriu conform specificației








403
Forbidden
Autentificat, dar lipsesc permisiunile
Absent








407
Proxy Auth Required
Serverul proxy necesită acreditări
Antet `Proxy-Authenticate`








511
Network Auth Required
Portal captiv (Wi-Fi hotel etc.)
Nu se aplică





Confundarea unui 403 cu un 401 este o eroare frecventă a dezvoltatorilor. Dacă serverul dvs. returnează 401, dar omite WWW-Authenticate, acesta nu este tehnic conform cu RFC 9110 — iar unii clienți HTTP stricți vor trata răspunsul ca malformat.
Cauzele principale ale erorii 401 Unauthorized
Probleme cu acreditările și token-urile

Nume de utilizator sau parolă incorectă — cea mai frecventă cauză pentru accesul prin browser
Token-uri de acces expirate — token-urile Bearer OAuth 2.0 au o valoare expires_in finită; odată depășită, fiecare cerere returnează 401 până când token-ul este reînnoit
Chei API revocate — cheile pot fi invalidate pe server fără ca clientul să fie notificat
Nepotrivire semnătură JWT — dacă secretul de semnare se rotește și clientul deține un token semnat cu vechiul secret, verificarea eșuează silențios
Decalaj de ceas — JWT-urile includ revendicările iat (emis la) și exp (expirare) validate față de ora serverului; un ceas al clientului deviat cu mai mult de câteva minute poate cauza respingerea token-urilor valide

Anteturi de autorizare lipsă sau malformate
Fiecare schemă de autentificare are un format precis al antetului. Abaterea de la acesta — chiar și printr-un singur spațiu sau padding Base64 incorect — produce un 401:
# Correct Basic Auth header
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# Correct Bearer token header
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
O greșeală frecventă este trimiterea Authorization: bearer <token> (b cu litere mici). Deși RFC 6750 precizează că numele schemei este insensibil la majuscule, multe biblioteci server-side efectuează potrivire strictă a șirurilor și resping varianta cu litere mici.
Configurare greșită pe server

Metodă de autentificare greșită impusă — un server configurat pentru OAuth 2.0 care primește anteturi Basic Auth le va respinge
Directive .htaccess — pe Apache, o directivă AuthType, AuthName sau Require configurată greșit în .htaccess va bloca fiecare cerere în spatele unui prompt de parolă
Blocuri auth_basic NGINX — o directivă auth_basic aplicată blocului location greșit poate bloca utilizatorii legitimi
Proxy invers care elimină antetele — echilibratorii de sarcină și proxy-urile inverse (NGINX, HAProxy, Cloudflare) pot elimina sau rescrie antetele Authorization înainte ca acestea să ajungă la serverul de origine

Interferențe din browser și de pe client

Cookie-uri corupte — cookie-urile de sesiune care transportă starea de autentificare pot deveni corupte sau nepotrivite după o invalidare a sesiunii pe server
Extensii de browser agresive — blocatoarele de reclame, extensiile de confidențialitate și extensiile VPN pot modifica sau elimina antetele cererilor
Eșecuri preflight CORS — în apelurile API cross-origin, browserul trimite o cerere preflight OPTIONS; dacă serverul nu răspunde corect la aceasta, cererea autentificată reală nu se mai execută

Factori de infrastructură și rețea

Reguli firewall care blochează endpoint-urile de autentificare — WAF-urile (Web Application Firewall) cu reguli excesiv de agresive pot marca și bloca cererile care conțin anteturi Authorization ca potențiale atacuri de injecție
CDN care memorează în cache răspunsurile autentificate — dacă un CDN memorează în cache un răspuns 401 și îl servește utilizatorilor următori, chiar și acreditările valide vor părea să eșueze
Limitarea ratei bazată pe IP — tentativele repetate de autentificare eșuate pot declanșa o blocare temporară care returnează 401 pentru toate cererile de la acel IP

Cum să remediați o eroare 401: Pas cu pas
Pentru utilizatori finali și acces prin browser
Pasul 1: Verificați acreditările cu precizie
Verificați că Caps Lock este dezactivat. Confirmați că utilizați parola curentă — nu una salvată înainte de o resetare recentă. Dacă contul dvs. utilizează autentificare cu mai mulți factori (MFA), asigurați-vă că codul unic nu a expirat (codurile TOTP sunt valabile implicit 30 de secunde).
Pasul 2: Ștergeți cookie-urile și cache-ul browserului
Cookie-urile de sesiune vechi sunt o sursă persistentă de bucle 401. În Chrome, navigați la chrome://settings/clearBrowserData, setați intervalul de timp la Tot timpul, bifați Cookie-uri și alte date de site și Imagini și fișiere în cache, apoi ștergeți. În Firefox, utilizați about:preferences#privacy și faceți clic pe Ștergeți datele.
După ștergere, închideți toate filele browserului pentru domeniul afectat înainte de a reîncerca — unele browsere mențin starea sesiunii în memorie care supraviețuiește unei ștergeri a cache-ului dacă fila rămâne deschisă.
Pasul 3: Testați într-o fereastră privată/incognito
O fereastră privată pornește fără cookie-uri, fără date în cache și cu majoritatea extensiilor dezactivate. Dacă eroarea 401 dispare în modul incognito, problema este definitiv pe client: fie un cookie corupt, un răspuns rău memorat în cache sau o extensie de browser.
Pasul 4: Dezactivați extensiile selectiv
Navigați la chrome://extensions/ și dezactivați toate extensiile. Reîncărcați pagina. Dacă autentificarea reușește, reactivați extensiile una câte una pentru a izola vinovatul. Privacy Badger, uMatrix și anumite extensii VPN sunt infractori frecvenți.
Pasul 5: Verificați URL-ul pentru erori
Asigurați-vă că nu navigați la o cale care necesită permisiuni ridicate. Un URL precum /admin/dashboard va returna 401 dacă sesiunea dvs. nu are privilegii de administrator — chiar dacă autentificarea de bază este validă. Verificați calea exactă cu proprietarul site-ului sau documentația.
Pasul 6: Resetați parola
Dacă se suspectează expirarea acreditărilor, utilizați fluxul Am uitat parola. După resetare, ștergeți din nou cookie-urile înainte de a încerca autentificarea — vechiul cookie de sesiune poate intra în conflict cu noua stare a acreditărilor.
Pentru dezvoltatori și integrări API
Pasul 7: Inspectați răspunsul HTTP brut
Înainte de a schimba orice, capturați răspunsul exact al serverului folosind curl cu ieșire detaliată:
curl -v -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/endpoint
Indicatorul -v afișează atât antetele cererilor trimise, cât și antetele răspunsurilor primite, inclusiv provocarea WWW-Authenticate. Aceasta vă spune exact ce schemă așteaptă serverul.
Pasul 8: Validați starea token-ului
Pentru token-urile JWT, decodificați payload-ul fără a verifica semnătura pentru a inspecta revendicările:
echo "YOUR_JWT_PAYLOAD_BASE64" | base64 --decode | python3 -m json.tool
Verificați câmpul exp (timestamp Unix). Comparați-l cu ora curentă:
date +%s
Dacă exp este mai mic decât timestamp-ul curent, token-ul a expirat. Implementați un flux de reînnoire folosind endpoint-ul de token al furnizorului dvs. OAuth înainte ca token-ul să ajungă la expirare.
Pasul 9: Auditați configurația de autentificare pe server
Pe Apache, inspectați fișierul .htaccess relevant sau configurația gazdei virtuale:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Confirmați că calea AuthUserFile există și este lizibilă de procesul serverului web. Pe NGINX, verificați blocul de server sau locație relevant:
location /secure/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
Verificați că fișierul .htpasswd conține acreditările hash corecte. Utilizați htpasswd -v /etc/nginx/.htpasswd username pentru a testa o parolă față de hash-ul stocat.
Pasul 10: Verificați jurnalele serverului
Jurnalele serverului oferă adevărul fundamental. Pe Apache:
tail -f /var/log/apache2/error.log | grep 401
Pe NGINX:
tail -f /var/log/nginx/error.log | grep 401
Pentru autentificarea la nivel de aplicație (Node.js, Django, Laravel), verificați ieșirea proprie a jurnalului aplicației. Intrarea din jurnal va specifica adesea dacă eșecul a fost un antet lipsă, un token invalid sau un eșec de căutare în baza de date.
Pasul 11: Verificați redirecționarea antetelor prin proxy invers
Dacă aplicația dvs. se află în spatele NGINX care acționează ca proxy invers, asigurați-vă că antetul Authorization este redirecționat către aplicația upstream:
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Authorization $http_authorization;
    proxy_pass_header Authorization;
}
Fără proxy_pass_header Authorization, NGINX elimină antetul înainte ca acesta să ajungă la serverul dvs. de aplicații — cauzând un 401 care pare o eroare de client, dar este cauzat în întregime de infrastructură.
Pasul 12: Inspectați regulile WAF și firewall
Dacă rulați un WAF (ModSecurity, Cloudflare WAF, AWS WAF), verificați dacă vreo regulă potrivește și blochează cererile care conțin anteturi Authorization. Setați temporar WAF-ul în modul doar-detecție și reîncercați. Dacă eroarea 401 dispare, rafinați regula incriminată în loc să dezactivați complet WAF-ul.
Pasul 13: Auditați comportamentul de cache al CDN
Asigurați-vă că CDN-ul dvs. nu memorează în cache răspunsurile 401. În Cloudflare, setați o regulă Cache pentru a ocoli cache-ul pentru endpoint-urile autentificate. În AWS CloudFront, configurați comportamentul pentru a redirecționa antetul Authorization către origine — în mod implicit, CloudFront îl elimină, ceea ce înseamnă că originea dvs. nu primește niciodată acreditările și returnează întotdeauna 401.
Implementarea autentificării robuste: Bune practici pentru proprietarii de servere
Dacă gestionați o aplicație web sau un API — fie într-un mediu de VPS Hosting sau pe un Server Dedicat — aceste practici previn erorile 401 să ajungă la utilizatorii dvs. de la bun început.
Gestionarea ciclului de viață al token-urilor
Nu emiteți niciodată token-uri fără o expirare definită. Pentru OAuth 2.0, utilizați token-uri de acces cu durată scurtă (15–60 de minute) asociate cu token-uri de reînnoire cu durată lungă. Implementați reînnoirea proactivă a token-urilor: declanșați o reînnoire când token-ul de acces are mai puțin de 20% din durata de viață rămasă, nu după ce a expirat deja.
Access Token TTL:  15 minutes
Refresh Token TTL: 30 days (rotated on each use)
Refresh trigger:   < 3 minutes remaining on access token
Pentru sistemele bazate pe JWT, implementați rotația cheilor cu o perioadă de grație. La rotirea secretului de semnare, păstrați vechiul secret valid pentru o durată de viață suplimentară a token-ului, astfel încât token-urile în tranzit să nu fie imediat invalidate.
Răspunsuri de eroare semnificative
Un răspuns 401 ar trebui să includă întotdeauna un corp care ajută clientul să înțeleagă ce să facă în continuare:
{
  "error": "invalid_token",
  "error_description": "The access token expired at 2024-01-15T10:30:00Z",
  "error_uri": "https://api.example.com/docs/authentication"
}
Răspunsurile 401 vagi care returnează doar un cod de stare îi forțează pe dezvoltatori să ghicească motivul eșecului, crescând dramatic sarcina de suport.
Jurnalizarea și alertarea autentificării
Înregistrați fiecare eșec de autentificare cu context suficient: timestamp, adresă IP, user agent, resursă solicitată și motiv al eșecului. Configurați alerte pentru tipare anomale — o creștere bruscă a erorilor 401 de la un singur IP indică fie o configurare greșită, fie un atac de tip credential stuffing. Platformele care rulează pe Servere Dedicate au acces complet la jurnalele la nivel de sistem și pot implementa pipeline-uri de alertare personalizate fără restricții.
Transmiterea securizată a acreditărilor
Acreditările de autentificare trebuie să călătorească doar prin conexiuni criptate. Dacă aplicația dvs. gestionează autentificările utilizatorilor, un Certificat SSL este indispensabil — transmiterea acreditărilor Basic Auth prin HTTP simplu expune numele de utilizator și parolele codificate Base64 în text clar pe rețea.
Scopul și rotația cheilor API
Emiteți chei API cu scopul minim necesar. Implementați o politică de rotație a cheilor și oferiți clienților un mecanism de rotație care le permite să schimbe cheile fără întreruperi. Revocați imediat cheile compromise și notificați clienții afectați printr-un canal documentat.
Testarea fluxurilor de autentificare în CI/CD
Integrați testele fluxului de autentificare în pipeline-ul dvs. de implementare. O suită de teste care exercită acreditări valide, token-uri expirate, anteturi lipsă și chei revocate va detecta regresiile înainte ca acestea să ajungă în producție. Acest lucru este deosebit de critic după actualizările de dependențe care ating middleware-ul de autentificare.
Erori 401 în medii specifice
WordPress
WordPress returnează 401 pe REST API-ul său (/wp-json/) când Parolele de aplicație sunt configurate greșit sau când un plugin de securitate (Wordfence, iThemes Security) blochează accesul la REST API. Verificați Settings > Permalinks și resalvați — aceasta golește regulile de rescriere care pot întrerupe endpoint-urile de autentificare. Dacă gestionați WordPress pe un VPS cu cPanel, verificați că mod_rewrite este activat și că .htaccess este inscriptibil.
cPanel și panouri de control pentru găzduire web
Directoarele protejate prin parolă configurate prin cPanel utilizează mod_authn_file al Apache. Dacă calea fișierului .htpasswd în .htaccess generat este absolută și rădăcina documentului se schimbă (frecvent după migrările de conturi), calea se întrerupe și fiecare cerere returnează 401. Utilizați întotdeauna căi relative sau verificați căile absolute după orice migrare. Mediile care utilizează Panouri de control VPS oferă acces direct la sistemul de fișiere pentru a corecta aceste căi fără a deschide un tichet de suport.
Clienți de e-mail și autentificare SMTP
Serverele SMTP returnează un echivalent la nivel de protocol al unui 401 (535 Authentication credentials invalid) când acreditările clientului de e-mail sunt greșite sau când serverul necesită STARTTLS și clientul încearcă autentificarea simplă. Dacă configurați Găzduire E-mail, asigurați-vă că clientul dvs. de e-mail este configurat cu metoda de autentificare corectă (PLAIN, LOGIN sau CRAM-MD5) și că TLS este impus înainte ca acreditările să fie transmise.
Aplicații mobile
Aplicațiile mobile întâlnesc frecvent erori 401 după ce un utilizator își schimbă parola pe web — token-ul de reînnoire stocat al aplicației este invalidat pe server, dar aplicația nu are niciun mecanism pentru a detecta acest lucru până când următorul apel API eșuează. Implementați un interceptor HTTP global care prinde răspunsurile 401, încearcă o reînnoire a token-ului exact o dată și, dacă reînnoirea returnează de asemenea 401, redirecționează utilizatorul către ecranul de autentificare cu un mesaj clar.
Matrice de decizie: Diagnosticarea erorii 401



Simptom
Cauza cea mai probabilă
Prima acțiune








—
—
—








401 la toate cererile, inclusiv cele care funcționau anterior
Token expirat sau revocat
Inspectați revendicarea `exp` a token-ului; declanșați reînnoirea








401 doar în browser, nu în curl
Cookie corupt sau interferență de extensie
Ștergeți cookie-urile; testați în incognito








401 doar de la un IP specific
Limită de rată WAF sau blocare IP
Verificați jurnalele WAF; adăugați pe lista albă dacă este legitim








401 după migrarea serverului
Cale `.htpasswd` întreruptă
Verificați calea `AuthUserFile` în `.htaccess`








401 la preflight OPTIONS
Configurare greșită CORS
Adăugați `Authorization` la `Access-Control-Allow-Headers`








401 în ciuda acreditărilor corecte
Proxy invers care elimină antetele
Adăugați `proxy_pass_header Authorization` în configurația NGINX








401 pe resurse memorate în cache de CDN
CDN servește răspuns 401 memorat în cache
Ocoliți cache-ul pentru rutele autentificate








401 după actualizarea dependențelor
Modificare incompatibilă în middleware-ul de autentificare
Revizuiți changelog-ul; verificați logica de parsare a antetelor





Listă de verificare practică înainte de a escalada o eroare 401
Utilizați această listă de verificare înainte de a depune un tichet de suport sau de a escalada la echipa dvs. de infrastructură:

Am capturat răspunsul HTTP brut cu curl -v și am confirmat valoarea antetului WWW-Authenticate

• Am decodificat JWT sau token-ul și am verificat revendicarea exp față de ora curentă a serverului
• Am confirmat că formatul antetului Authorization corespunde schemei pe care o anunță serverul
• Am testat într-o fereastră incognito cu toate extensiile dezactivate
• Am șters toate cookie-urile și cache-ul pentru domeniul afectat
• Am verificat jurnalele de erori ale serverului pentru motivul specific al respingerii
• Am verificat că configurația proxy-ului invers redirecționează antetul Authorization
• Am confirmat că CDN-ul nu memorează în cache răspunsul 401
• Am verificat regulile WAF pentru potriviri fals pozitive pe antetul Authorization
• Am verificat că SSL/TLS este activ pe endpoint — acreditările nu ar trebui să călătorească niciodată necriptate

Întrebări frecvente

Care este diferența dintre HTTP 401 și HTTP 403?

Un 401 înseamnă că serverul nu poate identifica cine ești — autentificarea lipsește sau este invalidă. Un 403 înseamnă că serverul știe cine ești, dar a decis că nu ai permisiunea de a accesa resursa. Remediați un 401 furnizând sau corectând acreditările; remediați un 403 ajustând regulile de control al accesului sau permisiunile.

De ce API-ul meu returnează 401 chiar și când trimit token-ul corect?

Cele mai frecvente cauze sunt expirarea token-ului (verificați revendicarea exp), decalajul de ceas între client și server (sincronizați NTP), un secret de semnare rotit care invalidează token-urile existente sau antetul Authorization eliminat de un proxy invers sau CDN înainte de a ajunge la serverul de origine.

Poate o eroare 401 să fie cauzată de o configurare greșită a serverului mai degrabă decât de o eroare a clientului?

Da. Un fișier .htaccess configurat greșit, un bloc auth_basic NGINX aplicat locației greșite, un proxy invers care elimină antetul Authorization sau o regulă WAF care blochează cererile autentificate pot produce toate răspunsuri 401 chiar și atunci când clientul trimite acreditări perfect valide.

Cum previn erorile 401 cauzate de expirarea token-urilor într-o aplicație de producție?

Implementați reînnoirea proactivă a token-urilor — monitorizați durata de viață rămasă a token-ului și reînnoiți-l înainte de expirare, nu după. Pentru OAuth 2.0, utilizați endpoint-ul token-ului de reînnoire pentru a obține un nou token de acces când cel curent are mai puțin de 20% din TTL-ul rămas. Adăugați un interceptor global de răspuns HTTP care gestionează automat răspunsurile 401 prin încercarea unei singure reînnoiri a token-ului înainte de a reîncerca cererea originală.

Ștergerea cookie-urilor rezolvă întotdeauna o eroare 401 în browser?

Doar dacă cauza principală este un cookie de sesiune corupt sau vechi. Dacă eroarea 401 este cauzată de o configurare greșită a serverului, o cheie API expirată sau o blocare de firewall, ștergerea cookie-urilor nu va avea niciun efect. Utilizați o fereastră incognito ca pas de diagnosticare — dacă eroarea 401 persistă în incognito, problema este pe server sau pe rețea, nu pe browser.