Ошибка 503 Service Unavailable означает, что сервер временно не может обработать запрос, — в отличие от 500-й ошибки, это не всегда указывает на баг в коде. Разберём основные причины 503 на сайтах 1С-Битрикс и порядок диагностики от самых частых причин к менее очевидным.
Перегрузка PHP-FPM или недостаток воркеров
Самая частая причина 503 на нагруженном сайте — исчерпание пула доступных PHP-воркеров: все процессы заняты обработкой текущих запросов, а новые запросы веб-сервер не может передать на обработку и возвращает 503 вместо ожидания. Проверяется через логи PHP-FPM (обычно в них видна метка о переполнении пула) и статус процесса самого PHP-FPM.
Превышение лимита одновременных подключений к MySQL
Если PHP-FPM ждёт ответа от базы данных дольше обычного (медленный
запрос, блокировка таблицы), воркеры накапливаются в ожидании,
создавая тот же эффект перегрузки, хотя корень проблемы —
не в самом PHP, а в базе. Диагностика через
SHOW PROCESSLIST в MySQL показывает, какие запросы
реально выполняются долго и блокируют остальные.
Нужна помощь с Битрикс?
Активная работа мастера обновления
Кратковременная 503 при заходе на сайт во время выполнения обновления системы — штатное поведение: Битрикс временно переводит сайт в режим техобслуживания на время применения изменений структуры базы данных. Если 503 держится значительно дольше ожидаемого времени обновления, стоит проверить, не завис ли сам процесс обновления, а не считать это продолжающейся нормальной работой.
Файл технических работ .maintenance
Наличие файла bitrix/php_interface/.maintenance
сознательно переводит сайт в режим 503 для всех, кроме
администраторов, — этот механизм используют сами разработчики
и деплой-скрипты при выкладке крупных изменений. Если сайт
неожиданно недоступен без явной причины, первым делом стоит
проверить, не остался ли этот файл после незавершённого деплоя.
Срабатывание защиты от DDoS на уровне хостинга
Некоторые хостинги автоматически включают режим ограничения (в том числе 503-ответ части запросов) при резком всплеске трафика, распознанном как потенциальная атака, — даже если это ложное срабатывание на легитимный всплеск интереса (например, после рекламной публикации). Проверка через панель хостинга или обращение в поддержку помогает отличить эту ситуацию от реальной технической проблемы на стороне приложения.
Проверка через лог nginx
tail -f /var/log/nginx/error.log
Лог веб-сервера часто содержит явное указание причины —
upstream timed out говорит о слишком медленном PHP,
no live upstreams — о полной недоступности PHP-FPM,
что уже прямо указывает направление дальнейшей диагностики вместо
догадок.
Диагностика через нагрузочное тестирование
Если 503 воспроизводится нерегулярно и только под нагрузкой, контролируемый нагрузочный тест на копии сайта (не на боевом проекте с реальными посетителями) позволяет найти точный порог, при котором сервер перестаёт справляться, — это переводит проблему из категории "иногда бывает" в измеримую метрику, по которой можно планировать масштабирование ресурсов.
Частые ошибки
- Проверка начинается с кода приложения, а не с логов сервера. Реальная причина часто видна сразу в логе nginx или PHP-FPM без чтения кода.
- Забытый файл .maintenance после незавершённого деплоя. Сайт недоступен без видимой технической причины.
- 503 списывается на "временный сбой" без диагностики первопричины. Проблема с высокой вероятностью повторится при следующем всплеске нагрузки.
Итог
503 Service Unavailable почти никогда не указывает на баг в прикладном коде напрямую — типичные причины: исчерпание PHP-воркеров, медленные запросы к базе, забытый файл технических работ или срабатывание защиты хостинга от всплеска трафика. Диагностику стоит начинать с логов nginx и PHP-FPM — они обычно прямо указывают направление, а не гадать по симптомам на стороне приложения.