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

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

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

Стандарт HTTP определяет её как запрос, в котором «нет действительных учётных данных для целевого ресурса», а сервер, отправляющий 401, ОБЯЗАН включить заголовок WWW-Authenticate с указанием принимаемой схемы входа (RFC 9110 §15.5.2).

Проще говоря, сервер спрашивает «Кто вы?», прежде чем вас впустить.

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

Какую страницу вы увидите, зависит от сервера и приложения:

• 401 Unauthorized — стандартная строка статуса и формулировка большинства приложений
• 401 Authorization Required — заголовок встроенной страницы 401 в nginx, под ним написано «nginx» (обычно с версией) (исходный код nginx); старые серверы Apache 2.2 используют те же слова
• Unauthorized · This server could not verify that you are authorized to access the document requested — стандартная страница Apache
• 401 - Unauthorized: Access is denied due to invalid credentials — IIS; подробная страница (её видно только на самом сервере) и журнал IIS называют причину как 401.1, 401.2 или 401.3: сбой входа, конфигурация сервера или права на файлы
• Окно входа в браузере — когда сервер запрашивает HTTP Basic или Digest, а на IIS и в корпоративных интранетах ещё NTLM или Negotiate
• This page isn't working · HTTP ERROR 401 — Chrome, когда у ответа 401 нет собственной страницы
• JSON от API, например {"error":{"message":"Missing Authentication header","code":401}}

Браузеры показывают окно входа только для этих схем. API с токенами («Bearer») его не вызывают: их 401 приходит как JSON, который обрабатывает приложение. Сайты с формой входа обычно отправляют неавторизованного посетителя на страницу входа через редирект 302, а не отвечают 401.

«401 Authorization Required» в nginx

Этот заголовок берётся со встроенной страницы 401 в nginx. Вы увидите её, когда location защищён директивой auth_basic, а запрос пришёл без имени пользователя и пароля или с неверными; страница появится и тогда, когда вы закроете окно входа в браузере.

Посетителю нужно обновить страницу и ввести имя пользователя и пароль, которые дал владелец сайта. Они не связаны с учётными записями на самом сайте: Basic-аутентификация сверяется с файлом паролей на сервере.

Владельцу сайта так настраивается защита и так оставить один путь открытым для всех:

# Create the password file (htpasswd comes with apache2-utils or httpd-tools)
#   sudo htpasswd -c /etc/nginx/.htpasswd alice   # -c creates the file: leave it out when adding users

location /admin/ {
    auth_basic           "Admin area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

# Inside a protected server block, open one path to everyone
location /public/ {
    auth_basic off;
}

# Test, then reload
#   curl -I -u alice:PASSWORD https://example.com/admin/
#   sudo nginx -t && sudo systemctl reload nginx

Всё равно 401 при верном пароле? Проверьте, есть ли пользователь в файле (htpasswd -c перезаписывает файл и удаляет прежних пользователей) и не нужен ли заголовок Authorization ещё и приложению за nginx: вход Basic в nginx и Bearer-токены приложения используют один и тот же заголовок, поэтому приложение получает данные nginx и отклоняет их.

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

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

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

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

Причины — от стороны посетителя до стороны сервера:

• Неверное имя пользователя или пароль — самая простая причина, особенно после сброса пароля
• Истёкший токен аутентификации — у JWT, токенов доступа OAuth и cookie сессий есть срок действия
• Нет заголовка Authorization — запрос вообще не содержал учётных данных
• Недействительный API-ключ — ключ отозван, заменён или скопирован с ошибкой
• Неверная схема аутентификации — сервер ждёт токен Bearer, а получил Basic, или наоборот
• Расхождение часов — сервер, проверяющий JWT, и сервер, выдавший его (или ваш компьютер, если токен подписывает он), по-разному понимают время; многие библиотеки не допускают никакого расхождения
• Предварительный запрос CORS — проверка OPTIONS в браузере никогда не несёт учётных данных, поэтому сервер, который их требует, отвечает 401, а настоящий запрос не отправляется
• Устаревшая сессия — браузер отправляет cookie сессии, которую сервер уже завершил
• Заголовок теряется по пути — Apache скрывает Authorization от PHP-FPM и CGI-скриптов, если не настроить иначе, CloudFront по умолчанию убирает его из GET- и HEAD-запросов, а Basic-аутентификация nginx перед приложением забирает его себе
• Заблокированные или отозванные учётные данные — слишком много неудачных попыток могут заблокировать аккаунт (некоторые API отвечают в этом случае 429 Too Many Requests)

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

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

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

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

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

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

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

В Chrome с русским интерфейсом нажмите Ctrl+Shift+Delete (на Mac — Cmd+Shift+Delete), чтобы открыть «Удалить данные о работе в браузере», выберите диапазон «Все время» вместо «Последний час», отметьте «Файлы cookie и другие данные сайтов» и «Изображения и другие файлы в кеше» и нажмите «Удалить данные». Вы выйдете со всех сайтов. Только для одного сайта: слева от адреса «Сведения о сайте» → «Файлы cookie и данные сайтов» → «Данные сайтов на устройстве». Шаги для других браузеров (названия на английском):

Chrome, Edge, Firefox: Ctrl+Shift+Delete (Cmd+Shift+Delete on a Mac)
  → Time range: All time → Cookies and site data + Cached files → Delete / Clear
  (this signs you out of every site; the per-site option below doesn't)
Safari: Settings → Privacy → Manage Website Data → the site → Remove
One site in Chrome: the icon left of the address → Site settings → Delete data

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

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

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

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

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

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

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

Не уверены, что сайт вообще работает? Проверка доступности сайта открывает его из 11 точек, так что вы отличите проблему со входом от сбоя.

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

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

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

Самая частая ошибка разработчика — неверно сформированный заголовок Authorization. Когда сервер отправляет заголовок WWW-Authenticate, в нём названа ожидаемая схема; многие JSON API (например, GitHub и OpenRouter) его не отправляют и объясняют проблему в теле ответа.

Проверьте, что заголовок соответствует нужному формату. Самые распространённые схемы — 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... ← many servers reject it
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Затем прочитайте заголовок WWW-Authenticate в ответе 401: в нём указана схема, которую ждёт сервер. Проверка HTTP-заголовков от DNS Robot показывает ответ целиком.

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

API-ключи перестают работать, когда ключ заменён или отозван, аккаунт заблокирован или переведён на более низкий тариф, либо тестовый ключ используется в продакшене. (Превышение лимита запросов даёт 429, а ключ без доступа к конечной точке обычно получает 403.)

Проверьте в панели провайдера, что ключ активен, затем проверьте его напрямую:

# Test a key: print only the status code (a real GET; some APIs reject HEAD)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = the key works
# 401 = the key is missing, wrong, revoked or expired
# 403 = the key works but isn't allowed to use this endpoint

# Common slips:
# 1. A space or newline after the key in .env:   API_KEY="abc123 "
# 2. The test key in production, or the reverse
# 3. An empty variable, so the header is just "Authorization: Bearer"

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

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

Если есть токен обновления (OAuth 2.0 и большинство схем на JWT), обменяйте его на новый токен доступа; если нет, войдите заново.

# Read a JWT's payload (tokens use base64url, so plain base64 -d often fails)
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p+"==")),indent=2))' "$TOKEN"
# "exp" is a Unix timestamp; compare it with: date +%s

# OAuth 2.0: get a new access token with the refresh token
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

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

Решение: пропускать запросы OPTIONS без аутентификации на конечных точках с CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin https://app.example.com;
        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;
    }

    # CORS header on every other answer, the 401 included, or the browser reports a CORS error
    add_header Access-Control-Allow-Origin https://app.example.com always;

    # 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: app.use(auth), зарегистрированный раньше публичных маршрутов, защищает и их, поэтому сначала регистрируйте публичные маршруты или подключайте аутентификацию только к защищённому роутеру.

# 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 и Require, каждый посетитель получает запрос входа 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. Убедитесь, что заголовок Authorization доходит до приложения

Клиент отправляет верные данные, но приложение их не видит. Где теряется заголовок:

nginx по умолчанию передаёт Authorization бэкенду, так что дополнительные строки не нужны; но если в том же location включён auth_basic, вход nginx забирает заголовок себе (см. раздел про nginx выше). Apache скрывает Authorization от PHP-FPM и CGI-скриптов, пока вы не включите CGIPassAuth (Apache 2.4.13+) — классическая причина ошибок 401 в API на WordPress и Laravel за Apache.

# Apache 2.4.13+ (inside a <Directory> block, or .htaccess): pass Authorization to PHP-FPM and CGI
CGIPassAuth On

# Older Apache: copy it into an environment variable instead
SetEnvIf Authorization "(.+)" HTTP_AUTHORIZATION=$1

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

Быстрее всего диагностировать 401 можно, прочитав ответ: заголовок WWW-Authenticate, если сервер его отправляет, показывает, какой вход нужен, а JSON API обычно объясняют ошибку в теле.

Используйте проверку HTTP-заголовков от DNS Robot (если 401 появляется только после редиректа, проверка редиректов покажет, какой шаг его отдаёт) или curl в терминале:

# Print the response headers of a real GET
curl -sS -D - -o /dev/null https://api.example.com/protected-endpoint

# A 401 often carries one of:
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"

# It tells you:
# - the scheme (Bearer, Basic, Digest, Negotiate)
# - the realm (which area is protected)
# - for Bearer tokens, the error: invalid_request, invalid_token or insufficient_scope

Если в WWW-Authenticate указано Bearer, нужен токен; если Basic — имя пользователя и пароль. error="invalid_token" значит, что токен истёк, отозван, повреждён или недействителен по другой причине. Заголовка нет совсем? Прочитайте тело ответа: многие API указывают причину там.

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

401 на публичной странице убирает её из Google. Google обращается со всеми кодами 4xx, кроме 429, одинаково: робот сообщает, что содержимого нет, и проиндексированный URL удаляется (документация Google о сканировании).

401 на страницах, которые должны требовать входа (админ-панели, личные кабинеты, API), — это нормально: Google не наказывает сайт за них. Только не используйте 401 или 403, чтобы замедлить Googlebot: по словам Google, на частоту сканирования они не влияют.

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

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

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

• Настройте автоматическое обновление токенов — используйте токены обновления, чтобы незаметно получать новые токены доступа до истечения старых
• Ограничьте область аутентификации — защищайте только маршруты, которым она действительно нужна, публичные страницы оставьте открытыми
• Давайте понятные сообщения об ошибках — возвращайте вместе с 401 полезное JSON-тело, а не только код статуса
• Следите за сбоями аутентификации — настройте оповещения о всплесках ответов 401: они могут указывать на проблемы с учётными данными или атаки
• Синхронизируйте часы серверов — используйте NTP, чтобы все серверы отставали от UTC не больше чем на несколько секунд и JWT не отклонялись из-за расхождения часов
• Проверяйте с помощью проверки HTTP-заголовков — регулярно убеждайтесь, что публичные страницы возвращают 200, а защищённые — 401, как задумано
• Документируйте схему аутентификации — чётко опишите ожидаемый формат заголовка Authorization в документации API
• Учитывайте предварительный запрос CORS — всегда разрешайте запросы OPTIONS без аутентификации на конечных точках API