Pingveraблог ← Блог
Главная › Блог › Ошибка 503 на сайте: что это значит и что делать интернет-магазину

Ошибка 503 на сайте: что это значит и что делать интернет-магазину

8 ноября 2026 · 12 мин чтения

Ошибка 503 на сайте: что это значит и что делать интернет-магазину

Ошибка 503 Service Unavailable означает, что сервер сейчас не может обработать запрос: он перегружен или закрыт на обслуживание. В отличие от ошибки 500, код сайта при этом может быть исправен. 503 возникает, когда запросов больше, чем сервер готов принять, когда сработал лимит защиты от наплыва трафика или когда сайт оставлен в режиме обслуживания после неудачного обновления.

Первое, что нужно выяснить: кто именно отдал 503. Это может быть сам движок (WordPress во время обновления), веб-сервер nginx с ограничением частоты запросов, хостинг или сервис защиты от DDoS перед сайтом. От ответа зависит, где искать причину и кого звать. До «Чёрной пятницы» 27 ноября 2026 года меньше трёх недель, и 503 под нагрузкой в день распродажи обходится дороже, чем в обычный вторник.

Коротко

Что означает ошибка 503 и чем она отличается от 500, 502 и 504

Стандарт HTTP (RFC 9110, раздел 15.6.4) определяет 503 так: сервер сейчас не может обработать запрос из-за временной перегрузки или планового обслуживания, и ситуация, скорее всего, исправится через некоторое время. Сервер может прислать заголовок Retry-After. По разделу 10.2.3 того же стандарта, вместе с 503 он показывает, как долго сервис будет недоступен. Значение задают датой или числом секунд: Retry-After: 120 значит «повторите через две минуты».

Соседние коды подсказывают, где искать:

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

Почему это важно сейчас

Ноябрь приносит пики трафика: 11.11 через три дня, «Чёрная пятница» 27 ноября. Под нагрузкой срабатывают лимиты, которые весь год никто не замечал.

Справка Яндекс Вебмастера описывает 503 как ошибку из-за временной перегрузки или отключения сервера на обслуживание и советует при плановых работах быстро восстанавливать работу сервера. В той же справке сказано, что страница исключается из поиска, если сервер вернул роботу код 3XX, 4XX или 5XX. Вернуть её можно, только когда при новом обращении робот получит рабочий ответ, и на это может уйти до двух недель. Если робот не смог подключиться к сайту из-за ошибки сервера, сайт может полностью пропасть из поиска.

Google в документации для веб-мастеров пишет, что ошибки 5xx заставляют робота временно замедлить обход. Уже проиндексированные адреса сохраняются, но со временем удаляются, если сервер продолжает отвечать ошибкой. Для полного отключения сайта Google допускает 503 на 1–2 дня и называет такое отключение крайней мерой не дольше нескольких дней.

Ещё один сезонный источник 503: обновления. Перед распродажей магазины ставят свежие версии плагинов и модулей, а WordPress на время обновления переводит сайт в режим обслуживания.

Что делать при ошибке 503: порядок действий

  1. Поймите масштаб. 503 на всех страницах или только на части? У всех посетителей или у некоторых? Откройте сайт с телефона через мобильный интернет и с компьютера. Запишите точное время.
  2. Посмотрите, чья это страница. Если на странице ошибки логотип хостинга, CDN или сервиса защиты от DDoS, ответ сформировал не ваш сайт. Тогда первым делом пишите провайдеру и прикладывайте время и адреса. Если это голая строка «503 Service Unavailable» с подписью nginx, ищите правило в конфигурации веб-сервера.
  3. Проверьте режим обслуживания WordPress. Сообщение «Briefly unavailable for scheduled maintenance. Check back in a minute.» выводит функция wp_maintenance(): она отдаёт код 503 и заголовок Retry-After: 600. Режим включается файлом .maintenance в корне сайта. По исходному коду WordPress, режим считается активным, только если файл создан меньше 10 минут назад. Документация WordPress советует при зависшем обновлении проверить, остался ли файл, и удалить его через FTP или файловый менеджер хостинга, но только убедившись, что обновление больше не идёт. После удаления проверьте, что плагин или ядро обновились целиком.
  4. Проверьте, не закрыт ли сайт в 1С-Битриксе. В настройках главного модуля есть раздел «Публичная часть»: кнопка «Закрыть доступ пользователей» закрывает сайт для посетителей на время работ. Студия могла закрыть сайт на обновление и забыть открыть. Заглушку для закрытого сайта задают файлом /bitrix/php_interface/include/site_closed.php. Какой код ответа отдаёт закрытый сайт в вашей версии, проверьте сами в «Проверке ответа сервера».
  5. Найдите 503 в журнале веб-сервера. В access log найдите строки с кодом 503 и посмотрите, с каких адресов и на какие страницы шли запросы. Если 503 получают тысячи запросов с нескольких IP на страницы поиска и фильтров, это боты. Если 503 рассыпаны по обычным посетителям на оформлении заказа, лимит слишком строгий.
  6. Проверьте лимиты nginx. Директивы limit_req и limit_conn по документации nginx отвечают на отклонённые запросы кодом 503 по умолчанию (limit_req_status 503, limit_conn_status 503). При limit_req без параметра burst размер всплеска равен нулю: все запросы сверх заданной частоты сразу получают ошибку. Страница товара с десятком запросов к API за секунду упрётся в такой лимит у обычного покупателя.
  7. Разведите коды в журнале. Задайте для лимитов limit_req_status 429. Тогда 503 в журнале будет означать настоящую перегрузку или обслуживание, а 429 покажет, что сработало ограничение частоты. Разбирать инцидент станет проще.
  8. Проверьте ресурсы и защиту в 1С-Битриксе. Модуль «Проактивная защита» умеет «Контроль активности»: если пользователь за заданное число секунд сделает больше указанного числа хитов, его заблокируют и покажут страницу блокировки. Под распродажу проверьте пороги, чтобы покупатель, который быстро листает каталог, не попал под блокировку. Код ответа этой страницы проверьте на своём сайте.
  9. Если сайт перегружен по-настоящему, снимайте лишнюю нагрузку, а не всех посетителей сразу. Отключите тяжёлые фоновые задачи на время пика: импорт каталога, генерацию фидов, массовые рассылки. Что ещё подготовить к наплыву, описано в статье «Нагрузочное тестирование сайта перед „Чёрной пятницей“». Если трафик похож на атаку, начните с материала «Защита сайта от DDoS-атак».
  10. Пройдите путь покупки. Каталог, карточка, корзина, оформление, оплата, возврат с платёжной страницы. 503 под нагрузкой часто бьёт по самым тяжёлым шагам.
  11. Верните страницы в поиск. В Яндекс Вебмастере проверьте ключевые адреса в «Проверке ответа сервера» и отправьте исключённые страницы на переобход.

Если сайт не открывается совсем и непонятно, с чего начать, общий порядок есть в статье «Сайт лежит: что делать».

Таблица: источники ошибки 503 и как их проверить

Источник 503 Признак Кто проверяет Как проверить Когда
Режим обслуживания WordPress «Briefly unavailable for scheduled maintenance» на всех страницах Студия или администратор сайта Файл .maintenance в корне, журнал обновлений После каждого обновления
Закрытая публичная часть 1С-Битрикса Заглушка «сайт закрыт» для всех, кроме администраторов Студия на поддержке Настройки главного модуля, раздел «Публичная часть» После работ и релизов
Лимит частоты nginx 503 у части посетителей при всплеске трафика, подпись nginx Администратор сервера Access log, директивы limit_req, limit_conn Перед каждым пиком
Блокировка защитой CMS Страница блокировки у активных посетителей Студия Журнал вторжений, пороги «Контроля активности» Перед распродажей
Хостинг, CDN, защита от DDoS Страница ошибки с логотипом провайдера Владелец и провайдер Панель провайдера, обращение в поддержку При инциденте
Реальная перегрузка сервера 503 и медленные ответы везде, растёт загрузка процессора Администратор или хостинг Графики нагрузки, журналы, фоновые задачи Ежедневно в сезон

Артефакт: страница обслуживания и лимиты для nginx

Фрагмент конфигурации nginx для плановых работ. Он отдаёт посетителям и роботам 503 с Retry-After, но оставляет доступным robots.txt: Google предупреждает, что 503 на robots.txt блокирует весь обход.

# Режим работ: создать файл  touch /var/www/shop/maintenance.on
#              снять режим:  rm /var/www/shop/maintenance.on

# Лимит частоты для тяжёлых страниц поиска и фильтров
limit_req_zone $binary_remote_addr zone=search:10m rate=5r/s;

server {
    # ...

    error_page 503 /503.html;

    location = /503.html {
        root /var/www/errors;
        add_header Retry-After 3600 always;  # подсказка: повторить через час
        internal;
    }

    location = /robots.txt {
        try_files $uri =404;                 # robots.txt не закрываем
    }

    location /search/ {
        limit_req zone=search burst=10 nodelay;
        limit_req_status 429;                # отличать лимит от перегрузки
        # ...
    }

    location / {
        if (-f /var/www/shop/maintenance.on) {
            return 503;
        }
        # ...
    }
}

Значения rate и burst здесь для примера. Подберите их по своему журналу: посчитайте, сколько запросов в секунду делает обычный покупатель на этих страницах, и оставьте запас. Лимит на оформление заказа и оплату ставить не стоит.

План проверки на неделю до распродажи:

[ ] Найти в конфигурации nginx все limit_req и limit_conn, записать значения и страницы
[ ] Посчитать в access log 503 и 429 за последние 7 дней: кто и на каких страницах их получал
[ ] Проверить пороги «Контроля активности» в 1С-Битриксе (если модуль включён)
[ ] Убедиться, что в корне WordPress нет забытого файла .maintenance
[ ] Подготовить страницу обслуживания с Retry-After и открытым robots.txt
[ ] Спросить у хостинга и сервиса защиты от DDoS, при каких условиях они отвечают 503
[ ] Перенести импорт каталога, генерацию фидов и рассылки с часов пика
[ ] Заморозить обновления плагинов и модулей с 24 ноября до конца распродажи
[ ] Проверить ключевые страницы в «Проверке ответа сервера» Яндекс Вебмастера
[ ] Договориться, кто снимает режим работ и лимиты в день распродажи и у кого доступ

Пример разбора

Ситуация условная, собрана для иллюстрации.

Магазин на 1С-Битриксе запускает рассылку к 11.11. Через десять минут после отправки менеджеру пишут покупатели: «сайт выдаёт ошибку». Главная открывается, проверка доступности зелёная. Менеджер переходит по ссылке из письма на страницу акции с фильтрами и видит «503 Service Unavailable» с подписью nginx.

Администратор открывает access log. 503 получают обычные посетители, а не боты: адреса разные, страницы одни и те же, все пришли по ссылке из письма. Год назад для защиты фильтров от парсеров на этих страницах поставили limit_req с частотой 2 запроса в секунду и без burst. Страница акции при открытии делает несколько запросов к фильтру подряд, и второй же запрос получает отказ.

Лимит смягчили: добавили burst, а для отказов задали limit_req_status 429, чтобы в следующий раз отличить лимит от перегрузки. Проверку доступности добавили для страницы акции, а не только для главной. Как замечать такие провалы по потоку заказов, описано в статье «Магазин работает, а заказов нет».

Частые ошибки

Ограничения. Советы про nginx и журналы подходят сайтам, где у вас или у студии есть доступ к серверу. Магазины на Tilda и InSales работают на инфраструктуре платформы: при 503 там проверяют свои вставки и интеграции и пишут в поддержку платформы. Ни одна настройка не убирает риск 503 под пиком полностью. Она помогает узнать о нём раньше покупателей и быстро понять, какое правило сработало.

Вопросы и ответы

Ошибка 503 на сайте: проблема у меня или у сайта?

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

Сколько можно держать сайт в режиме обслуживания?

Чем меньше, тем лучше. Google допускает ответ 503 для полного отключения на 1–2 дня и советует передавать Retry-After. Если работы займут дольше, ограничьте функции: отключите корзину или оформление, а каталог оставьте доступным с кодом 200.

Как быстро страницы вернутся в Яндекс после 503?

По справке Яндекс Вебмастера, страница уходит из списка исключённых, когда робот при новом обращении получает рабочий ответ. Появиться в поиске она может в течение двух недель после того, как робот узнал об изменении. Ускорить процесс помогает отправка страниц на переобход.

Источники

Проверено: 8 ноября 2026 года.

Шаг «узнать о 503 раньше покупателей» можно автоматизировать. Pingvera раз в минуту проверяет доступность сайта по HTTP из нескольких регионов, подтверждает сбой повторными проверками и присылает алерт в Telegram, MAX, VK, на почту или в webhook. Для WooCommerce сервис следит и за потоком заказов: если сайт отвечает, а заказы перестали приходить, придёт отдельный алерт. Бесплатный тариф покрывает до 5 сайтов, разовую проверку можно сделать без регистрации на https://pingvera.ru/check.

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

Читайте также: Ошибка 502 на сайте: причины и что делать магазину · Ошибка 504 на сайте: причины и что делать магазину · Ошибка 500 на сайте: что это и как найти причину · Сайт лежит: что это значит и как быстро найти причину · Бесплатно проверить сайт.

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал