Ошибка 401 Unauthorized: что это значит и как исправить

Ошибка 401 (401 Unauthorized) означает, что сервер не смог установить, кто вы: запрос пришёл без учётных данных, с неверным логином, паролем или ключом, либо с истёкшим токеном или сессией. Сайт при этом работает. Обычно помогает войти заново или обновить токен, а сервер в ответе подсказывает нужный способ входа заголовком WWW-Authenticate.

Ниже — отдельно, что делать пользователю, который увидел код ошибки 401 на сайте или в приложении, и как разработчику или владельцу сайта найти причину: по заголовкам ответа, логам nginx и Apache, содержимому токена. Разберём формулировку стандарта, схемы Basic, Bearer и Digest, ошибку 401 в API и отличие 401 от 403.

Что значит ошибка 401 Unauthorized

Код 401 Unauthorized относится к клиентским ошибкам 4xx. Согласно RFC 9110, §15.5.2, он означает, что «запрос не был применён, потому что ему не хватает валидных учётных данных аутентификации для целевого ресурса». Название вводит в заблуждение: несмотря на слово «Unauthorized» (неавторизован), речь идёт именно об аутентификации — то есть о том, что сервер не смог установить вашу личность.

Стандарт требует: ответ 401 обязан содержать заголовок WWW-Authenticate хотя бы с одним challenge, применимым к ресурсу. Этот заголовок сообщает клиенту, какую схему аутентификации использовать. Если запрос уже содержал учётные данные, 401 означает, что сервер их отверг, — повторять тот же запрос без изменений бессмысленно.

Ошибка аутентификации и ошибка авторизации: в чём разница

Эти слова в интерфейсах часто смешивают, поэтому сообщение «ошибка авторизации» может скрывать и 401, и 403. Аутентификация — проверка, кто вы: логин и пароль, токен, ключ API, сертификат. Авторизация — проверка, что вам можно: есть ли у установленного пользователя права на действие или раздел. Что значит ошибка аутентификации на практике: сервер не принял то, чем вы представились, и ответил 401. Если же вас узнали, но прав не хватает, правильный ответ — 403 Forbidden.

Как выглядит ответ 401

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"
Content-Type: application/json

{ "error": "token_expired" }

Как ошибка 401 выглядит в браузере и программах

Текст зависит от сервера и клиента, но код один и тот же:

• nginx: страница «401 Authorization Required» со строкой «nginx» под ней.
• Apache: «Unauthorized. This server could not verify that you are authorized to access the document requested.»
• IIS: «401 — Unauthorized: Access is denied due to invalid credentials.»
• Браузер при Basic-аутентификации: сначала всплывающее окно с полями логина и пароля; если нажать «Отмена», браузер покажет страницу 401.
• JavaScript-клиенты: axios выбрасывает «Request failed with status code 401», у fetch — response.status === 401 и response.ok === false.
• Приложения и учётные системы: «Ошибка HTTP-запроса, код 401», «Ошибка входа 401», «Сессия истекла, войдите снова».

Ошибка 401 при входе на сайт: что делать пользователю

Если вы не разработчик и просто не можете войти, пройдите шаги по порядку — большинство случаев закрываются на первых трёх.

1. Проверьте логин и пароль. Раскладка клавиатуры, Caps Lock, лишний пробел в начале или конце при вставке из буфера. Если пароль недавно меняли, старый мог сохраниться в менеджере паролей браузера.
2. Выйдите и войдите заново. Истёкшая сессия — самая частая причина ошибки 401 у залогиненного пользователя. Обычная перезагрузка страницы её не обновит.
3. Очистите cookies этого сайта. В Chrome и Яндекс Браузере нажмите на значок слева от адреса → «Файлы cookie и данные сайтов» → удалите данные сайта. Общий диалог очистки открывается сочетанием Ctrl+Shift+Delete (на macOS — Cmd+Shift+Delete). Повреждённая или устаревшая cookie сессии даёт 401 даже при верном пароле.
4. Проверьте дату и время на устройстве. Токены и одноразовые коды двухфакторной аутентификации привязаны ко времени. Если часы отстают или спешат на несколько минут, сервер считает токен просроченным или «ещё не действующим». Включите автоматическую синхронизацию времени.
5. Откройте сайт в режиме инкогнито (Ctrl+Shift+N в Chrome). Если там вход работает, мешают расширения браузера или сохранённые данные.
6. Проверьте адрес. Старая закладка может вести на служебный раздел, закрытый паролем (например, /admin/ или тестовую копию сайта), — там 401 штатный ответ.
7. Если ничего не помогло — скорее всего, учётная запись заблокирована, пароль сброшен администратором или проблема на стороне сервиса. Напишите в поддержку и укажите время ошибки и точный текст сообщения.

Ошибка 401 в приложениях и сервисах: 1С, Контур, электронный дневник, Меркурий

В учётных и отраслевых сервисах ошибка 401 чаще всего означает одно из трёх: истекла сессия, изменился пароль или токен доступа, приложение хранит старые данные входа. Что делать: выйти из учётной записи и войти заново, обновить приложение, проверить время на устройстве, при необходимости удалить сохранённые данные приложения. В электронном дневнике (NetSchool / «Сетевой город») и в сервисах Контура ошибка нередко появляется после смены пароля или долгого простоя вкладки. Если ошибка 401 возникает сразу у всех пользователей организации, проблема на стороне сервиса — это вопрос в его техподдержку, а не к вашему компьютеру.

В 1С «ошибка HTTP-запроса» с кодом 401 обычно возникает при обращении к опубликованному HTTP-сервису или веб-сервису: в параметрах подключения не указаны или указаны неверно имя и пароль пользователя информационной базы, такого пользователя в базе нет либо на веб-сервере включена своя аутентификация, которую запрос не проходит. Учётные данные передаются в параметрах Пользователь и Пароль конструктора Новый HTTPСоединение(...) — проверьте их в первую очередь. Ошибка 401 на игровых консолях вроде Nintendo Switch — это внутренний код платформы, а не HTTP-ответ сайта, и к этой статье не относится.

401 vs 403: в чём разница

Эти два кода путают чаще всего. Кратко: 401 — «я не знаю, кто ты» (проблема аутентификации), 403 — «я знаю, кто ты, но тебе сюда нельзя» (проблема авторизации). Таблица ниже раскрывает различия.

Коды, которые путают с 401

Роль заголовков WWW-Authenticate и Authorization

Аутентификация в HTTP — это диалог двух заголовков. Сначала сервер отвечает 401 с WWW-Authenticate (challenge — «представься так-то»). Затем клиент повторяет запрос с заголовком Authorization, где передаёт учётные данные в нужной схеме.

GET /api/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Если Authorization отсутствует, неверен или токен в нём истёк, сервер снова возвращает 401. Сайты с входом через форму и cookie обычно не отправляют WWW-Authenticate вовсе, а при потере сессии перенаправляют на страницу входа (302) — поэтому «чистый» 401 чаще встречается в API и на разделах, закрытых Basic-аутентификацией.

Схемы аутентификации: Basic, Bearer, Digest

Заголовок WWW-Authenticate указывает схему. Три самые распространённые:

• Basic — логин и пароль, закодированные в Base64 (только по HTTPS!). Authorization: Basic dXNlcjpwYXNz
• Bearer — токен доступа (обычно JWT или OAuth 2.0). Authorization: Bearer <token>
• Digest — хеш-ответ на challenge сервера, не передаёт пароль в открытом виде.

Пример Basic-аутентификации

curl -v https://example.com/private \
  -H "Authorization: Basic dXNlcjpwYXNzd29yZA=="

# то же самое, curl закодирует сам:
curl -v -u user:password https://example.com/private

Строка dXNlcjpwYXNzd29yZA== — это всего лишь user:password, закодированные в Base64. Декодировать её тривиально, поэтому Basic без HTTPS фактически передаёт пароль открытым текстом. Схема Bearer лишена этого недостатка: токен можно сделать короткоживущим и отозвать в любой момент, не меняя пароль пользователя. Именно поэтому современные API почти всегда используют Bearer, а Basic оставляют для внутренних сервисов и служебных эндпоинтов за HTTPS.

Коды ошибок Bearer: invalid_token и соседи

Для схемы Bearer RFC 6750 определяет поле error в challenge и три значения: invalid_request (запрос сформирован неверно, ответ 400), invalid_token (токен истёк, отозван, повреждён или подписан не тем ключом, ответ 401) и insufficient_scope (у токена нет нужных прав, ответ 403). Поле error_description часто содержит точную причину, например «The access token expired», — прочитайте его, прежде чем гадать.

Ошибка 401 в API: «Request failed with status code 401»

Когда ошибка 401 приходит на запрос к API, причина почти всегда в том, что сервер получил не тот заголовок Authorization, который вы собирались отправить, или не получил его вовсе. Сначала посмотрите на фактический запрос и ответ:

# Linux / macOS
curl -i -H "Authorization: Bearer $TOKEN" https://api.example.com/v1/me

# PowerShell 7
Invoke-WebRequest -Uri https://api.example.com/v1/me `
  -Headers @{ Authorization = "Bearer $token" } -SkipHttpErrorCheck

Ключ -i у curl выводит заголовки ответа, в том числе WWW-Authenticate; -v дополнительно покажет, что ушло в запросе. В Windows PowerShell 5.1 параметра -SkipHttpErrorCheck нет: ответ 401 там превращается в исключение, и код читается через $_.Exception.Response.StatusCode в блоке catch.

Частые причины 401 в API, которые не видны при беглом взгляде на код:

• Неверный формат заголовка. Пропущено слово Bearer, стоит Token или JWT вместо схемы, которую ждёт сервер, в токен попали кавычки, пробел или перевод строки из файла с переменными окружения.
• Ключ передан не туда. Одни API ждут ключ в Authorization, другие — в собственном заголовке вроде X-API-Key. Сверьтесь с документацией конкретного сервиса.
• Заголовок срезается по пути. Apache, передающий запрос в PHP через FastCGI/CGI, по умолчанию не пробрасывает Authorization в скрипт — приложение видит запрос без учётных данных. Лечится директивой CGIPassAuth On (Apache 2.4.13+) в конфигурации или .htaccess.
• Редирект на другой хост. curl при -L не отправляет учётные данные на другой хост после редиректа (для этого нужен --location-trusted), браузеры тоже убирают Authorization при переходе на другой домен. Если API отвечает 301 на адрес без слеша или с http на https, запрос доходит без токена.
• Preflight-запрос CORS. Браузер перед запросом с Authorization отправляет OPTIONS без учётных данных. Если сервер требует токен и на OPTIONS, он отвечает 401, а в консоли вы увидите ошибку CORS.
• Токен из другого окружения. Ключ от тестового стенда не работает в боевом API и наоборот.

Как проверить, не истёк ли JWT-токен

У JWT срок жизни записан в поле exp полезной нагрузки (Unix-время в секундах). Декодировать токен можно локально, не отправляя его на сторонние сайты:

python3 -c "import sys,base64,json;p=sys.argv[1].split('.')[1];print(json.loads(base64.urlsafe_b64decode(p+'='*(-len(p)%4))))" "$TOKEN"

# текущее Unix-время для сравнения с exp
date +%s

Если exp меньше текущего времени — токен истёк, нужно обновление. Если токен свежий, а сервер всё равно пишет invalid_token, проверьте поля aud и iss (токен мог быть выпущен для другого сервиса) и время на сервере: timedatectl в Linux, w32tm /query /status в Windows. Подробно о структуре токена — в статье JWT-токен: что это и как проверить.

Причины ошибки 401 и как исправить

Причины делятся на клиентские и серверные.

• Истёкший токен или сессия — самая частая причина у API. Решение: обновить access-токен через refresh-токен или войти заново.
• Неверные учётные данные — опечатка в логине/пароле, неправильный API-ключ. Решение: перепроверить креды.
• Отсутствует заголовок Authorization — клиент вовсе не отправил учётные данные. Решение: добавить заголовок.
• Неверная схема — сервер ждёт Bearer, а клиент шлёт Basic. Решение: сверить с WWW-Authenticate.
• Серверная настройка — например, включён auth_basic в nginx или требуется API-ключ.

Ошибка сервера 401: что проверить владельцу сайта

Если 401 получают посетители вашего сайта, начните с вопроса, должен ли этот адрес вообще требовать вход. Нередко пароль остаётся на разделе после работ на тестовой копии или закрывает больше, чем задумывалось.

Серверная настройка Basic Auth в nginx

location /admin/ {
    auth_basic           "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

При такой конфигурации любой запрос к /admin/ без корректного заголовка Authorization получит 401 и challenge Basic. Файл паролей создаётся утилитой htpasswd из пакета apache2-utils (Debian/Ubuntu) или httpd-tools (RHEL/AlmaLinux):

sudo htpasswd -c /etc/nginx/.htpasswd admin   # -c только при создании файла
sudo nginx -t && sudo systemctl reload nginx

В Apache тот же эффект даёт блок в конфигурации или .htaccess:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Где искать причину в логах

В журнале доступа видно, какие адреса отдают 401 и кому: grep ' 401 ' /var/log/nginx/access.log | tail -n 20. Причину отказа пишет журнал ошибок. В nginx это строки вида user "admin": password mismatch (неверный пароль), user "admin" was not found in "/etc/nginx/.htpasswd" (нет такого пользователя) и no user/password was provided for basic authentication (браузер не прислал данные). В Apache — AH01617: user admin: authentication failure for "/admin/": Password Mismatch и AH01618: user admin not found. Где лежат логи и как их читать — в разборе логов nginx.

Побочные эффекты пароля на сайте

• Поисковые роботы получают 401 так же, как посетители, и не индексируют закрытые страницы. Для тестовой копии сайта это правильно, для боевых разделов — потеря трафика.
• Выпуск сертификата Let's Encrypt по HTTP-проверке ломается, если паролем закрыт весь сайт вместе с /.well-known/acme-challenge/. Исключите этот путь из-под auth_basic директивой auth_basic off; в отдельном location.
• Мониторинг доступности увидит 401 и поднимет тревогу. Либо передавайте в проверке заголовок Authorization, либо настройте проверку на ожидаемый код 401 — тогда она подтвердит, что защита на месте.

Токены и сессии: почему 401 возникает у залогиненных пользователей

Парадокс «я вошёл, но получаю 401» объясняется жизненным циклом токенов. В современных API access-токен намеренно живёт недолго — от нескольких минут до часа. Это ограничивает ущерб, если токен утечёт. Когда срок истекает, сервер отвечает 401, и клиент должен обменять долгоживущий refresh-токен на новый access-токен.

POST /oauth/token HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=def502...&client_id=app

Грамотный клиент перехватывает первый 401, автоматически обновляет токен и повторяет исходный запрос — пользователь даже не замечает паузы. Если этой логики нет, пользователь видит внезапный выход из системы. Поэтому обработка 401 — обязательная часть любого API-клиента. Важно повторять запрос только один раз: если после обновления токена снова пришёл 401, значит, отозван сам refresh-токен и нужен полноценный вход, иначе клиент уйдёт в бесконечный цикл обновлений.

Типичные серверные причины 401 в API

• Ротация ключей — старый API-ключ отозван, приложение всё ещё шлёт его.
• Рассинхрон часов — JWT с полем exp считается истёкшим из-за неверного времени на сервере.
• Неверный realm или audience — токен выдан для другого сервиса.
• Отозванная сессия — администратор принудительно завершил сессию пользователя.

Как проверить заголовки и аутентификацию

Чтобы увидеть код ответа и заголовок WWW-Authenticate, воспользуйтесь бесплатной проверкой HTTP-заголовков и кода ответа на enterno.io — она сразу покажет статус и все заголовки ответа. А чтобы оценить общую защищённость эндпоинта и корректность схем аутентификации, пригодится сканер безопасности. Проверка заголовков ответа особенно полезна, когда нужно понять, какую именно схему (Basic, Bearer, Digest) ждёт сервер, — эта информация всегда содержится в challenge заголовка WWW-Authenticate.

Если закрытый паролем раздел или API важен для работы, поставьте его на мониторинг доступности с ожидаемым кодом: так вы узнаете и о падении сервиса, и о том, что защиту случайно сняли и адрес начал отвечать 200 без пароля.

Как правильно проектировать 401 в своём API

Если вы разрабатываете API, корректная реализация 401 повышает и безопасность, и удобство для клиентов. Придерживайтесь нескольких правил.

• Всегда возвращайте WWW-Authenticate с указанием схемы и, по возможности, поля error (например, invalid_token) и пояснения в error_description — так клиент поймёт, обновить токен или запросить логин заново.
• Не раскрывайте лишнего. Тело ответа не должно подсказывать, существует ли пользователь: одинаковый ответ на «неверный пароль» и «нет такого логина» защищает от перебора учётных записей.
• Разделяйте 401 и 403. Возвращайте 401 только при проблеме аутентификации, а 403 — когда личность установлена, но прав не хватает. Смешение кодов путает клиентов и усложняет отладку.
• Ставьте короткий срок жизни access-токенам и поддерживайте механизм refresh-токенов, чтобы истечение не выбрасывало пользователя из сессии внезапно.
• Не требуйте токен на OPTIONS, если API вызывается из браузера: preflight-запрос CORS учётных данных не несёт.
• Ограничьте частоту неудачных попыток входа по IP и учётной записи: 401 — именно тот ответ, который видит подбирающий пароли бот.

Соблюдение этих принципов делает поведение вашего API предсказуемым: клиенты смогут автоматически обрабатывать 401, не гадая, что именно пошло не так.

Связанные материалы

Разобраться в кодах ответа помогут справочник HTTP-кодов и разбор ошибки 403 Forbidden — их часто путают с 401. Полезно также понимать работу HTTP-заголовков, ведь именно они несут учётные данные.

Частые вопросы

Что значит ошибка 401 простыми словами?

Сервер не узнал вас. Вы не вошли в аккаунт, ввели неверный пароль или ваш вход (сессия, токен) устарел. Сайт при этом исправен — нужно войти заново или обновить учётные данные.

Чем 401 отличается от 403?

401 Unauthorized означает провал аутентификации: сервер не установил вашу личность из-за отсутствующих, неверных или истёкших учётных данных. 403 Forbidden означает провал авторизации: сервер знает, кто вы, но у вас недостаточно прав. При 401 помогает повторный вход, при 403 — только расширение прав администратором.

Почему я получаю 401, хотя точно вошёл в систему?

Скорее всего, истёк ваш access-токен или серверная сессия. Токены доступа живут недолго (минуты), и после истечения сервер отвечает 401. Обновите токен через refresh-токен или войдите заново. Также проверьте, что заголовок Authorization действительно отправляется и содержит актуальное значение, и что время на устройстве выставлено верно.

Обязателен ли заголовок WWW-Authenticate при ответе 401?

Да. По RFC 9110 сервер, возвращающий 401, обязан включить заголовок WWW-Authenticate минимум с одним challenge, применимым к ресурсу. Он сообщает клиенту, какую схему аутентификации использовать — Basic, Bearer, Digest и т. д. Отсутствие этого заголовка при 401 — нарушение стандарта.

Как исправить 401 при обращении к API?

Проверьте по порядку: отправляется ли заголовок Authorization, верна ли схема (Bearer против Basic), не истёк ли токен и корректен ли API-ключ. Прогоните запрос через curl -v, чтобы увидеть отправленные заголовки и ответ сервера, включая WWW-Authenticate с описанием ошибки. Если заголовок уходит, но сервер его не видит, ищите прокси или редирект, который его срезает.

Безопасна ли Basic-аутентификация?

Basic передаёт логин и пароль всего лишь закодированными в Base64 — это не шифрование, а обратимое кодирование. Использовать её допустимо только поверх HTTPS, где весь трафик зашифрован TLS. Без HTTPS учётные данные фактически передаются в открытом виде. Для API предпочтительнее схема Bearer с короткоживущими токенами.