Ошибка 503 Service Unavailable: что означает и как исправить
5 мин чтения
Ошибка 503 Service Unavailable: что означает и как исправить

Ошибка 503 Service Unavailable: что означает и как исправить

503 — единственная ошибка из пятисотой серии, которую сервер отдаёт «сознательно»: я жив, но сейчас обслуживать не буду. За ней прячутся два совершенно разных сюжета — плановые техработы и внезапная перегрузка. Разбираем оба, плюс SEO-нюанс, из-за которого 503 называют «правильной ошибкой»: при грамотном использовании она защищает позиции сайта, а при безграмотном — убивает их.

Два лица 503: техработы и перегрузка

Сюжет первый — намеренный. Администратор включил режим обслуживания: обновляется CMS, накатывается миграция базы, меняется сервер. Приложение целиком отвечает 503, часто с человеческой заглушкой «скоро вернёмся». Это цивилизованный способ закрыться на ремонт: и посетитель, и поисковый робот получают честный сигнал «временно, зайдите позже» — в отличие от молчащего сервера или внезапных 500.

Сюжет второй — вынужденный. Сервер захлёбывается: кончились воркеры, забились очереди, сработали лимиты на число соединений — и балансировщик начинает отстреливать лишние запросы кодом 503. Классические триггеры — наплыв с рекламы или рассылки, сезонный пик, боты и парсеры, о которых мы писали отдельно, или чей-то тяжёлый экспорт, съевший все ресурсы. В отличие от 502, где бэкенд мёртв, при 503 он жив — просто не справляется.

Если вы посетитель

Делать ничего не нужно — ошибка не про вас и не про ваше устройство. Если на заглушке указано время окончания работ, верьте ему. Если нет — попробуйте зайти через 10–15 минут: перегрузки волнообразны, и между волнами сайт отвечает. Единственный осмысленный «лайфхак»: если вам нужна информация со страницы, а не действие на сайте, — сохранённая копия в поисковике или веб-архив выручают, пока сайт лежит.

Если вы владелец: чек-лист по обоим сюжетам

Симптом Вероятная причина Действие
503 на всём сайте после обновления Забыт режим обслуживания (в WordPress — файл .maintenance, в Битриксе — соответствующий флаг) Выключить режим/удалить файл — классика «обновились и забыли»
503 в часы пик, ночью чисто Не хватает воркеров/ресурсов под реальный трафик Кэширование, увеличение лимитов, апгрейд тарифа
503 волнами без роста посещаемости Боты и парсеры жгут ресурсы Смотреть access-лог по IP и User-Agent, резать агрессивных
503 только на части страниц Лимиты на конкретный пул приложения или локацию Проверить настройки пула и rate-limit для этого пути
503 от хостинга на shared-тарифе Упёрлись в лимиты тарифа (CPU-минуты, процессы) Панель хостинга → статистика лимитов; дальше — оптимизация или переезд

SEO-нюанс: почему 503 — «правильная» ошибка для техработ

Поисковые роботы понимают 503 буквально: «временно недоступно — загляни позже». Страницы при этом не выбрасываются из индекса, а обход откладывается. Именно поэтому на время работ нужно отдавать 503, а не 200 с текстом «ведутся работы» (иначе поисковик проиндексирует заглушку вместо тысяч страниц) и не 404 (иначе страницы начнут выпадать). Хорошим тоном считается добавить заголовок Retry-After с указанием, когда возвращаться:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

Важна и длительность. Часы и даже сутки в статусе 503 поисковики переживают спокойно. Но если 503 висит длительно — недели, — роботы начинают трактовать «временно» как «навсегда», и страницы поедут из индекса со всеми последствиями. Правило простое: 503 — обезболивающее на время операции, а не способ жить.

Как правильно закрыться на техработы: рецепт для nginx

Правильный maintenance-режим делается за пять минут и учитывает три вещи: код 503 (а не 200), заголовок Retry-After и лазейку для себя — чтобы вы могли проверять сайт, пока остальные видят заглушку:

# в блоке server:
if (-f /var/www/maintenance.on) { set $maint 1; }
if ($remote_addr = ВАШ.IP.АДРЕС)  { set $maint 0; }
if ($maint) { return 503; }

error_page 503 @maintenance;
location @maintenance {
    add_header Retry-After 3600 always;
    root /var/www/maintenance;
    rewrite ^ /index.html break;
}

Включение — создать файл maintenance.on, выключение — удалить. Никаких правок конфига в горячке ночных работ и никакого шанса «забыть снять» половину сайта: флаг один и виден в файловой системе. В исключения, кроме своего IP, имеет смысл добавить и адреса своего мониторинга — тогда он продолжит видеть настоящее состояние сервера за заглушкой; а вот отдельную проверку публичной страницы на время работ можно и оставить срабатывающей — как контроль того, что заглушка корректно отдаётся посетителям.

Самый дорогой сценарий — «забытая» заглушка

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

Как отличить «мигающую» перегрузку от инцидента

Перегрузочный 503 редко бывает сплошным: сервер отдаёт то ошибку, то нормальную страницу, в зависимости от того, попал ли запрос в свободный слот. Ручная проверка такое почти не ловит — нужно смотреть долю ошибок в потоке запросов. Здесь два инструмента дополняют друг друга: access-лог сервера показывает долю 503 изнутри, а регулярные внешние проверки — как часто на ошибку натыкается реальный посетитель снаружи, из разных городов. Если внешний мониторинг ловит 503 в 10% проверок — каждый десятый посетитель уходит ни с чем, и это уже не «редкие всплески», а системная нехватка ресурсов.

Как это устроено в Пруфене

Пруфен проверяет сайт HTTP-запросами из 13 точек с интервалом от 2 минут и хранит историю каждой проверки: видно и сплошные инциденты, и «мигающие» 503 в часы пик. Пороги срабатывания настраиваются так, чтобы плановые ночные работы не создавали шума, а дневная перегрузка поднимала тревогу сразу.

Частые вопросы

Чем 503 отличается от 502 и 504? 503 — сервер жив, но отказывает сознательно (работы или перегрузка). 502 — приложение за прокси умерло или отвечает мусором. 504 — приложение живо, но не уложилось в отведённое время.

Сколько можно «висеть» в 503 без вреда для SEO? Часы — безопасно, сутки — терпимо, недели — начнётся выпадение страниц из индекса. Планируйте тяжёлые работы так, чтобы укладываться в часы, и всегда отдавайте Retry-After.

Почему 503 отдают только некоторым посетителям? Потому что перегрузка — это очередь: кому-то достался свободный воркер, кому-то нет. Отсюда же жалобы «у меня работает, у клиента нет» — оба правы, просто попали в разные моменты.

Открыл сайт после работ — 503 осталась, хотя режим выключен. Почему? Три обычных подозреваемых: кэш CDN, который ещё отдаёт закэшированную заглушку; недоудалённый флаг режима обслуживания (в WordPress — файл .maintenance в корне); и кэш самого приложения. Проверьте страницу с добавленным параметром ?nocache=1 и из режима инкогнито, прежде чем перезапускать всё подряд.

Хостинг говорит «у вас всё в порядке», а 503 периодически вижу. Кому верить? Истории проверок. Соберите статистику снаружи за несколько дней: время каждой ошибки, из каких точек она видна. С таким графиком разговор с поддержкой хостинга переходит из «кажется, иногда не работает» в предметный.

Была ли статья полезна?

Начните мониторинг прямо сейчас

Бесплатный тариф — до 5 проверок. 150 ₽ на баланс при регистрации.

Создать аккаунт