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 vs. 403 vs. 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 до того, как они достигнут исходного сервера

Вмешательство браузера и клиентской стороны

Повреждённые cookies — сессионные cookies, несущие состояние аутентификации, могут быть повреждены или рассинхронизированы после аннулирования серверной сессии
Агрессивные расширения браузера — блокировщики рекламы, расширения для защиты конфиденциальности и VPN-расширения могут изменять или удалять заголовки запросов
Сбои предварительного запроса CORS — при кросс-доменных API-вызовах браузер отправляет предварительный запрос OPTIONS; если сервер не отвечает на него корректно, фактический аутентифицированный запрос никогда не отправляется

Инфраструктурные и сетевые факторы

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

Как исправить ошибку 401: пошаговое руководство
Для конечных пользователей и доступа через браузер
Шаг 1: Точно проверьте учётные данные
Убедитесь, что Caps Lock выключен. Подтвердите, что используете текущий пароль, а не сохранённый до недавнего сброса. Если ваша учётная запись использует многофакторную аутентификацию (MFA), убедитесь, что одноразовый код не истёк (коды TOTP действительны 30 секунд по умолчанию).
Шаг 2: Очистите cookies и кэш браузера
Устаревшие сессионные cookies — постоянный источник циклов 401. В Chrome перейдите в chrome://settings/clearBrowserData, установите временной диапазон За всё время, отметьте Файлы cookie и другие данные сайтов и Кэшированные изображения и файлы, затем очистите. В Firefox используйте about:preferences#privacy и нажмите Удалить данные.
После очистки закройте все вкладки браузера для затронутого домена перед повторной попыткой — некоторые браузеры сохраняют состояние сессии в памяти, которое переживает очистку кэша, если вкладка остаётся открытой.
Шаг 3: Проверьте в приватном/инкогнито окне
Приватное окно запускается без cookies, без кэшированных данных и с отключёнными большинством расширений. Если ошибка 401 исчезает в режиме инкогнито, проблема однозначно на стороне клиента: либо повреждённый cookie, либо кэшированный плохой ответ, либо расширение браузера.
Шаг 4: Выборочно отключите расширения
Перейдите в chrome://extensions/ и отключите все расширения. Перезагрузите страницу. Если аутентификация прошла успешно, включайте расширения по одному, чтобы выявить виновника. Privacy Badger, uMatrix и некоторые VPN-расширения являются частыми нарушителями.
Шаг 5: Проверьте URL на наличие ошибок
Убедитесь, что вы не переходите по пути, требующему повышенных прав. URL вида /admin/dashboard вернёт 401, если ваша сессия не имеет прав администратора — даже если базовый вход выполнен. Уточните точный путь у владельца сайта или в документации.
Шаг 6: Сбросьте пароль
Если подозревается истечение срока действия учётных данных, воспользуйтесь функцией Забыли пароль. После сброса снова очистите cookies перед попыткой входа — старый сессионный 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:
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-адрес, user agent, запрошенный ресурс и причина сбоя. Настройте оповещения для аномальных паттернов — всплеск ошибок 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 или вмешательство расширения
Очистите cookies; проверьте в инкогнито








401 только с определённого IP
Ограничение частоты WAF или блокировка 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 соответствует схеме, объявленной сервером
• Проверено в окне инкогнито с отключёнными всеми расширениями
• Очищены все cookies и кэш для затронутого домена
• Проверены журналы ошибок сервера на предмет конкретной причины отклонения
• Подтверждено, что конфигурация обратного прокси пересылает заголовок 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, применённый к неправильному location, обратный прокси, удаляющий заголовок Authorization, или правило WAF, блокирующее аутентифицированные запросы, — всё это может приводить к ответам 401, даже когда клиент отправляет совершенно действительные учётные данные.

Как предотвратить ошибки 401, вызванные истечением срока действия токена, в продакшн-приложении?

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

Всегда ли очистка cookies исправляет ошибку 401 в браузере?

Только если первопричиной является повреждённый или устаревший сессионный cookie. Если 401 вызван неправильной конфигурацией сервера, истёкшим API-ключом или блокировкой брандмауэра, очистка cookies не даст никакого эффекта. Используйте окно инкогнито как диагностический шаг — если 401 сохраняется в инкогнито, проблема на стороне сервера или сети, а не браузера.