401 Unauthorized — Access denied due to invalid credentials
#401 и 403: в чём разница
Код 401 говорит: «Я не знаю, кто вы, представьтесь» — сервер не получил учётных данных или они недействительны. Код 403 говорит: «Я знаю, кто вы, но доступа у вас нет». Поэтому при 401 нужно проверить логин, пароль или токен, а при 403 — права. Вместе с 401 сервер обязан присылать заголовок WWW-Authenticate с указанием схемы (Basic, Bearer).
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Заголовок Authorization теряетсяApache + PHP-FPM/FastCGI не передаёт заголовок в приложение. | Базовая аутентификация работает в curl, но не в приложении. | Добавьте в .htaccess: RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]. |
| Прокси или CDN удаляет заголовокПравила кэширования. | Запрос доходит без Authorization. | Исключите запросы с авторизацией из кэша. |
| Токен просроченВремя жизни истекло. | 401 после определённого времени. | Обновите токен (refresh token) или войдите снова. |
| Смена пароля или отзыв ключаДанные недействительны. | Все запросы получают 401. | Получите новые учётные данные. |
| Файл .htpasswd недоступенНет прав или неверный путь. | Все пользователи получают 401, в журнале ошибка. | Проверьте путь и права на чтение для пользователя веб-сервера. |
#Если вы посетитель сайта
- Проверьте логин и парольАдминистратору: найдите в журнале доступа и ошибок веб-сервера запись, соответствующую точному времени и URL сбоя. На системах с systemd можно начать с
sudo journalctl -u nginx --since "15 minutes ago"(если nginx работает как служба); для файловых логов используйте путь, указанный в конфигурацииaccess_log/error_log. Ищите сообщения подключения к upstream, тайм-ауты и отказ приложения; не меняйте лимиты без подтверждённой причины. Посетителю достаточно записать код и время и обратиться к владельцу. - Откройте страницу в режиме инкогнитоДля диагностики ошибки 401 откройте приватное окно Chrome/Edge (
Ctrl+Shift+N) или Firefox (Ctrl+Shift+P), введите тот же URL и войдите в сервис заново через его официальную страницу. Если доступ появился, вероятно, в обычном профиле устарели cookie авторизации; очистите cookie только этого сайта в настройках браузера. Если 401 остаётся, проверьте данные учётной записи и её права; не отправляйте логин или токен посторонним. - Выйдите и войдите сноваЕсли сайт показывает HTTP 401 после длительной сессии, откройте меню своей учётной записи и выберите «Выйти», затем войдите заново с официальной страницы входа. Не вводите пароль в неожиданном всплывающем окне без проверки адреса. Если 401 возвращается, проверьте, имеет ли аккаунт право на этот ресурс; повторные попытки с неправильным паролем могут вызвать временную блокировку.
- Отключите расширения менеджеров паролейОткройте адрес
chrome://extensionsв браузере. Временно выключите расширения, обновите проблемную страницу и проверьте результат. Если ошибка исчезла, включайте расширения по одному, чтобы найти конфликт. Не удаляйте расширения, пока не убедились, что они не нужны. - Проверьте дату и времяОткройте «Параметры» → «Время и язык» → «Дата и время». Включите автоматическую установку времени и проверьте часовой пояс; затем нажмите «Синхронизировать» (если кнопка есть). Повторите действие, вызвавшее ошибку.
#Если вы разработчик (API и приложения)
Воспроизведите запрос в curl и посмотрите заголовки:
curl -v https://api.example.com/v1/mecurl -i -u user https://example.com/protected/curl -v https://api.example.com/v1/me -H "Authorization: Bearer ВАШ_ТОКЕН"Типичные ошибки: токен просрочен (поле exp), используется токен от другого окружения (тестового вместо боевого), заголовок записан как Authorisation, пропущено слово Bearer, токен содержит перевод строки или кавычки. Если часы сервера и клиента расходятся больше чем на пару минут, проверка срока может не пройти.
#Если вы владелец сайта с защитой паролем
sudo apt install apache2-utilssudo htpasswd /etc/nginx/.htpasswd adminКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
location /admin/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}#Особенности Apache, WordPress и браузерных ошибок
В Apache при работе PHP через FastCGI заголовок Authorization по умолчанию не попадает в приложение, и REST API WordPress с Application Passwords отвечает 401, хотя пароль верный: добавьте в .htaccess перед правилами WordPress строку SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1. Если окно запроса логина и пароля появляется в браузере снова и снова, значит сервер отклоняет введённые данные: проверьте, что файл .htpasswd читается пользователем веб-сервера и что хеш создан поддерживаемым алгоритмом (bcrypt поддерживается в Apache 2.4, MD5-apr1 — везде). Для встроенной проверки токена посмотрите в журнале приложения причину отказа: срок, подпись или аудитория (aud), они указаны в сообщении библиотеки JWT.