Błąd HTTP 401 Unauthorized: Kompletny przewodnik diagnostyki i naprawy

Kod statusu HTTP 401 Unauthorized oznacza, że serwer otrzymał Twoje żądanie, ale odmawia jego przetworzenia, ponieważ prawidłowe dane uwierzytelniające były nieobecne, nieprawidłowe lub wygasłe. W przeciwieństwie do błędu 403 Forbidden — gdzie serwer rozpoznaje Cię, ale odmawia dostępu na podstawie uprawnień — 401 sygnalizuje konkretnie błąd uwierzytelniania: serwer nie wie, kim jesteś lub nie może tego zweryfikować.

To rozróżnienie ma znaczenie. Odpowiedź 401 zawsze zawiera nagłówek WWW-Authenticate w odpowiedzi serwera, informując klienta, którego schematu uwierzytelniania użyć. Jeśli ten nagłówek jest nieobecny, możesz mieć do czynienia z błędnie skonfigurowanym serwerem, a nie problemem z danymi uwierzytelniającymi. Znajomość dokładnego trybu awarii przed rozpoczęciem rozwiązywania problemów oszczędza znaczną ilość czasu.

Jak faktycznie wygląda odpowiedź 401

Błąd pojawia się w kilku wariantach komunikatów w zależności od oprogramowania serwera, frameworka lub CDN przed aplikacją:

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

401 Authorization Required (powszechne w NGINX)
HTTP 401 (klienci API, Postman, curl)

Wszystkie te przypadki odnoszą się do tego samego kodu statusu zdefiniowanego w RFC 9110. Różnica w sformułowaniach jest czysto kosmetyczna — wynika z serwera WWW, odwrotnego proxy lub frameworka aplikacji generującego odpowiedź.
Techniczna anatomia błędu 401
Zrozumienie tego, co dzieje się na poziomie protokołu, zapobiega zgadywaniu. Gdy klient wysyła żądanie do chronionego zasobu bez danych uwierzytelniających, serwer odpowiada:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token"
Content-Type: application/json
Nagłówek WWW-Authenticate to wyzwanie serwera. Informuje klienta dokładnie, który schemat — Basic, Bearer, Digest, NTLM lub niestandardowy schemat — jest wymagany. Klient, który ignoruje ten nagłówek i ponawia próbę bez dostosowania żądania, będzie zapętlał się w nieskończoność.
401 vs. 403 vs. 407: Znajomość różnic



Kod statusu
Nazwa
Przyczyna główna
Nagłówek `WWW-Authenticate`








—
—
—
—








401
Unauthorized
Brakujące lub nieprawidłowe dane uwierzytelniające
Wymagane przez specyfikację








403
Forbidden
Uwierzytelniony, ale brak uprawnień
Nieobecny








407
Proxy Auth Required
Serwer proxy wymaga danych uwierzytelniających
Nagłówek `Proxy-Authenticate`








511
Network Auth Required
Captive portal (hotelowe Wi-Fi itp.)
Nie dotyczy





Mylne zidentyfikowanie 403 jako 401 to częsty błąd deweloperów. Jeśli Twój serwer zwraca 401, ale pomija WWW-Authenticate, jest technicznie niezgodny z RFC 9110 — a niektórzy rygorystyczni klienci HTTP będą traktować odpowiedź jako zniekształconą.
Przyczyny błędu 401 Unauthorized
Problemy z danymi uwierzytelniającymi i tokenami

Nieprawidłowa nazwa użytkownika lub hasło — najczęstsza przyczyna w przypadku dostępu przez przeglądarkę
Wygasłe tokeny dostępu — tokeny Bearer OAuth 2.0 mają skończoną wartość expires_in; po jej upływie każde żądanie zwraca 401 do momentu odświeżenia tokena
Unieważnione klucze API — klucze mogą zostać unieważnione po stronie serwera bez powiadamiania klienta
Niezgodność podpisu JWT — jeśli sekret podpisywania zostanie zmieniony, a klient posiada token podpisany starym sekretem, weryfikacja kończy się cichym niepowodzeniem
Rozbieżność zegarów — JWT zawierają roszczenia iat (wydany o) i exp (wygaśnięcie) weryfikowane względem czasu serwera; zegar klienta przesunięty o więcej niż kilka minut może powodować odrzucanie prawidłowych tokenów

Brakujące lub zniekształcone nagłówki Authorization
Każdy schemat uwierzytelniania ma precyzyjny format nagłówka. Odchylenie od niego — nawet o jedną spację lub nieprawidłowe dopełnienie Base64 — powoduje błąd 401:
# Correct Basic Auth header
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# Correct Bearer token header
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Częstym błędem jest wysyłanie Authorization: bearer <token> (małymi literami b). Chociaż RFC 6750 stwierdza, że nazwa schematu jest niewrażliwa na wielkość liter, wiele bibliotek po stronie serwera wykonuje ścisłe dopasowanie ciągów i odrzuca wariant pisany małymi literami.
Błędna konfiguracja po stronie serwera

Wymuszana niewłaściwa metoda uwierzytelniania — serwer skonfigurowany dla OAuth 2.0 otrzymujący nagłówki Basic Auth odrzuci je
Dyrektywy .htaccess — w Apache błędnie skonfigurowana dyrektywa AuthType, AuthName lub Require w .htaccess będzie blokować każde żądanie za monitem o hasło
Bloki auth_basic w NGINX — dyrektywa auth_basic zastosowana do niewłaściwego bloku location może zablokować dostęp prawidłowym użytkownikom
Odwrotne proxy usuwające nagłówki — load balancery i odwrotne proxy (NGINX, HAProxy, Cloudflare) mogą usuwać lub przepisywać nagłówki Authorization zanim dotrą do serwera źródłowego

Ingerencja przeglądarki i po stronie klienta

Uszkodzone ciasteczka — ciasteczka sesji przechowujące stan uwierzytelniania mogą ulec uszkodzeniu lub niezgodności po unieważnieniu sesji po stronie serwera
Agresywne rozszerzenia przeglądarki — blokery reklam, rozszerzenia prywatności i rozszerzenia VPN mogą modyfikować lub usuwać nagłówki żądań
Błędy wstępnego żądania CORS — w wywołaniach API między domenami przeglądarka wysyła wstępne żądanie OPTIONS; jeśli serwer nie odpowie na nie prawidłowo, właściwe uwierzytelnione żądanie nigdy nie zostanie wysłane

Czynniki infrastrukturalne i sieciowe

Reguły zapory blokujące punkty końcowe uwierzytelniania — WAF (Web Application Firewalls) z nadmiernie agresywnymi regułami mogą oznaczać i odrzucać żądania zawierające nagłówki Authorization jako potencjalne ataki wstrzykiwania
CDN buforujące uwierzytelnione odpowiedzi — jeśli CDN buforuje odpowiedź 401 i serwuje ją kolejnym użytkownikom, nawet prawidłowe dane uwierzytelniające będą wyglądać na nieprawidłowe
Ograniczanie szybkości na podstawie IP — powtarzające się nieudane próby uwierzytelniania mogą wywołać tymczasową blokadę zwracającą 401 dla wszystkich żądań z tego IP

Jak naprawić błąd 401: krok po kroku
Dla użytkowników końcowych i dostępu przez przeglądarkę
Krok 1: Dokładnie zweryfikuj dane uwierzytelniające
Sprawdź, czy Caps Lock jest wyłączony. Upewnij się, że używasz aktualnego hasła — nie zapisanego przed ostatnim resetem. Jeśli Twoje konto używa uwierzytelniania wieloskładnikowego (MFA), upewnij się, że jednorazowy kod nie wygasł (kody TOTP są domyślnie ważne przez 30 sekund).
Krok 2: Wyczyść ciasteczka i pamięć podręczną przeglądarki
Nieaktualne ciasteczka sesji są trwałym źródłem pętli 401. W Chrome przejdź do chrome://settings/clearBrowserData, ustaw zakres czasu na Cały czas, zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamięci podręcznej, a następnie wyczyść. W Firefox użyj about:preferences#privacy i kliknij Wyczyść dane.
Po wyczyszczeniu zamknij wszystkie karty przeglądarki dla danej domeny przed ponowną próbą — niektóre przeglądarki utrzymują stan sesji w pamięci, który przeżywa wyczyszczenie pamięci podręcznej, jeśli karta pozostaje otwarta.
Krok 3: Przetestuj w oknie prywatnym/incognito
Okno prywatne uruchamia się bez ciasteczek, bez danych w pamięci podręcznej i z wyłączonymi większością rozszerzeń. Jeśli błąd 401 znika w trybie incognito, problem jest definitywnie po stronie klienta: albo uszkodzone ciasteczko, buforowana zła odpowiedź lub rozszerzenie przeglądarki.
Krok 4: Selektywnie wyłączaj rozszerzenia
Przejdź do chrome://extensions/ i wyłącz wszystkie rozszerzenia. Przeładuj stronę. Jeśli uwierzytelnianie się powiedzie, włączaj rozszerzenia jedno po drugim, aby zidentyfikować winowajcę. Privacy Badger, uMatrix i niektóre rozszerzenia VPN są częstymi sprawcami.
Krok 5: Sprawdź URL pod kątem błędów
Upewnij się, że nie nawigujesz do ścieżki wymagającej podwyższonych uprawnień. URL taki jak /admin/dashboard zwróci 401, jeśli Twoja sesja nie ma uprawnień administratora — nawet jeśli podstawowe logowanie jest prawidłowe. Zweryfikuj dokładną ścieżkę z właścicielem witryny lub dokumentacją.
Krok 6: Zresetuj hasło
Jeśli podejrzewasz wygaśnięcie danych uwierzytelniających, skorzystaj z procedury Zapomniałem hasła. Po zresetowaniu wyczyść ciasteczka ponownie przed próbą logowania — stare ciasteczko sesji może kolidować z nowym stanem danych uwierzytelniających.
Dla deweloperów i integracji API
Krok 7: Sprawdź surową odpowiedź HTTP
Przed wprowadzeniem jakichkolwiek zmian przechwyć dokładną odpowiedź serwera używając curl z pełnym wyjściem:
curl -v -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/endpoint
Flaga -v pokazuje zarówno wysłane nagłówki żądania, jak i otrzymane nagłówki odpowiedzi, w tym wyzwanie WWW-Authenticate. Informuje Cię dokładnie, którego schematu oczekuje serwer.
Krok 8: Zweryfikuj stan tokena
Dla tokenów JWT zdekoduj ładunek bez weryfikacji podpisu, aby sprawdzić roszczenia:
echo "YOUR_JWT_PAYLOAD_BASE64" | base64 --decode | python3 -m json.tool
Sprawdź pole exp (znacznik czasu Unix). Porównaj go z aktualnym czasem:
date +%s
Jeśli exp jest mniejsze niż aktualny znacznik czasu, token wygasł. Zaimplementuj procedurę odświeżania używając punktu końcowego tokena Twojego dostawcy OAuth przed wygaśnięciem tokena.
Krok 9: Sprawdź konfigurację uwierzytelniania po stronie serwera
W Apache sprawdź odpowiedni plik .htaccess lub konfigurację wirtualnego hosta:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Potwierdź, że ścieżka AuthUserFile istnieje i jest czytelna przez proces serwera WWW. W NGINX sprawdź odpowiedni blok serwera lub lokalizacji:
location /secure/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
Zweryfikuj, czy plik .htpasswd zawiera prawidłowe zahaszowane dane uwierzytelniające. Użyj htpasswd -v /etc/nginx/.htpasswd username do przetestowania hasła względem przechowywanego hasha.
Krok 10: Sprawdź logi serwera
Logi serwera dostarczają prawdziwych informacji. W Apache:
tail -f /var/log/apache2/error.log | grep 401
W NGINX:
tail -f /var/log/nginx/error.log | grep 401
W przypadku uwierzytelniania na poziomie aplikacji (Node.js, Django, Laravel) sprawdź własne wyjście logów aplikacji. Wpis w logu często określi, czy błąd wynikał z brakującego nagłówka, nieprawidłowego tokena czy błędu wyszukiwania w bazie danych.
Krok 11: Zweryfikuj przekazywanie nagłówków przez odwrotne proxy
Jeśli Twoja aplikacja działa za NGINX działającym jako odwrotne proxy, upewnij się, że nagłówek Authorization jest przekazywany do aplikacji upstream:
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Authorization $http_authorization;
    proxy_pass_header Authorization;
}
Bez proxy_pass_header Authorization NGINX usuwa nagłówek zanim dotrze do serwera aplikacji — powodując błąd 401, który wygląda jak błąd klienta, ale jest całkowicie spowodowany przez infrastrukturę.
Krok 12: Sprawdź reguły WAF i zapory
Jeśli używasz WAF (ModSecurity, Cloudflare WAF, AWS WAF), sprawdź, czy jakaś reguła dopasowuje i blokuje żądania zawierające nagłówki Authorization. Tymczasowo ustaw WAF w tryb tylko wykrywania i spróbuj ponownie. Jeśli błąd 401 zniknie, doprecyzuj naruszającą regułę zamiast całkowicie wyłączać WAF.
Krok 13: Sprawdź zachowanie buforowania CDN
Upewnij się, że Twój CDN nie buforuje odpowiedzi 401. W Cloudflare ustaw regułę pamięci podręcznej, aby pomijać pamięć podręczną dla uwierzytelnionych punktów końcowych. W AWS CloudFront skonfiguruj zachowanie tak, aby przekazywać nagłówek Authorization do źródła — domyślnie CloudFront go usuwa, co oznacza, że Twoje źródło nigdy nie otrzymuje danych uwierzytelniających i zawsze zwraca 401.
Wdrażanie solidnego uwierzytelniania: najlepsze praktyki dla właścicieli serwerów
Jeśli zarządzasz aplikacją internetową lub API — czy to w środowisku Hostingu VPS, czy na Serwerze Dedykowanym — te praktyki zapobiegają docieraniu błędów 401 do Twoich użytkowników.
Zarządzanie cyklem życia tokenów
Nigdy nie wydawaj tokenów bez zdefiniowanego wygaśnięcia. Dla OAuth 2.0 używaj krótkotrwałych tokenów dostępu (15–60 minut) w połączeniu z długotrwałymi tokenami odświeżania. Wdrożyj proaktywne odświeżanie tokenów: wyzwalaj odświeżanie, gdy token dostępu ma mniej niż 20% pozostałego czasu życia, a nie po jego wygaśnięciu.
Access Token TTL:  15 minutes
Refresh Token TTL: 30 days (rotated on each use)
Refresh trigger:   < 3 minutes remaining on access token
Dla systemów opartych na JWT wdrożyj rotację kluczy z okresem przejściowym. Podczas rotacji sekretu podpisywania zachowaj stary sekret ważny przez jeden dodatkowy czas życia tokena, aby tokeny w trakcie przetwarzania nie zostały natychmiast unieważnione.
Znaczące odpowiedzi na błędy
Odpowiedź 401 powinna zawsze zawierać treść, która pomaga klientowi zrozumieć, co zrobić dalej:
{
  "error": "invalid_token",
  "error_description": "The access token expired at 2024-01-15T10:30:00Z",
  "error_uri": "https://api.example.com/docs/authentication"
}
Niejasne odpowiedzi 401 zwracające tylko kod statusu zmuszają deweloperów do zgadywania przyczyny błędu, znacznie zwiększając obciążenie pomocą techniczną.
Logowanie uwierzytelniania i alerty
Rejestruj każdy błąd uwierzytelniania z wystarczającym kontekstem: znacznik czasu, adres IP, agent użytkownika, żądany zasób i przyczyna błędu. Skonfiguruj alerty dla anomalnych wzorców — skok liczby błędów 401 z jednego IP wskazuje na błędną konfigurację lub atak credential stuffing. Platformy działające na Serwerach Dedykowanych mają pełny dostęp do logów systemowych i mogą wdrażać niestandardowe potoki alertów bez ograniczeń.
Bezpieczna transmisja danych uwierzytelniających
Dane uwierzytelniające muszą być przesyłane wyłącznie przez szyfrowane połączenia. Jeśli Twoja aplikacja obsługuje logowania użytkowników, Certyfikat SSL jest niezbędny — przesyłanie danych uwierzytelniających Basic Auth przez zwykłe HTTP ujawnia zakodowane w Base64 nazwy użytkowników i hasła w postaci jawnego tekstu w sieci.
Zakres i rotacja kluczy API
Wydawaj klucze API z minimalnym wymaganym zakresem. Wdrożyj politykę rotacji kluczy i zapewnij klientom mechanizm rotacji umożliwiający wymianę kluczy bez przestojów. Natychmiast unieważniaj skompromitowane klucze i powiadamiaj dotknięte tym klientów przez udokumentowany kanał.
Testowanie przepływów uwierzytelniania w CI/CD
Zintegruj testy przepływu uwierzytelniania z potokiem wdrożeniowym. Zestaw testów ćwiczący prawidłowe dane uwierzytelniające, wygasłe tokeny, brakujące nagłówki i unieważnione klucze wykryje regresje przed dotarciem do środowiska produkcyjnego. Jest to szczególnie istotne po aktualizacjach zależności dotykających oprogramowanie pośredniczące uwierzytelniania.
Błędy 401 w określonych środowiskach
WordPress
WordPress zwraca 401 w swoim REST API (/wp-json/), gdy Hasła Aplikacji są błędnie skonfigurowane lub gdy wtyczka bezpieczeństwa (Wordfence, iThemes Security) blokuje dostęp do REST API. Sprawdź Settings > Permalinks i zapisz ponownie — to czyści reguły przepisywania, które mogą przerywać punkty końcowe uwierzytelniania. Jeśli zarządzasz WordPress na VPS z cPanel, sprawdź, czy mod_rewrite jest włączony i czy .htaccess jest zapisywalny.
cPanel i panele kontrolne hostingu
Katalogi chronione hasłem skonfigurowane przez cPanel używają mod_authn_file Apache. Jeśli ścieżka pliku .htpasswd w wygenerowanym .htaccess jest bezwzględna i katalog główny dokumentów zmienia się (powszechne po migracjach kont), ścieżka ulega uszkodzeniu i każde żądanie zwraca 401. Zawsze używaj ścieżek względnych lub weryfikuj ścieżki bezwzględne po każdej migracji. Środowiska używające Paneli Kontrolnych VPS zapewniają bezpośredni dostęp do systemu plików w celu poprawienia tych ścieżek bez otwierania zgłoszenia do pomocy technicznej.
Klienci poczty e-mail i uwierzytelnianie SMTP
Serwery SMTP zwracają odpowiednik protokołowy błędu 401 (535 Authentication credentials invalid), gdy dane uwierzytelniające klienta poczty są nieprawidłowe lub gdy serwer wymaga STARTTLS, a klient próbuje uwierzytelniania w postaci jawnej. Jeśli konfigurujesz Hosting Poczty E-mail, upewnij się, że Twój klient poczty jest skonfigurowany z prawidłową metodą uwierzytelniania (PLAIN, LOGIN lub CRAM-MD5) i że TLS jest wymuszany przed przesłaniem danych uwierzytelniających.
Aplikacje mobilne
Aplikacje mobilne często napotykają błędy 401 po zmianie hasła przez użytkownika w sieci — przechowywany token odświeżania aplikacji jest unieważniany po stronie serwera, ale aplikacja nie ma mechanizmu wykrycia tego do momentu, gdy następne wywołanie API zakończy się niepowodzeniem. Wdrożyj globalny interceptor HTTP, który przechwytuje odpowiedzi 401, próbuje odświeżenia tokena dokładnie raz, a jeśli odświeżenie również zwróci 401, przekierowuje użytkownika do ekranu logowania z jasnym komunikatem.
Macierz decyzyjna: diagnozowanie błędu 401



Objaw
Najbardziej prawdopodobna przyczyna
Pierwsze działanie








—
—
—








401 przy wszystkich żądaniach, w tym wcześniej działających
Token wygasł lub został unieważniony
Sprawdź roszczenie `exp` tokena; wyzwól odświeżanie








401 tylko w przeglądarce, nie w curl
Uszkodzone ciasteczko lub ingerencja rozszerzenia
Wyczyść ciasteczka; przetestuj w trybie incognito








401 tylko z określonego IP
Limit szybkości zapory lub blokada IP
Sprawdź logi WAF; dodaj do białej listy jeśli uzasadnione








401 po migracji serwera
Uszkodzona ścieżka `.htpasswd`
Zweryfikuj ścieżkę `AuthUserFile` w `.htaccess`








401 przy wstępnym żądaniu OPTIONS
Błędna konfiguracja CORS
Dodaj `Authorization` do `Access-Control-Allow-Headers`








401 mimo prawidłowych danych uwierzytelniających
Odwrotne proxy usuwa nagłówki
Dodaj `proxy_pass_header Authorization` do konfiguracji NGINX








401 przy zasobach buforowanych przez CDN
CDN serwuje buforowaną odpowiedź 401
Pomiń pamięć podręczną dla uwierzytelnionych tras








401 po aktualizacji zależności
Przełomowa zmiana w oprogramowaniu pośredniczącym uwierzytelniania
Przejrzyj dziennik zmian; sprawdź logikę parsowania nagłówków





Praktyczna lista kontrolna przed eskalacją błędu 401
Użyj tej listy kontrolnej przed złożeniem zgłoszenia do pomocy technicznej lub eskalacją do zespołu infrastruktury:

Przechwycono surową odpowiedź HTTP za pomocą curl -v i potwierdzono wartość nagłówka WWW-Authenticate

• Zdekodowano JWT lub token i zweryfikowano roszczenie exp względem aktualnego czasu serwera
• Potwierdzono, że format nagłówka Authorization odpowiada schematowi reklamowanemu przez serwer
• Przetestowano w oknie incognito z wyłączonymi wszystkimi rozszerzeniami
• Wyczyszczono wszystkie ciasteczka i pamięć podręczną dla danej domeny
• Sprawdzono logi błędów serwera pod kątem konkretnej przyczyny odrzucenia
• Zweryfikowano, że konfiguracja odwrotnego proxy przekazuje nagłówek Authorization
• Potwierdzono, że CDN nie buforuje odpowiedzi 401
• Sprawdzono reguły WAF pod kątem fałszywie pozytywnych dopasowań nagłówka Authorization
• Zweryfikowano, że SSL/TLS jest aktywny na punkcie końcowym — dane uwierzytelniające nigdy nie powinny być przesyłane niezaszyfrowane

FAQ

Jaka jest różnica między HTTP 401 a HTTP 403?

401 oznacza, że serwer nie może zidentyfikować, kim jesteś — uwierzytelnianie jest brakujące lub nieprawidłowe. 403 oznacza, że serwer wie, kim jesteś, ale zdecydował, że nie masz uprawnień dostępu do zasobu. Napraw błąd 401 podając lub korygując dane uwierzytelniające; napraw błąd 403 dostosowując reguły kontroli dostępu lub uprawnienia.

Dlaczego moje API zwraca 401, nawet gdy wysyłam prawidłowy token?

Najczęstsze przyczyny to wygaśnięcie tokena (sprawdź roszczenie exp), rozbieżność zegarów między klientem a serwerem (zsynchronizuj NTP), rotacja sekretu podpisywania unieważniająca istniejące tokeny lub nagłówek Authorization usuwany przez odwrotne proxy lub CDN przed dotarciem do serwera źródłowego.

Czy błąd 401 może być spowodowany błędną konfiguracją serwera, a nie błędem klienta?

Tak. Błędnie skonfigurowany plik .htaccess, blok auth_basic NGINX zastosowany do niewłaściwej lokalizacji, odwrotne proxy usuwające nagłówek Authorization lub reguła WAF blokująca uwierzytelnione żądania — wszystko to może generować odpowiedzi 401 nawet gdy klient wysyła całkowicie prawidłowe dane uwierzytelniające.

Jak zapobiegać błędom 401 spowodowanym wygaśnięciem tokena w aplikacji produkcyjnej?

Wdrożyj proaktywne odświeżanie tokenów — monitoruj pozostały czas życia tokena i odświeżaj go przed wygaśnięciem, a nie po. Dla OAuth 2.0 użyj punktu końcowego tokena odświeżania, aby uzyskać nowy token dostępu, gdy bieżący ma mniej niż 20% pozostałego TTL. Dodaj globalny interceptor odpowiedzi HTTP, który automatycznie obsługuje odpowiedzi 401 próbując jednorazowego odświeżenia tokena przed ponowieniem oryginalnego żądania.

Czy wyczyszczenie ciasteczek zawsze naprawia błąd 401 w przeglądarce?

Tylko jeśli przyczyną jest uszkodzone lub nieaktualne ciasteczko sesji. Jeśli błąd 401 jest spowodowany błędną konfiguracją serwera, wygasłym kluczem API lub blokadą zapory, wyczyszczenie ciasteczek nie przyniesie efektu. Użyj okna incognito jako kroku diagnostycznego — jeśli błąd 401 utrzymuje się w trybie incognito, problem leży po stronie serwera lub sieci, a nie przeglądarki.