Артём Савельев 
Ошибка 401 Unauthorized: что означает и как исправить
401 — самая вежливая из ошибок доступа: сервер не отказывает навсегда, а просит представиться. Проблема в том, что появляется она часто там, где никакого логина быть не должно: на публичных страницах, в API-интеграциях, после обновления сайта. Разбираем механику, отличие от 403 и типовые сценарии — от протухшей сессии до забытого пароля на тестовой версии сайта.
Механика: сервер просит представиться
Формально 401 значит «запрос без действительных учётных данных»: вместе с ошибкой сервер присылает заголовок WWW-Authenticate — приглашение авторизоваться. Именно поэтому при 401 браузер иногда показывает системное окошко логина и пароля: это Basic Auth, простейшая защита «на уровне сервера», которую любят вешать на тестовые и служебные разделы. Ключевое отличие от 403 запоминается одной фразой: 401 — «вы не представились», 403 — «мы вас знаем, но не пустим». Первое лечится правильным входом, второе — нет.
Если вы посетитель
Сценарий первый: 401 в личном кабинете, где вы уже были залогинены. Ваша сессия истекла или сброшена (например, после смены пароля или массового разлогина после инцидента) — просто войдите заново. Если не помогает, чистите куки для этого сайта: битая сессионная кука иногда «залипает» и продолжает отправляться, сервер её отвергает — круг замыкается. Сценарий второй: сайт встречает системным окном логина/пароля, хотя это обычный публичный сайт. Это почти наверняка Basic Auth, случайно оставленный на проде (об этом ниже), — от вас тут ничего не зависит, можно лишь сообщить владельцу. Сценарий третий: 401 в приложении или программе, которая работала годами, — истёк сохранённый токен или пароль приложения; перелогиньтесь в самой программе.
Если вы владелец: где 401 возникает «сам»
| Сценарий | Как проявляется | Лечение |
|---|---|---|
| Basic Auth уехал с тестовой площадки на прод | Весь сайт (или раздел) просит логин у обычных посетителей и роботов | Убрать auth_basic из прод-конфига; держать разные конфиги для сред |
| Истёк или отозван API-токен интеграции | Интеграция молча перестала работать: заказы не выгружаются, статусы не приходят | Перевыпустить токен; поставить мониторинг на API-эндпоинт |
| Сломался механизм сессий | Пользователей массово «выкидывает»; жалобы «постоянно просит войти» | Проверить хранилище сессий (Redis/файлы), время на серверах, настройки кук |
| Защита статики/фидов «заодно» | Правило auth зацепило фиды, картинки или вебхуки платёжки | Точечные исключения для путей, которые должны быть публичными |
Разработчик скопировал конфиг со staging на прод вместе с Basic Auth — и сайт для всего мира закрылся окном пароля. Хуже всего, что команда этого не видит: у всех сотрудников пароль сохранён в браузере, и сайт «открывается как обычно». Первыми страдают новые посетители и поисковые роботы — то есть ровно те, кто молча уходит. Внешняя проверка без сохранённых паролей ловит такое в первые же минуты.
401 в API: тихий убийца интеграций
Отдельного внимания заслуживают API: там 401 не видит никто, кроме логов. Токен истёк по сроку, сотрудник, на чьём аккаунте держалась интеграция, уволился, ключ отозвали при ротации секретов — и обмен данными останавливается без единого видимого симптома на сайте. Заказы перестают уходить в CRM, остатки — обновляться, и заметно это становится по бизнес-последствиям через дни. Правило простое: у каждого критичного API-эндпоинта должна быть своя проверка доступности с реальной авторизацией — как мы разбирали в статье про мониторинг API. Тогда «401 вместо 200» становится уведомлением через две минуты, а не разбором полётов через неделю.
Basic Auth — хороший инструмент не на своём месте
Сама по себе базовая авторизация — правильный способ закрыть от мира то, что миру видеть рано: staging-версию, черновой раздел, служебную панель. Она же спасает тестовые площадки от индексации — поисковик, получив 401, не положит в выдачу сайт-дубль, который потом конкурировал бы с боевым. Три правила аккуратного использования: пароль на staging — всегда (и это часть чек-листа создания тестовой площадки); конфиги сред разделены так, чтобы auth физически не мог уехать на прод с копированием файла; и для внешних систем, которым нужен доступ за пароль (мониторинг, интеграции), — отдельные учётные данные, которые можно отозвать, не трогая остальные.
# Быстрая проверка "не закрылись ли мы от мира" после работ: curl -I https://example.ru | head -1 # HTTP/2 200 — всё открыто # HTTP/2 401 — сайт просит пароль у всего интернета
Пруфен в HTTP-проверках ждёт от страницы конкретный код ответа: если публичная страница вдруг начала отдавать 401 — придёт уведомление, даже если «у всех сотрудников открывается». В настройках проверки задаются собственные заголовки — можно проверять и эндпоинты за авторизацией, передавая тестовый токен, и ловить его протухание раньше интеграций.
Частые вопросы
Чем 401 отличается от 403 на практике? После 401 есть смысл логиниться — с правильными данными доступ откроется. При 403 вход не поможет: запрет адресован вам (или вашему IP/стране) независимо от аккаунта.
Сайт постоянно просит логин и пароль системным окном. Что это? Basic Auth на уровне веб-сервера. Если это чужой сайт — вероятно, вы наткнулись на служебную или тестовую версию. Если ваш — проверьте, не уехала ли защита staging на боевой домен.
Вредит ли 401 поисковым позициям? Да, если его получают роботы: страницы за авторизацией выпадают из индекса. Известный случай — Basic Auth, случайно закрывший весь сайт: для поисковика это равносильно исчезновению сайта.
Почему после смены пароля посыпались 401 в куче сервисов? Потому что старый пароль или связанные с ним токены были сохранены везде: в почтовых клиентах, интеграциях, скриптах. Это штатное поведение — обновите данные во всех местах, где они были прописаны.