Как работает ошибка 503?

Когда сервер возвращает код ошибки 503 (503 Service Unavailable), это значит одно: веб-сервер получил запрос от клиента и понял, что нужно что-то с ним делать, но прямо сейчас это невозможно. Не потому, что запрос неправильный. Причина может быть связана с базой данных. Просто — в эту секунду сервер настолько перегружен или нарушена его работа, что он не может обработать этот конкретный запрос.

Это отличается от ошибки 500 (Internal Server Error), где в самом коде что-то сломалось. При 500 сервер ловит ошибку в приложении и падает. При 503 сервер отвечает, но временно не может обработать запрос.

Для разработчика ошибка 503 означает: ваш код должен поймать этот статус и попробовать запрос еще раз. Но не сразу же, а с задержкой. Информацию о задержке сервер отправляет в специальном заголовке.

Для DevOps это сигнал о перегрузке, отказе зависимости или плановых работах. Нужно срочно добавить ресурсы, переключить трафик или запустить процесс восстановления.

Для владельца сайта это значит: бизнес приостановлен, клиенты не могут получить доступ. Нужно узнать, в чем причина, и скорее все исправить.

Заголовок Retry-After: когда именно повторить попытку

Вместе с кодом 503 сервер отправляет HTTP-заголовок Retry-After. Это инструкция для клиента: когда попробовать снова.

Заголовок Retry-After может быть написан двумя способами.

Первый — количество секунд:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

Значит: повторить запрос не раньше чем через 120 секунд (две минуты). Браузер или ваше приложение должны дождаться этого времени и отправить запрос повторно.

Второй — конкретная дата и время:

HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

Это прямо указывает момент в будущем, когда сервис восстановится. Клиент смотрит на текущее время и сам считает, сколько ждать.

Почему это важно? Потому что правильно написанный retry-обработчик не будет просто спамить сервер запросами каждую секунду. Он будет уважать это значение и коррелировать количество попыток с exponential backoff. Поисковые роботы Google, Яндекс и другие движки тоже парсят Retry-After и замедляют краулинг вашего сайта.

Для администратора: обязательно включите выдачу Retry-After в конфигурацию nginx, Apache или другого веб-сервера. Это помогает всем участникам (клиентам, API-потребителям, поисковикам) правильно следовать расписанию восстановления работы.

Какие причины вызывают ошибку 503?

Перегрузка сервера при пике трафика

Сервер имеет лимит на одновременные соединения. Когда трафик резко возрастает в 5–10 раз (распродажа, вирусный пост в соцсетях, новость про вас на Яндексе), веб-сервер наткнется на этот лимит. Вместо краха (полного отказа обслуживать кого бы то ни было) он начинает выдавать 503 новым клиентам. Это graceful degradation: лучше вернуть 503 некоторым, чем умереть.

Плановое техническое обслуживание

Администратор переводит сервис в режим maintenance. Нужно установить обновление, перенести данные с одного хоста на другой, перезагрузить сервер. На время работ все запросы получают ошибку 503 с Retry-After, указывающим, когда это закончится.

Бэкенд или микросервис недоступен

Ваш веб-сервер работает, но он зависит от другого сервиса — платежной системы, базы данных на другом хосте, API поставщика. Если тот упал или недоступен, сервер получит запрос, но не сможет его обработать. Результат — 503.

Исчерпаны ресурсы: CPU, оперативная память, TCP-порты

Приложение может потреблять все доступные ресурсы сервера. Утечка памяти в коде, какой-то процесс занял весь процессор, или кончились свободные порты для исходящих соединений. Когда ресурсов нет, сервис не может начать новый handler для запроса — возвращается 503.

База данных перегружена или упала

База данных становится недоступна, перегружена или зависла на долгом запросе от другого клиента. Приложение не может выполнить свой запрос к БД. Вместо того чтобы заморозить весь сервис, приложение немедленно возвращает 503.

Провайдер ввел ограничение

Ваш хостинг-провайдер имеет лимиты на количество процессов, файловых дескрипторов, bandwidth. Когда вы упираетесь в лимит, сервер перестает обрабатывать новые запросы и выдает 503.

Разработчик должен уметь читать логи приложения и искать в них настоящую причину. DevOps должен мониторить метрики: CPU, RAM, количество активных соединений в nginx. Владелец должен знать, кому позвонить: в техподдержку хостинга или к своей команде разработчиков.

Ошибка 503 и другие коды ошибок 5xx сервера

На первый взгляд, коды 500, 502, 503, 504 похожи. Но это разные проблемы. Способ реагирования должен быть разным.

503 Service Unavailable против 500 Internal Server Error

Код 500 говорит: в коде приложения произошла ошибка. Исключение, которое не было обработано правильно. Это проблема в самом коде, и она не временная. Нет смысла повторять запрос немедленно — он упадет снова. Нужно исправить ошибку в коде.

Код 503 не означает, что приложение сломано: оно временно не может обработать запрос (перегрузка, зависимость недоступна, техработы). Повторите попытку позже.

503 против 502 Bad Gateway

502 Bad Gateway означает, что реверс-прокси (скажем, nginx) получил запрос, переправил его бэкенд-серверу, но бэкенд совсем не ответил, упал или выплюнул бессмыслицу. Вышестоящий сервер полностью недоступен.

503 Service Unavailable означает, что сервер получил запрос, но прямо сейчас перегружен или восстанавливается. Для клиента оба требуют retry, но 502 обычно намекает на более серьезную проблему.

503 против 504 Gateway Timeout

504 Gateway Timeout возникает, когда реверс-прокси отправил запрос бэкенду, но тот не ответил в отведенное время (таймаут). Бэкенд не упал — он просто долго обрабатывает. Нет гарантии, что повторный запрос будет быстрее.

503 обычно означает, что сервер отвергает запросы, потому что не может их обработать. С Retry-After он дает вам расписание.

Для разработчика: обработайте оба кода в retry-логике, но с 504 будьте осторожны. Очень возможно, что операция уже выполняется на стороне сервера, и еще один идентичный запрос создаст дубликат.

Ошибка 503 и поисковые системы

Поисковые движки (Google, Яндекс, Bing) отлично знают, что означает 503. Когда краулер попытается загрузить страницу вашего сайта и получит 503, система поиска это понимает.

Поисковая система интерпретирует это как: сайт временно недоступен, переиндексирую позже. Робот не будет сразу пытаться переиндексировать весь сайт еще раз — это было бы DDoS на вас. Если в ответе есть Retry-After, краулер использует эту информацию для планирования следующей попытки загрузить страницу.

Если 503 держится дольше одного дня, поисковая система может (временно) понизить позицию вашего сайта в выдаче. Это не наказание — просто факт: сайт был физически недоступен, его невозможно было показать.

Совет владельцам: когда проводите плановое обслуживание, убедитесь, что вы возвращаете код 503 со строкой Retry-After, указывающей конец работ. Это сильно уменьшает риск потери позиций в поиске.

Что видят клиенты в браузере

Когда пользователь открывает браузер и попадает на сайт с ошибкой 503, он видит стандартную страницу браузера:

503 Service Unavailable
This server is temporarily unable to handle the request.

Или что-то подобное на русском:

503 Service Unavailable
Сервис временно недоступен

Многие браузеры показывают свою собственную страницу ошибки, если сайт не предусмотрел custom page.

Хороший веб-сайт имеет собственную красивую HTML-страницу для ошибки 503. На ней объяснение на простом языке: «Мы на техническом обслуживании. Вернемся ориентировочно в 15:00. Спасибо за терпение». Это успокаивает клиентов.

Для администратора: убедитесь, что вы отправляете правильный HTTP-код 503, custom error page и заголовок Retry-After. Это даст клиентам и поисковым роботам ясный сигнал о том, что проблема временная.