HTTP 401 Unauthorized Error: Повний посібник з діагностики та виправлення

Код стану HTTP 401 Unauthorized означає, що сервер отримав ваш запит, але відмовляється його обробляти, оскільки дійсні облікові дані автентифікації або відсутні, або некоректні, або застарілі. На відміну від помилки 403 Forbidden — коли сервер вас розпізнає, але відмовляє в доступі на основі дозволів — 401 конкретно сигналізує про збій автентифікації: сервер не знає, хто ви, або не може це підтвердити.

Ця відмінність важлива. Відповідь 401 завжди містить заголовок WWW-Authenticate у відповіді сервера, який вказує клієнту, яку схему автентифікації використовувати. Якщо цей заголовок відсутній, можливо, ви маєте справу з неправильно налаштованим сервером, а не з проблемою облікових даних. Знання точного режиму збою перед початком усунення несправностей заощаджує значний час.

Як насправді виглядає відповідь 401

Помилка з’являється під кількома варіантами повідомлень залежно від серверного програмного забезпечення, фреймворку або CDN перед застосунком:

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

401 Authorization Required (поширено в NGINX)
HTTP 401 (API-клієнти, Postman, curl)

Усі вони відповідають одному й тому ж коду стану, визначеному RFC 9110. Варіація у формулюванні є суто косметичною — зумовленою веб-сервером, зворотним проксі або фреймворком застосунку, що генерує відповідь.
Технічна анатомія помилки 401
Розуміння того, що відбувається на рівні протоколу, запобігає здогадкам. Коли клієнт надсилає запит до захищеного ресурсу без облікових даних, сервер відповідає:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token"
Content-Type: application/json
Заголовок WWW-Authenticate — це виклик сервера. Він точно повідомляє клієнту, яка схема — Basic, Bearer, Digest, NTLM або власна схема — є обов’язковою. Клієнт, який ігнорує цей заголовок і повторює запит без коригування, буде зациклюватися нескінченно.
401 проти 403 проти 407: знання різниці



Код стану
Назва
Першопричина
Заголовок `WWW-Authenticate`








—
—
—
—








401
Unauthorized
Відсутні або недійсні облікові дані автентифікації
Обов’язковий за специфікацією








403
Forbidden
Автентифікований, але не має дозволу
Відсутній








407
Proxy Auth Required
Проксі-сервер вимагає облікових даних
Заголовок `Proxy-Authenticate`








511
Network Auth Required
Captive portal (готельний Wi-Fi тощо)
Не застосовується





Помилкова ідентифікація 403 як 401 є поширеною помилкою розробників. Якщо ваш сервер повертає 401, але не включає WWW-Authenticate, він технічно не відповідає RFC 9110 — і деякі суворі HTTP-клієнти оброблятимуть відповідь як некоректну.
Першопричини помилки 401 Unauthorized
Проблеми з обліковими даними та токенами

Неправильне ім’я користувача або пароль — найпоширеніша причина для доступу через браузер
Застарілі токени доступу — Bearer-токени OAuth 2.0 мають кінцеве значення expires_in; після його закінчення кожен запит повертає 401, доки токен не буде оновлено
Відкликані API-ключі — ключі можуть бути анульовані на стороні сервера без повідомлення клієнта
Невідповідність підпису JWT — якщо секрет підпису змінюється, а клієнт має токен, підписаний старим секретом, перевірка мовчки завершується невдачею
Розбіжність годинників — JWT містять твердження iat (видано о) та exp (термін дії), які перевіряються відносно часу сервера; годинник клієнта, що відхилився більш ніж на кілька хвилин, може призвести до відхилення дійсних токенів

Відсутні або некоректні заголовки Authorization
Кожна схема автентифікації має точний формат заголовка. Відхилення від нього — навіть на один пробіл або неправильне доповнення Base64 — призводить до 401:
# Correct Basic Auth header
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# Correct Bearer token header
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Поширена помилка — надсилання Authorization: bearer <token> (рядкові b). Хоча RFC 6750 стверджує, що назва схеми нечутлива до регістру, багато серверних бібліотек виконують суворе порівняння рядків і відхиляють варіант у нижньому регістрі.
Неправильна конфігурація на стороні сервера

Застосовано неправильний метод автентифікації — сервер, налаштований для OAuth 2.0, що отримує заголовки Basic Auth, відхилить їх
Директиви .htaccess — на Apache неправильно налаштована директива AuthType, AuthName або Require у .htaccess блокуватиме кожен запит за запитом пароля
Блоки auth_basic у NGINX — директива auth_basic, застосована до неправильного блоку location, може заблокувати законних користувачів
Зворотний проксі видаляє заголовки — балансувальники навантаження та зворотні проксі (NGINX, HAProxy, Cloudflare) можуть видаляти або переписувати заголовки Authorization до того, як вони досягнуть сервера-джерела

Втручання браузера та клієнтської сторони

Пошкоджені файли cookie — сесійні файли cookie, що несуть стан автентифікації, можуть бути пошкоджені або не збігатися після анулювання сесії на стороні сервера
Агресивні розширення браузера — блокувальники реклами, розширення для конфіденційності та VPN-розширення можуть змінювати або видаляти заголовки запитів
Збої попереднього запиту CORS — у міжоригінальних API-викликах браузер надсилає попередній запит OPTIONS; якщо сервер не відповідає на нього правильно, фактичний автентифікований запит ніколи не надсилається

Фактори інфраструктури та мережі

Правила брандмауера, що блокують кінцеві точки автентифікації — WAF (брандмауери веб-застосунків) з надмірно агресивними правилами можуть позначати та відхиляти запити, що містять заголовки Authorization, як потенційні атаки ін’єкцій
CDN кешує автентифіковані відповіді — якщо CDN кешує відповідь 401 і обслуговує її наступним користувачам, навіть дійсні облікові дані здаватимуться недійсними
Обмеження швидкості на основі IP — повторні невдалі спроби автентифікації можуть спровокувати тимчасове блокування, яке повертає 401 для всіх запитів з цього IP

Як виправити помилку 401: покрокова інструкція
Для кінцевих користувачів і доступу через браузер
Крок 1: Точно перевірте облікові дані
Переконайтеся, що Caps Lock вимкнено. Підтвердьте, що ви використовуєте поточний пароль, а не збережений до недавнього скидання. Якщо ваш обліковий запис використовує багатофакторну автентифікацію (MFA), переконайтеся, що одноразовий код не закінчився (коди TOTP дійсні протягом 30 секунд за замовчуванням).
Крок 2: Очистіть файли cookie та кеш браузера
Застарілі сесійні файли cookie є постійним джерелом циклів 401. У Chrome перейдіть до chrome://settings/clearBrowserData, встановіть діапазон часу на Весь час, позначте Файли cookie та інші дані сайту та Кешовані зображення та файли, потім очистіть. У Firefox використовуйте about:preferences#privacy і натисніть Очистити дані.
Після очищення закрийте всі вкладки браузера для ураженого домену перед повторною спробою — деякі браузери зберігають стан сесії в пам’яті, який зберігається після очищення кешу, якщо вкладка залишається відкритою.
Крок 3: Перевірте у приватному/інкогніто вікні
Приватне вікно починається без файлів cookie, без кешованих даних і з більшістю вимкнених розширень. Якщо 401 зникає в режимі інкогніто, проблема однозначно на стороні клієнта: або пошкоджений файл cookie, або кешована погана відповідь, або розширення браузера.
Крок 4: Вибірково вимкніть розширення
Перейдіть до chrome://extensions/ і вимкніть усі розширення. Перезавантажте сторінку. Якщо автентифікація вдається, повторно вмикайте розширення по одному, щоб ізолювати винуватця. Privacy Badger, uMatrix і деякі VPN-розширення є частими порушниками.
Крок 5: Перевірте URL на наявність помилок
Переконайтеся, що ви не переходите до шляху, який вимагає підвищених дозволів. URL на кшталт /admin/dashboard поверне 401, якщо ваша сесія не має прав адміністратора — навіть якщо ваш базовий вхід дійсний. Перевірте точний шлях у власника сайту або в документації.
Крок 6: Скиньте пароль
Якщо підозрюється закінчення терміну дії облікових даних, скористайтеся процедурою Забули пароль. Після скидання знову очистіть файли cookie перед спробою входу — старий сесійний файл cookie може конфліктувати з новим станом облікових даних.
Для розробників та інтеграцій API
Крок 7: Перевірте необроблену HTTP-відповідь
Перш ніж щось змінювати, захопіть точну відповідь сервера за допомогою curl з детальним виводом:
curl -v -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/endpoint
Прапор -v показує як надіслані заголовки запиту, так і отримані заголовки відповіді, включаючи виклик WWW-Authenticate. Це точно вказує, яку схему очікує сервер.
Крок 8: Перевірте стан токена
Для JWT-токенів декодуйте корисне навантаження без перевірки підпису для огляду тверджень:
echo "YOUR_JWT_PAYLOAD_BASE64" | base64 --decode | python3 -m json.tool
Перевірте поле exp (мітка часу Unix). Порівняйте з поточним часом:
date +%s
Якщо exp менше поточної мітки часу, токен застарів. Реалізуйте процедуру оновлення за допомогою кінцевої точки токена вашого OAuth-провайдера до того, як токен досягне терміну дії.
Крок 9: Перевірте конфігурацію автентифікації на стороні сервера
На Apache перевірте відповідний .htaccess або конфігурацію віртуального хосту:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Підтвердьте, що шлях AuthUserFile існує і доступний для читання процесом веб-сервера. На NGINX перевірте відповідний блок сервера або розташування:
location /secure/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
Переконайтеся, що файл .htpasswd містить правильні хешовані облікові дані. Використовуйте htpasswd -v /etc/nginx/.htpasswd username для перевірки пароля відносно збереженого хешу.
Крок 10: Перевірте журнали сервера
Журнали сервера надають достовірну інформацію. На Apache:
tail -f /var/log/apache2/error.log | grep 401
На NGINX:
tail -f /var/log/nginx/error.log | grep 401
Для автентифікації на рівні застосунку (Node.js, Django, Laravel) перевірте власний вивід журналу застосунку. Запис у журналі часто вказуватиме, чи збій стався через відсутній заголовок, недійсний токен або збій пошуку в базі даних.
Крок 11: Перевірте пересилання заголовків зворотним проксі
Якщо ваш застосунок знаходиться за NGINX, що діє як зворотний проксі, переконайтеся, що заголовок Authorization пересилається до вихідного застосунку:
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Authorization $http_authorization;
    proxy_pass_header Authorization;
}
Без proxy_pass_header Authorization NGINX видаляє заголовок до того, як він досягне вашого сервера застосунку — спричиняючи 401, який виглядає як помилка клієнта, але повністю зумовлений інфраструктурою.
Крок 12: Перевірте правила WAF та брандмауера
Якщо ви використовуєте WAF (ModSecurity, Cloudflare WAF, AWS WAF), перевірте, чи якесь правило відповідає та блокує запити, що містять заголовки Authorization. Тимчасово переведіть WAF у режим лише виявлення та повторіть спробу. Якщо 401 зникає, уточніть правило-порушника, а не вимикайте WAF повністю.
Крок 13: Перевірте поведінку кешування CDN
Переконайтеся, що ваш CDN не кешує відповіді 401. У Cloudflare встановіть правило кешу для обходу кешу для автентифікованих кінцевих точок. У AWS CloudFront налаштуйте поведінку для пересилання заголовка Authorization до джерела — за замовчуванням CloudFront видаляє його, що означає, що ваше джерело ніколи не отримує облікові дані і завжди повертає 401.
Реалізація надійної автентифікації: найкращі практики для власників серверів
Якщо ви керуєте веб-застосунком або API — чи то в середовищі VPS Хостингу, чи то на Виділеному сервері — ці практики запобігають потраплянню помилок 401 до ваших користувачів.
Управління життєвим циклом токенів
Ніколи не видавайте токени без визначеного терміну дії. Для OAuth 2.0 використовуйте короткострокові токени доступу (15–60 хвилин) у поєднанні з довгостроковими токенами оновлення. Реалізуйте проактивне оновлення токенів: запускайте оновлення, коли у токена доступу залишилося менше 20% терміну дії, а не після того, як він вже закінчився.
Access Token TTL:  15 minutes
Refresh Token TTL: 30 days (rotated on each use)
Refresh trigger:   < 3 minutes remaining on access token
Для систем на основі JWT реалізуйте ротацію ключів із пільговим періодом. При ротації секрету підпису зберігайте старий секрет дійсним протягом одного додаткового терміну дії токена, щоб токени в процесі передачі не були негайно анульовані.
Змістовні відповіді про помилки
Відповідь 401 завжди повинна містити тіло, яке допомагає клієнту зрозуміти, що робити далі:
{
  "error": "invalid_token",
  "error_description": "The access token expired at 2024-01-15T10:30:00Z",
  "error_uri": "https://api.example.com/docs/authentication"
}
Розпливчасті відповіді 401, що повертають лише код стану, змушують розробників здогадуватися про причину збою, що значно збільшує навантаження на підтримку.
Журналювання автентифікації та сповіщення
Реєструйте кожен збій автентифікації з достатнім контекстом: мітка часу, IP-адреса, агент користувача, запитуваний ресурс і причина збою. Налаштуйте сповіщення про аномальні шаблони — стрибок 401 з одного IP вказує або на неправильну конфігурацію, або на атаку підбору облікових даних. Платформи, що працюють на Виділених серверах, мають повний доступ до журналів системного рівня та можуть реалізовувати власні конвеєри сповіщень без обмежень.
Безпечна передача облікових даних
Облікові дані автентифікації повинні передаватися лише через зашифровані з’єднання. Якщо ваш застосунок обробляє входи користувачів, SSL-сертифікат є обов’язковим — передача облікових даних Basic Auth через звичайний HTTP відкриває закодовані в Base64 імена користувачів і паролі у відкритому вигляді в мережі.
Обмеження та ротація API-ключів
Видавайте API-ключі з мінімально необхідною областю дії. Реалізуйте політику ротації ключів і надайте клієнтам механізм ротації, який дозволяє їм замінювати ключі без простою. Негайно відкликайте скомпрометовані ключі та повідомляйте постраждалих клієнтів через задокументований канал.
Тестування процедур автентифікації в CI/CD
Інтегруйте тести процедур автентифікації у ваш конвеєр розгортання. Набір тестів, що перевіряє дійсні облікові дані, застарілі токени, відсутні заголовки та відкликані ключі, виявить регресії до того, як вони потраплять у виробництво. Це особливо критично після оновлень залежностей, що стосуються проміжного програмного забезпечення автентифікації.
Помилки 401 у конкретних середовищах
WordPress
WordPress повертає 401 у своєму REST API (/wp-json/), коли паролі застосунків налаштовані неправильно або коли плагін безпеки (Wordfence, iThemes Security) блокує доступ до REST API. Перевірте Settings > Permalinks і збережіть знову — це очищає правила перезапису, які можуть порушити кінцеві точки автентифікації. Якщо ви керуєте WordPress на VPS з cPanel, переконайтеся, що mod_rewrite увімкнено і що .htaccess доступний для запису.
cPanel та панелі керування веб-хостингом
Захищені паролем директорії, налаштовані через cPanel, використовують mod_authn_file Apache. Якщо шлях до файлу .htpasswd у згенерованому .htaccess є абсолютним і кореневий каталог документів змінюється (поширено після міграцій облікових записів), шлях порушується і кожен запит повертає 401. Завжди використовуйте відносні шляхи або перевіряйте абсолютні шляхи після будь-якої міграції. Середовища, що використовують Панелі керування VPS, надають прямий доступ до файлової системи для виправлення цих шляхів без відкриття заявки до служби підтримки.
Поштові клієнти та автентифікація SMTP
SMTP-сервери повертають еквівалент 401 на рівні протоколу (535 Authentication credentials invalid), коли облікові дані поштового клієнта неправильні або коли сервер вимагає STARTTLS, а клієнт намагається виконати звичайну автентифікацію. Якщо ви налаштовуєте Хостинг електронної пошти, переконайтеся, що ваш поштовий клієнт налаштований з правильним методом автентифікації (PLAIN, LOGIN або CRAM-MD5) і що TLS застосовується до передачі облікових даних.
Мобільні застосунки
Мобільні застосунки часто стикаються з помилками 401 після того, як користувач змінює пароль у вебі — збережений токен оновлення застосунку анулюється на стороні сервера, але застосунок не має механізму для виявлення цього до наступного збою API-виклику. Реалізуйте глобальний HTTP-перехоплювач, який перехоплює відповіді 401, намагається оновити токен рівно один раз, і якщо оновлення також повертає 401, перенаправляє користувача на екран входу з чітким повідомленням.
Матриця рішень: діагностика помилки 401



Симптом
Найімовірніша причина
Перша дія








—
—
—








401 на всіх запитах, включаючи ті, що раніше працювали
Токен застарів або відкликаний
Перевірте твердження `exp` токена; запустіть оновлення








401 лише в браузері, але не в curl
Пошкоджений файл cookie або втручання розширення
Очистіть файли cookie; перевірте в інкогніто








401 лише з певного IP
Обмеження швидкості брандмауера або блокування IP
Перевірте журнали WAF; додайте до білого списку, якщо законний








401 після міграції сервера
Шлях `.htpasswd` порушений
Перевірте шлях `AuthUserFile` у `.htaccess`








401 на попередньому запиті OPTIONS
Неправильна конфігурація CORS
Додайте `Authorization` до `Access-Control-Allow-Headers`








401 незважаючи на правильні облікові дані
Зворотний проксі видаляє заголовки
Додайте `proxy_pass_header Authorization` до конфігурації NGINX








401 на ресурсах, кешованих CDN
CDN обслуговує кешовану відповідь 401
Обійдіть кеш для автентифікованих маршрутів








401 після оновлення залежностей
Критична зміна проміжного програмного забезпечення автентифікації
Перегляньте журнал змін; перевірте логіку розбору заголовків





Практичний контрольний список перед ескалацією помилки 401
Використовуйте цей контрольний список перед поданням заявки до служби підтримки або ескалацією до вашої команди інфраструктури:

Захоплено необроблену HTTP-відповідь за допомогою curl -v та підтверджено значення заголовка WWW-Authenticate

• Декодовано JWT або токен та перевірено твердження exp відносно поточного часу сервера
• Підтверджено, що формат заголовка Authorization відповідає схемі, яку рекламує сервер
• Перевірено у вікні інкогніто з усіма вимкненими розширеннями
• Очищено всі файли cookie та кеш для ураженого домену
• Перевірено журнали помилок сервера на наявність конкретної причини відхилення
• Перевірено, що конфігурація зворотного проксі пересилає заголовок Authorization
• Підтверджено, що CDN не кешує відповідь 401
• Перевірено правила WAF на наявність хибнопозитивних збігів із заголовком Authorization
• Перевірено, що SSL/TLS активний на кінцевій точці — облікові дані ніколи не повинні передаватися у незашифрованому вигляді

FAQ

У чому різниця між HTTP 401 та HTTP 403?

401 означає, що сервер не може ідентифікувати, хто ви — автентифікація відсутня або недійсна. 403 означає, що сервер знає, хто ви, але вирішив, що у вас немає дозволу на доступ до ресурсу. Виправте 401, надавши або виправивши облікові дані; виправте 403, налаштувавши правила контролю доступу або дозволи.

Чому мій API повертає 401, навіть коли я надсилаю правильний токен?

Найпоширеніші причини — закінчення терміну дії токена (перевірте твердження exp), розбіжність годинників між клієнтом і сервером (синхронізуйте NTP), ротований секрет підпису, що анулює існуючі токени, або заголовок Authorization, що видаляється зворотним проксі або CDN до досягнення сервера-джерела.

Чи може помилка 401 бути спричинена неправильною конфігурацією сервера, а не помилкою клієнта?

Так. Неправильно налаштований файл .htaccess, блок auth_basic NGINX, застосований до неправильного розташування, зворотний проксі, що видаляє заголовок Authorization, або правило WAF, що блокує автентифіковані запити, — все це може генерувати відповіді 401, навіть коли клієнт надсилає абсолютно дійсні облікові дані.

Як запобігти помилкам 401, спричиненим закінченням терміну дії токена, у виробничому застосунку?

Реалізуйте проактивне оновлення токенів — відстежуйте залишковий термін дії токена та оновлюйте його до закінчення терміну, а не після. Для OAuth 2.0 використовуйте кінцеву точку токена оновлення для отримання нового токена доступу, коли у поточного залишилося менше 20% TTL. Додайте глобальний перехоплювач HTTP-відповідей, який автоматично обробляє відповіді 401, намагаючись одноразово оновити токен перед повторною спробою оригінального запиту.

Чи завжди очищення файлів cookie виправляє помилку 401 у браузері?

Лише якщо першопричиною є пошкоджений або застарілий сесійний файл cookie. Якщо 401 спричинений неправильною конфігурацією сервера, застарілим API-ключем або блокуванням брандмауером, очищення файлів cookie не матиме жодного ефекту. Використовуйте вікно інкогніто як діагностичний крок — якщо 401 зберігається в інкогніто, проблема на стороні сервера або мережі, а не браузера.