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

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

Ключевые выводы

• 401 — ошибкааутентификации, а не авторизации: сервер не знает, кто вы, а не запрещает вам доступ.
• Согласно актуальному стандарту RFC 9110 (IETF, июнь 2022), сервер обязан вернуть заголовокWWW-Authenticateвместе с ответом 401.
• Googlebot не может краулить страницы с ответом 401 — они не попадают в индекс; для публичных страниц это SEO-проблема, для закрытых разделов — норма.
• Наиболее частые причины: неверные учётные данные, истёкшая сессия или токен, неправильная конфигурация.htaccessили Nginx, конфликт плагинов безопасности.
• Для диагностики используйте Google Search Console, DevTools браузера, curl или Postman и логи сервера.

Что такое ошибка 401 и чем она отличается от 403 и 404

Статус-код 401 определён в разделе 15.5.2 стандарта RFC 9110 (HTTP Semantics, IETF STD 97, июнь 2022), который заменил устаревший RFC 7235. Формулировка стандарта однозначна: сервер не выполнил запрос, потому что клиент не предоставил действительных учётных данных для целевого ресурса. MDN Web Docs уточняет важный нюанс: несмотря на название «Unauthorized» (неавторизован), семантически ответ означает «unauthenticated» — клиент не прошёл аутентификацию. Это принципиальное различие, которое часто путают.

Название «Unauthorized» исторически вводит в заблуждение, поскольку в повседневном языке «авторизация» и «аутентификация» нередко смешиваются. Аутентификация отвечает на вопрос «кто вы?» — подтверждение личности. Авторизация отвечает на вопрос «что вам разрешено?» — проверка прав доступа. Ошибка 401 означает, что личность не подтверждена. Если личность подтверждена, но прав недостаточно — сервер должен вернуть 403 Forbidden, а не 401.

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

Как работает механизм 401 на уровне HTTP

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

Примеры значений заголовкаWWW-Authenticate: для базовой аутентификации —Basic realm="Admin Panel", для токен-аутентификации —Bearer realm="api", error="invalid_token". Параметрrealmобозначает защищённую область и помогает пользователю понять, к какому ресурсу он пытается получить доступ. После получения 401 клиент должен повторить запрос, добавив заголовокAuthorizationс корректными учётными данными. При успешной проверке сервер возвращает 200 OK.

Браузер при получении 401 с Basic Auth автоматически показывает диалоговое окно ввода логина и пароля. При Bearer Token такого диалога нет — клиентское приложение должно самостоятельно обработать ответ и инициировать повторную аутентификацию. Это важно учитывать при разработке веб-приложений и мобильных клиентов.

Причины появления ошибки 401

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

Причины на стороне пользователя

• Неверный логин или пароль— наиболее распространённая причина. Включая опечатки, неправильный регистр, лишние пробелы.
• Истёкшая сессия— браузер отправляет устаревший cookie сессии вместо того, чтобы запросить новый.
• Устаревший или отозванный токен— JWT или API Key с истёкшим сроком действия.
• Кэшированные учётные данные— браузер хранит старые данные Basic Auth и отправляет их автоматически.
• Расширения браузера— некоторые блокировщики рекламы или VPN-расширения могут изменять или удалять заголовки запроса.

Причины на стороне сервера и конфигурации

• Ошибка в.htaccess— неправильный путь к файлу.htpasswd, отсутствие модуляmod_auth_basic, некорректные права доступа к файлу паролей (должны быть 644).
• Ошибка в конфигурации Nginx— неверная директиваauth_basicили путь к файлу паролей.
• Плагины безопасности WordPress— некоторые плагины (Wordfence, iThemes Security) могут блокировать запросы Googlebot или других клиентов, возвращая 401.
• Неправильная настройка reverse proxy— Nginx или Apache удаляет заголовокAuthorizationперед передачей запроса бэкенду, и бэкенд не получает учётных данных.

Нетривиальные технические причины

Среди менее очевидных причин выделяются три сценария, которые часто упускают при диагностике. Первый — CORS preflight: браузер отправляет предварительный OPTIONS-запрос, из которого автоматически удаляется заголовокAuthorization; если сервер не настроен корректно обрабатывать preflight, он возвращает 401 на этот запрос, и основной запрос не выполняется. Второй — рассинхронизация времени при использовании JWT: токены содержат временны́е метки, и если системное время сервера или клиента расходится более чем на допустимый порог, токен считается недействительным. Третий — неправильная конфигурация reverse proxy, при которой заголовокAuthorizationне проксируется на бэкенд.

Специфика WordPress

В WordPress ошибка 401 чаще всего возникает в трёх контекстах: REST API (/wp-json/), XML-RPC (/xmlrpc.php) и административная панель (/wp-admin/). Плагины безопасности могут блокировать запросы к REST API без аутентификации, что нарушает работу сторонних интеграций. XML-RPC по умолчанию требует аутентификации и часто становится источником ложных 401 в логах при попытках брутфорса.

Как исправить ошибку 401: пошаговые инструкции

Для обычного пользователя

1. Проверьте учётные данные.Убедитесь, что логин и пароль введены правильно, без лишних пробелов и с учётом регистра. Попробуйте сбросить пароль через форму восстановления.
2. Очистите кэш и cookie браузера.В Chrome: Настройки → Конфиденциальность → Очистить данные браузера. Выберите «Файлы cookie» и «Кэшированные изображения и файлы». После очистки перезагрузите страницу.
3. Попробуйте режим инкогнито.Это позволяет исключить влияние кэшированных данных и расширений браузера.
4. Отключите расширения браузера.Временно деактивируйте блокировщики рекламы, VPN-расширения и менеджеры паролей, затем повторите попытку.
5. Проверьте, не истекла ли ваша подписка или доступ.Если ресурс платный, убедитесь, что ваш аккаунт активен.

Для администратора сайта

1. Проверьте логи сервера.Для Nginx:/var/log/nginx/error.log, для Apache:/var/log/apache2/error.log. Найдите строки с кодом 401 и определите, какие URL затронуты и какой модуль генерирует ошибку.
2. Проверьте конфигурацию.htaccess.Убедитесь, что директивыAuthType Basic,AuthName,AuthUserFileиRequire valid-userуказаны корректно. Путь вAuthUserFileдолжен быть абсолютным. Проверьте, что модульmod_auth_basicвключён.
3. Проверьте права доступа к файлу.htpasswd.Файл должен иметь права 644 и быть доступен для чтения веб-сервером. Убедитесь, что файл существует по указанному пути.
4. Проверьте настройки плагинов безопасности.В WordPress временно деактивируйте плагины безопасности и проверьте, исчезла ли ошибка. Если да — найдите в настройках плагина правило, блокирующее нужные запросы.
5. Проверьте, не закрыты ли публичные страницы авторизацией случайно.Используйте Screaming Frog или Sitebulb для краулинга сайта и выявления всех URL с ответом 401.

Для разработчика

1. Проверьте заголовокAuthorizationв запросе.Используйте DevTools (вкладка Network) или curl:curl -v -H "Authorization: Bearer ваш_токен" https://example.com/api/resource. Убедитесь, что заголовок присутствует и содержит корректное значение.
2. Проверьте срок действия токена.JWT-токены содержат полеexp(expiration). Декодируйте токен на jwt.io и убедитесь, что он не истёк. Реализуйте автоматическое обновление токена (refresh token flow) при получении 401.
3. Проверьте конфигурацию CORS.Убедитесь, что сервер корректно обрабатывает preflight OPTIONS-запросы и возвращает заголовокAccess-Control-Allow-Headers: Authorization.
4. Проверьте конфигурацию reverse proxy.В Nginx убедитесь, что директиваproxy_pass_header Authorizationилиproxy_set_header Authorization $http_authorizationприсутствует в конфигурации. Apache: проверьте директивуProxyPassReverseи наличиеCGIPassAuth Onпри необходимости.
5. Используйте Postman для изолированной проверки.Отправьте запрос напрямую к API с корректными заголовками, минуя браузер и прокси. Это позволяет исключить клиентские факторы.

Влияние ошибки 401 на SEO и индексацию

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

Проблема возникает, когда ответ 401 появляется на страницах, которые должны быть публично доступны. В Google Search Console такие страницы отображаются в отчёте «Индексирование страниц» (Page Indexing Report) со статусом «Blocked due to unauthorised request (401)» в разделе «Not Indexed». Важный нюанс: эта ошибка может появляться даже для страниц, доступных обычным пользователям — если брандмауэр или система безопасности сайта блокирует именно Googlebot по User-Agent или IP-адресу.

Как найти страницы с 401 в Google Search Console

1. Откройте Google Search Console и выберите нужный ресурс.
2. В левой панели навигации перейдите в раздел «Индексирование» → «Страницы».
3. В таблице «Почему страницы не проиндексированы» найдите строку «Заблокировано из-за несанкционированного запроса (401)».
4. Нажмите на строку, чтобы увидеть список затронутых URL.
5. Используйте инструмент проверки URL (URL Inspection Tool) для каждой страницы, чтобы понять, как Google видит ресурс в реальном времени.

Краулинговый бюджет и 401

Страницы, постоянно возвращающие ответ 401, расходуют краулинговый бюджет — ресурс Googlebot на обход страниц сайта — без какой-либо пользы для индексации. Для крупных сайтов с тысячами защищённых URL это может существенно снижать эффективность краулинга публичных страниц. Рекомендуется исключить защищённые разделы из файлаsitemap.xmlи убедиться, что публичные страницы не содержат ссылок на закрытые URL. Не следует использовать ответ 401 как инструмент массового удаления страниц из индекса — для этого существуют корректные механизмы: редиректы 301, статус 410 Gone или директиваnoindex.

Отдельного внимания заслуживает комбинацияrobots.txtиnoindex: если страница заблокирована вrobots.txt, Googlebot не будет её краулить и никогда не увидит тегnoindex. Для управления индексацией закрытых разделов используйте заголовокX-Robots-Tag: noindexв HTTP-ответе — он обрабатывается до попытки краулинга содержимого страницы.

Ошибка 401 в API и разработке

В контексте REST API правильное использование кодов 401 и 403 критично для безопасности и удобства разработчиков, интегрирующих ваш API. Общее правило: возвращайте 401, когда запрос не содержит учётных данных или они недействительны (токен истёк, подпись неверна). Возвращайте 403, когда учётные данные действительны, но у пользователя нет прав на выполнение операции.

При получении ответа 401 клиент должен автоматически инициировать обновление токена через refresh token flow (если реализован OAuth 2.0 или аналогичный механизм), а затем повторить исходный запрос. Если refresh token также недействителен — перенаправить пользователя на страницу входа. Такая логика предотвращает ситуацию, когда пользователь видит ошибку из-за истёкшего токена, хотя его сессия должна быть активной.

Технические маршруты API (/api/,/wp-json/) следует закрывать от индексации с помощью заголовкаX-Robots-Tag: noindexили правил вrobots.txt, а не полагаться на то, что ответ 401 автоматически исключит их из индекса — Googlebot всё равно тратит краулинговый бюджет на попытку обращения к этим URL.

Подкоды 401 в Microsoft IIS

На серверах под управлением Microsoft IIS существуют расширенные подкоды ошибки 401, которые помогают точнее диагностировать причину. Эти подкоды специфичны для IIS и не являются частью универсального HTTP-стандарта: 401.1 — неудачная попытка входа; 401.2 — конфигурация сервера вызвала неудачную попытку входа; 401.3 — ACL (Access Control List) запретил доступ; 401.501 — клиент превысил лимит запросов. При работе с IIS-сервером эти подкоды отображаются в логах и помогают сузить область поиска проблемы.

Профилактика и мониторинг 401-ошибок

Превентивный мониторинг позволяет обнаружить проблемы с аутентификацией до того, как они повлияют на пользователей или индексацию. Настройте оповещения в системе мониторинга (Uptime Robot, Zabbix, Datadog) на появление ответов 401 для публичных URL. Регулярно проверяйте отчёт «Индексирование страниц» в Google Search Console на наличие новых URL со статусом 401.

Чек-лист перед запуском сайта или нового раздела

• Проверьте все публичные URL краулером (Screaming Frog, Sitebulb) — убедитесь, что ни одна публичная страница не возвращает 401.
• Убедитесь, что защищённые разделы исключены изsitemap.xml.
• Проверьте, что публичные страницы не содержат ссылок на закрытые URL.
• Протестируйте поведение сайта с отключёнными cookie и без заголовкаAuthorization— имитируйте запрос Googlebot.
• Убедитесь, что конфигурация reverse proxy не удаляет заголовокAuthorization.
• Проверьте срок действия SSL-сертификата — некоторые системы аутентификации зависят от HTTPS.
• Для API-эндпоинтов убедитесь, что CORS настроен корректно и preflight OPTIONS-запросы обрабатываются без ошибок.
• Настройте автоматическое обновление токенов в клиентских приложениях.

Когда ошибка 401 — это норма, а когда — проблема

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

Ошибка 401 становится проблемой в трёх случаях: публичные страницы, которые должны индексироваться, случайно закрыты аутентификацией; Googlebot блокируется брандмауэром или плагином безопасности, хотя обычные пользователи имеют доступ; большое количество защищённых URL расходует краулинговый бюджет, снижая эффективность обхода публичных страниц. Во всех трёх случаях решение начинается с диагностики через Google Search Console и проверки логов сервера — именно эти инструменты дают точную картину того, какие URL затронуты и по какой причине.