Ошибки на сайте — это не «технические мелочи», которые можно поправить «когда будет время». Это прямые потери заявок: пользователь видит белый экран или «Bad gateway», закрывает вкладку и уходит туда, где всё работает. И самое неприятное — такие ошибки часто возникают в моменты пикового спроса: когда вы запустили рекламу, опубликовали пост или выросли позиции в поиске.

В этой статье разберём самые частые «страшные» ошибки 502 и 503, почему они появляются, что можно проверить быстро (без доступа к серверу) и как выстроить процесс так, чтобы инциденты ловились до того, как о них узнает директор.

Ошибка 502 Bad Gateway: что это и почему возникает

502 означает, что «передний» сервер (обычно nginx) не смог получить корректный ответ от приложения (например, gunicorn/Flask, PHP-FPM, Node) или от апстрима. Проще: сайт как витрина есть, но «внутри» тот, кто должен отдавать страницу, не ответил.

Самые частые причины 502:

  • Приложение упало или зависло (перезапуск помог бы, но никто не заметил).
  • Закончились ресурсы (CPU/память), процессы убились системой.
  • Долгие запросы: приложение не успевает ответить, прокси ждёт и сдаётся по таймауту.
  • Проблемы с базой данных: приложение живо, но база не отвечает.
  • Сетевые/инфраструктурные сбои: порт, сокет, контейнер, маршрутизация.

Если говорить языком бизнеса: 502 — это обычно «у нас что-то упало» или «у нас не хватает мощности».

Ошибка 503 Service Unavailable: чем отличается от 502

503 означает, что сервис временно недоступен. Иногда это «запланировано» (обслуживание, деплой), но чаще — следствие перегрузки или защиты.

Типовые причины 503:

  • Перегрузка по трафику: сервис ограничивает запросы, чтобы не умереть окончательно.
  • Рестарт/деплой: сервис ещё не поднялся или уже выключился.
  • Ограничения WAF/CDN/антибота: некоторые конфигурации возвращают 503 при подозрительном трафике.
  • Плановые работы у хостинга.

С точки зрения пользователя 502 и 503 одинаково плохи: заявка не отправится. Но по диагностике они часто ведут к разным действиям.

Быстрая диагностика: что проверить за 5 минут

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

1) Ошибка только у вас или у всех?
Откройте сайт с телефона на мобильном интернете (не Wi‑Fi). Если открывается — проблема может быть локальной (DNS/провайдер/кэш).

2) Не упала ли только одна страница?
Откройте главную и 2–3 внутренних URL. Если 502/503 только на одном разделе — возможно, упал отдельный компонент (например, база/интеграция).

3) Проверка формы заявки.
Иногда «сайт жив», но ломается отправка формы. Это тоже потери. Быстрое правило: после любого деплоя и после любой «правки маркетолога» форму надо тестировать руками.

4) Посмотрите, не было ли изменений.
Была реклама? Был деплой? Меняли DNS? Подключали виджеты? Если да — вероятность, что причина рядом, резко растёт.

5) Посмотрите, что пишет мониторинг/метрика.
Если у вас подключён мониторинг аптайма — он покажет время падения. Если нет — это хороший вывод на будущее.

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

Что делать, если вы владелец/маркетолог и сайт «падает»

План действий без паники:

  • Зафиксируйте время и симптомы: 502 или 503, какие страницы, с каких устройств проверяли.
  • Остановите трафик на мёртвую страницу: если крутится реклама — лучше поставить на паузу, чем оплачивать клики в пустоту.
  • Сообщите тех. специалисту/подрядчику и передайте краткий отчёт (время, URL, код ошибки, скриншот).
  • После восстановления — проверьте формы, цели в аналитике и ключевые посадочные страницы.
  • Сделайте разбор: почему упало и что поменять, чтобы не повторялось.

Если хочется выстроить это системно — в сопровождении сайта как раз есть идея: инциденты ловятся не «по звонку», а мониторингом и регламентом реакции.

Как сделать так, чтобы 502/503 ловились до вас

Нормальная схема состоит из трёх элементов.

1) Мониторинг доступности.
Проверка сайта каждые 1–5 минут с уведомлением в Telegram/почту. Если сайт лежит 20 минут, а вы узнаёте об этом от клиента — мониторинга нет (или он декоративный).

2) Регламент реакции (SLA).
Кто отвечает за инциденты? За сколько минут должен быть первый ответ? За сколько — восстановление? Это особенно важно, если сайт приносит заявки ежедневно.

3) Профилактика.
Обновления, бэкапы, проверка нагрузки, тесты формы и критичных страниц после изменений. Это тот самый слой «предотвратить», который обычно дешевле, чем «героически чинить ночью».

Эту логику удобно собирать через план поддержки сайта на год: он превращает хаотичные аварии в регулярный процесс.

Частые причины падений — и что обычно помогает

Ниже список, который чаще всего всплывает при разборе инцидентов.

  • Всплеск трафика + слабый сервер → масштабирование, кэш, CDN, оптимизация тяжёлых страниц.
  • Тяжёлые скрипты и виджеты → убрать лишнее, отложить загрузку, оптимизировать.
  • Проблемы с базой данных → настройка пула соединений, индексы, мониторинг, лимиты.
  • Неудачный деплой → прогрев/healthcheck, деплой без простоя, откат.
  • Отсутствие контроля изменений → список «что меняли» и обязательная проверка форм/страниц.

Часть этих причин напрямую связана со скоростью и стабильностью. Если вам кажется, что сайт «просто медленный», это часто предвестник будущих 502/503. См. скорость и Core Web Vitals.

Когда пора делать аудит, а не «поправить и забыть»

Если ошибки 502/503 повторяются, это уже не единичный сбой, а системная проблема. Тогда полезнее не «чинить симптом», а сделать разбор: инфраструктура, нагрузка, процессы, мониторинг, точки отказа.

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

Читайте также