Ошибка HTTP 401 Unauthorized: Что Означает и Как Исправить

Что такое ошибка 401 Unauthorized?

Ошибка 401 Unauthorized — это код состояния HTTP, который означает, что сервер требует аутентификации для запрашиваемого ресурса, но запрос либо не содержал учётных данных, либо предоставленные учётные данные оказались недействительными.

Спецификация HTTP (RFC 9110, раздел 15.5.2) определяет её так: запрос не содержит действительных учётных данных для аутентификации на целевом ресурсе. Сервер, генерирующий ответ 401, должен включить заголовок WWW-Authenticate, указывающий, какую схему аутентификации следует использовать.

Простыми словами: сервер спрашивает «кто вы?» перед тем, как разрешить доступ. Вы либо не предоставили никаких данных для идентификации, либо предоставленные данные оказались неверными.

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

Ошибка 401 отображается по-разному в зависимости от сервера, браузера и приложения. Вот наиболее распространённые сообщения, с которыми вы можете столкнуться.

• 401 Unauthorized — стандартное сообщение HTTP-ответа

• HTTP Error 401 – Unauthorized — часто встречается в приложениях IIS и ASP.NET

• 401 Authorization Required — страница ошибки Nginx по умолчанию

• Error 401 — краткая форма в адресной строке браузера

• Access Denied: Invalid credentials — пользовательские страницы ошибок приложений

• Authentication Required — всплывающее окно браузера для аутентификации Basic/Digest

• Invalid API Key — часто встречается в ответах REST API

• Token Expired — токен JWT или OAuth требует обновления

Когда сервер отправляет ответ 401, большинство браузеров отображают всплывающее окно входа с запросом имени пользователя и пароля. Если сервер использует аутентификацию на основе токенов (как в случае с API), вы увидите ошибку в теле JSON-ответа.

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

Коды состояния 401 и 403 часто путают, даже опытные разработчики. Различие простое: 401 означает «я не знаю, кто вы», а 403 означает «я знаю, кто вы, но вам не разрешено».

Практическое правило: если предоставление правильного имени пользователя и пароля (или API-ключа) решит проблему, сервер должен возвращать 401. Если пользователь уже аутентифицирован, но просто не имеет доступа к данному ресурсу, сервер должен возвращать 403 Forbidden.

Распространённые причины ошибки 401

Понимание причин возникновения ошибки 401 зависит от того, являетесь ли вы обычным пользователем, разработчиком, вызывающим API, или администратором сервера. Вот наиболее частые причины.

• Неверное имя пользователя или пароль — самая базовая причина, особенно после сброса пароля

• Истёкший токен аутентификации — токены JWT, токены доступа OAuth и сессионные cookie имеют срок действия

• Отсутствие заголовка Authorization — запрос вообще не содержал учётных данных

• Недействительный API-ключ — ключ был отозван, заменён или скопирован неправильно

• Неверная схема аутентификации — сервер ожидает Bearer-токен, но получил Basic-аутентификацию, или наоборот

• Расхождение часов (clock skew) — валидация JWT не проходит, когда часы сервера и клиента расходятся более чем на несколько минут

• CORS preflight удаляет заголовки — браузер удаляет заголовок Authorization из предварительного запроса OPTIONS

• Устаревший кеш браузера — браузер отправляет кешированный, истёкший сессионный cookie вместо запроса нового

• Неверная конфигурация обратного прокси — Nginx или Apache удаляет заголовок Authorization перед передачей запроса на бэкенд

• Заблокированные или отозванные учётные данные — слишком много неудачных попыток привело к блокировке аккаунта

Как исправить ошибку 401 для посетителя

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

1. Проверьте данные для входа

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

Типичные ошибки: включён Caps Lock, вы используете старый пароль (особенно после недавнего сброса) или вы входите не в тот аккаунт. Если у вас есть менеджер паролей, позвольте ему автоматически заполнить учётные данные, чтобы избежать опечаток.

2. Очистите кеш и cookie браузера

Ваш браузер может отправлять истёкший сессионный cookie или кешированный токен аутентификации. Очистка этих данных заставит браузер запросить свежие учётные данные у сервера.

Chrome:  Settings → Privacy → Clear browsing data → Cookies + Cached images
Firefox: Settings → Privacy → Clear Data → Cookies + Cache
Safari:  Settings → Privacy → Manage Website Data → Remove All
Edge:    Settings → Privacy → Clear browsing data → Cookies + Cache

После очистки полностью закройте браузер (а не только вкладку), откройте его заново и перейдите на страницу. Вы должны увидеть новое окно входа.

3. Попробуйте режим инкогнито

Откройте URL в окне инкогнито (Chrome) или приватном окне (Firefox/Safari). Это позволяет обойти все кешированные cookie, расширения и сохранённые учётные данные.

Если страница работает в режиме инкогнито, но не в обычном браузере, проблема в кешированном cookie или расширении браузера, которое мешает аутентификации. Отключайте расширения по одному, чтобы найти причину.

4. Проверьте URL-адрес

Убедитесь, что вы посещаете правильный URL. Некоторые серверы возвращают 401 для путей, требующих аутентификации, даже если сам путь неверный. Возможно, вы пытаетесь получить доступ к закрытой области, которую не должны были посещать.

Проверьте, существует ли публичная версия страницы по другому URL. Например, example.com/admin/ может возвращать 401, тогда как example.com/ доступен публично.

Как исправить ошибку 401 для разработчика

Для разработчиков, работающих с API, ошибки 401 обычно связаны с заголовком Authorization, форматом токена или жизненным циклом учётных данных. Вот наиболее частые решения.

5. Проверьте заголовок Authorization

Самая распространённая ошибка разработчика — неправильно сформированный заголовок Authorization. Заголовок WWW-Authenticate в ответе сервера указывает, какую именно схему он ожидает.

Убедитесь, что ваш заголовок соответствует требуемому формату. Наиболее распространённые схемы — Bearer (для токенов) и Basic (для имени пользователя и пароля в кодировке Base64).

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← WRONG
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Всегда проверяйте заголовок WWW-Authenticate в ответе 401. Он точно сообщает, что ожидает сервер. Используйте HTTP Headers tool DNS Robot для просмотра полного ответа.

6. Проверьте действительность API-ключа

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

Убедитесь, что ваш ключ всё ещё активен в панели управления провайдера. Многие API (Google, AWS, Stripe) позволяют проверить ключ прямо из их консоли.

# Test if your API key is valid
curl -I -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = key is valid
# 401 = key is invalid or expired
# 403 = key is valid but lacks permission for this endpoint

# Check common API key issues:
# 1. Trailing whitespace in .env file:  API_KEY="abc123 " ← trailing space
# 2. Wrong environment:                 using test key on production
# 3. Missing prefix:                    some APIs need "sk_live_" prefix

7. Обработка истечения срока действия и обновление токенов

Токены JWT и токены доступа OAuth имеют ограниченный срок действия — обычно от 15 минут до 24 часов. Когда они истекают, каждый вызов API возвращает 401, пока вы не получите новый токен.

Решение зависит от вашего потока аутентификации. OAuth 2.0 использует токен обновления (refresh token) для получения нового токена доступа без повторной аутентификации. Системы на основе JWT обычно требуют нового входа в систему.

# Decode a JWT token to check its expiry (works on macOS and Linux)
echo "eyJhbGciOiJIUzI1NiIs..." | cut -d'.' -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Look for "exp" field — it's a Unix timestamp
# Compare with current time: date +%s

# OAuth 2.0 refresh token flow
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. Исправление проблем с CORS Preflight

Когда браузер отправляет кросс-доменный запрос с заголовком Authorization, он сначала отправляет предварительный запрос OPTIONS. Браузер автоматически удаляет заголовок Authorization из этого предварительного запроса. Если ваш сервер требует аутентификации для запроса OPTIONS, он возвращает 401 до того, как основной запрос будет отправлен.

Решение: настройте ваш сервер так, чтобы запросы OPTIONS были разрешены без аутентификации на эндпоинтах с поддержкой CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Как исправить ошибку 401 для владельца сайта

Если ваши посетители или пользователи сообщают об ошибках 401, проблема в конфигурации аутентификации вашего сервера. Выполните следующие проверки.

9. Проверьте конфигурацию аутентификации сервера

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

В Nginx проверьте директивы auth_basic. В Apache проверьте директивы AuthType и Require. В Node.js/Express проверьте порядок middleware — middleware аутентификации, размещённый перед обработчиками маршрутов, заблокирует всё.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. Проверьте правила аутентификации в .htaccess

На серверах Apache файлы .htaccess могут включать аутентификацию Basic или Digest для определённых каталогов. Если файл .htaccess находится в публичном каталоге с директивами AuthType, каждый посетитель получит запрос на вход 401.

Проверьте файлы .htaccess в затронутом каталоге и во всех родительских каталогах — Apache применяет правила из каждого .htaccess по всему пути.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Исправьте удаление заголовков обратным прокси

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

Проверьте конфигурацию вашего прокси, чтобы убедиться, что заголовок Authorization передаётся.

# Nginx reverse proxy — pass Authorization header to backend
location /api/ {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Authorization $http_authorization;  # ← Critical!
    proxy_pass_header Authorization;                      # ← Also add this
}

# Apache reverse proxy
<Location /api/>
    ProxyPass http://localhost:3000/api/
    ProxyPassReverse http://localhost:3000/api/
    RequestHeader set Authorization "expr=%{HTTP:Authorization}"  # Pass auth header
</Location>

Отладка ошибки 401 с помощью HTTP-заголовков

Самый быстрый способ диагностировать ошибку 401 — проверить заголовки ответа. Заголовок WWW-Authenticate в ответе сервера точно указывает, какой метод аутентификации требуется.

Используйте HTTP Headers tool DNS Robot или curl из терминала, чтобы увидеть полный ответ.

# Check the WWW-Authenticate header in the 401 response
curl -I https://api.example.com/protected-endpoint

# Typical 401 response headers:
# HTTP/1.1 401 Unauthorized
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"
# Content-Type: application/json

# The WWW-Authenticate header tells you:
# - The auth scheme (Bearer, Basic, Digest)
# - The realm (which area is protected)
# - The error reason (invalid_token, expired, etc.)

Обратите особое внимание на заголовок WWW-Authenticate. Если указано Bearer, вам нужен токен. Если указано Basic, вам нужны имя пользователя и пароль. Если указано error=invalid_token, ваш токен существует, но имеет неверный формат или истёк. Один этот заголовок обычно точно указывает, в чём проблема.

Влияет ли ошибка 401 на SEO?

Ошибка 401 на публичных страницах навредит вашему SEO. Когда Googlebot встречает 401, он не может просканировать страницу и в итоге удалит её из индекса.

Однако ошибки 401 на страницах, которые и должны требовать аутентификации (панели администратора, личные кабинеты, API-эндпоинты), совершенно нормальны. Google ожидает, что эти страницы будут защищены, и не будет штрафовать ваш сайт за это.

Проблема возникает, когда ошибки 401 появляются на страницах, которые должны быть общедоступными. Обычно это происходит при неправильной настройке middleware аутентификации или когда CDN/обратный прокси ошибочно требует учётные данные на публичных маршрутах.

Как предотвратить ошибки 401

Профилактика избавит вас от отладки в будущем. Следуйте этим практикам, чтобы минимизировать ошибки 401 в ваших приложениях и на сайтах.

• Реализуйте автоматическое обновление токенов — используйте refresh-токены для автоматического получения новых токенов доступа до их истечения

• Задайте правильные области аутентификации — защищайте только те маршруты, которые действительно требуют аутентификации, оставляйте публичные страницы открытыми

• Используйте понятные сообщения об ошибках — возвращайте информативное JSON-тело ошибки вместе с кодом 401, а не только код состояния

• Отслеживайте сбои аутентификации — настройте оповещения о всплесках ответов 401, которые могут указывать на проблемы с учётными данными или атаки

• Синхронизируйте часы серверов — используйте NTP для поддержания точности часов всех серверов в пределах нескольких секунд от UTC, чтобы предотвратить отклонение JWT из-за расхождения часов

• Тестируйте с помощью [HTTP Headers tool](/http-headers) — регулярно проверяйте, что публичные страницы возвращают 200, а защищённые — 401, как и ожидается

• Документируйте вашу схему аутентификации — чётко укажите ожидаемый формат заголовка Authorization в документации API

• Обрабатывайте CORS preflight — всегда разрешайте запросы OPTIONS без аутентификации на API-эндпоинтах