Ошибки 502 и 504: сайт отваливается под нагрузкой

Сайт работал нормально, а потом вдруг перестал открываться. Вместо страницы — короткое сообщение с числом: 502 или 504. Через минуту всё снова работает, через час опять пропадает. Владелец звонит на хостинг, там говорят «у нас всё в порядке», звонит разработчику, тот отвечает «сайт не менялся». А обращения в это время не приходят, потому что человек, увидевший такую страницу, просто уходит к конкуренту.

Разберём, что означают эти числа, чем они отличаются от привычной ошибки 500, откуда берутся и что с ними делать — на языке, понятном владельцу бизнеса, а не только специалисту.

Что вообще происходит при открытии страницы

Чтобы понять природу этих ошибок, нужно представить, как устроена выдача страницы.

Когда посетитель открывает адрес вашего сайта, запрос попадает не сразу к программе, которая формирует страницу. Сначала его принимает веб-сервер — программа, которая стоит «на входе» и распределяет запросы. Она передаёт запрос дальше, обработчику: тот выполняет код сайта, обращается к базе данных, собирает страницу и отдаёт результат обратно. Веб-сервер получает готовую страницу и отправляет её посетителю.

То есть в цепочке минимум три участника: веб-сервер на входе, обработчик кода сайта и база данных. И ошибки 502 и 504 возникают именно на стыке между первым и вторым.

Ошибка 502 означает: веб-сервер обратился к обработчику, но получил в ответ мусор или не получил ничего — обработчик не отвечает или отвечает неправильно. Условно: «я передал ваш запрос дальше, но там никого нет».

Ошибка 504 означает: веб-сервер обратился к обработчику, тот начал работать, но не успел закончить за отведённое время. Условно: «я передал запрос, там взялись за дело, но ответа так и не дождались».

Разница принципиальная. В первом случае обработчик упал или недоступен. Во втором он жив, но работает слишком медленно.

Чем это отличается от ошибки 500

Ошибка 500 — самая известная. Она означает, что код сайта выполнялся и в нём произошла ошибка: обращение к несуществующему файлу, неверный запрос к базе, опечатка в коде после обновления.

Практическая разница вот в чём:

500 — обычно проблема в коде. Она возникает стабильно, на конкретной странице или после конкретного действия. Обновили систему управления сайтом, поставили модуль, поменяли настройку — и одна и та же страница перестала открываться. Ошибка воспроизводится: заходишь снова — снова ошибка.

502 и 504 — обычно проблема с ресурсами или инфраструктурой. Они возникают плавающе: сейчас есть, через минуту нет, у одного посетителя есть, у другого нет. Чаще всего это признак перегрузки, а не поломки.

Из этого следует и разный подход к поиску причины. Ошибку 500 ищут в логах ошибок сайта и в последних изменениях кода. Ошибки 502 и 504 ищут в потреблении ресурсов, в нагрузке и в настройках сервера.

Откуда берётся ошибка 502

Самые частые причины, по нашему опыту сопровождения сайтов:

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

Обработчик аварийно завершился. Скрипт занял слишком много памяти, упёрся в ограничение и был принудительно остановлен. Веб-сервер ждал ответа, а обработчик уже умер — получается 502. Типичный случай: массовая выгрузка каталога, генерация большого отчёта, обработка крупного файла.

Ошибка в настройках после переноса. Сайт переехал на новый сервер, пути или параметры подключения между веб-сервером и обработчиком указаны неверно. В этом случае 502 возникает не плавающе, а постоянно.

Обработчик перезапускается. После обновления версии обработчика или изменения его настроек происходит перезапуск, и в эти секунды все запросы получают 502. Если такое происходит регулярно — значит, обработчик падает и автоматически поднимается снова.

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

Откуда берётся ошибка 504

Здесь причина всегда одна по сути: что-то работает дольше отведённого времени. А вот почему именно — вариантов много:

Тяжёлый запрос к базе данных. Самая частая причина. База разрослась, индексы не настроены, и выборка, которая раньше занимала полсекунды, теперь занимает минуту. Особенно характерно для больших каталогов, для страниц с фильтрами и для админки.

База данных заблокирована. Одна операция изменяет большой объём данных и держит блокировку, остальные запросы ждут своей очереди и не дожидаются. Классический сценарий — импорт прайса поставщика в разгар рабочего дня.

Обращение к внешнему сервису, который не отвечает. Сайт при формировании страницы запрашивает данные откуда-то ещё: курс валют, остатки из учётной системы, данные службы доставки. Если внешний сервис завис, сайт ждёт его и сам отдаёт 504. Это очень коварная причина, потому что с самим сайтом всё в порядке.

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

Слишком много данных на одной странице. Страница фильтра, выводящая десять тысяч позиций без разбивки на части, может просто не успеть сформироваться.

Нехватка ресурсов сервера в целом. Если на сервере не хватает памяти, система начинает использовать диск вместо оперативной памяти, и всё замедляется в десятки раз.

Почему это стоит денег

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

Посетитель не возвращается. Человек, который увидел ошибку, в подавляющем большинстве случаев не пробует обновить страницу, а уходит на следующий сайт из списка. Обращение уходит конкуренту.

Формы не отправляются. Самое обидное. Человек заполнил заявку, нажал «отправить» и получил ошибку. Заявка не дошла ни до вас, ни до него. Он не станет заполнять второй раз.

Реклама сгорает впустую. Если сбои совпадают с показом объявлений, вы платите за переходы на неработающий сайт. Причём именно реклама часто и создаёт нагрузку, которая вызывает сбой, — получается замкнутый круг.

Поисковые роботы фиксируют недоступность. Если сайт регулярно отдаёт ошибки в момент обхода, страницы могут временно выпадать из индекса. Восстановление занимает недели.

Страдает репутация. Особенно если сбои случаются во время звонка клиента: «я на вашем сайте, у меня ошибка какая-то».

Что делать в первую очередь

Порядок действий, если сайт начал отдавать 502 или 504.

Шаг 1. Зафиксировать, когда это происходит. Не «иногда», а точно: даты, время, какие страницы. Здесь помогает сервис мониторинга доступности — он проверяет сайт каждую минуту и ведёт журнал. Без такого журнала разговор с хостингом получается беспредметным: они говорят «у нас всё работало», и возразить нечем.

Шаг 2. Посмотреть, совпадает ли это с чем-то. Сопоставьте время сбоев с посещаемостью в Яндекс.Метрике, с запуском рекламы, с расписанием фоновых задач, с временем выгрузки прайсов. Очень часто картина проясняется сразу: сбои каждый день в 3 часа ночи — значит, дело в задаче по расписанию; сбои в момент пиковой посещаемости — значит, не хватает лимита процессов.

Шаг 3. Посмотреть логи. Журнал ошибок веб-сервера покажет, что именно произошло: «превышено время ожидания» или «соединение с обработчиком разорвано». Журнал медленных запросов к базе покажет, какие именно запросы тормозят. Это работа для специалиста, но именно она даёт точный ответ вместо гаданий.

Шаг 4. Проверить нагрузку. Панель управления хостингом обычно показывает потребление процессорного времени, памяти и число процессов. Если графики упираются в потолок в моменты сбоев — причина найдена.

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

Как это чинится

Решения зависят от причины, но набор типовых мер такой.

Кэширование. Самая действенная мера при перегрузке. Готовые страницы сохраняются и отдаются посетителям без пересборки. Нагрузка на обработчик и базу падает в разы. Настраивается на уровне системы управления сайтом и сервера.

Оптимизация запросов к базе. Добавление индексов, переписывание тяжёлых выборок, разбиение больших списков на страницы. Часто именно это решает проблему полностью.

Ограничение времени ожидания внешних сервисов. Если сайт обращается куда-то наружу, у такого обращения должен быть жёсткий лимит — например, три секунды. Не ответили — страница формируется без этих данных, а не зависает.

Перенос тяжёлых операций в фон и на ночь. Импорт прайсов, пересчёт цен, генерация отчётов не должны выполняться в момент запроса посетителя. Их место — в задачах по расписанию, в часы минимальной посещаемости.

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

Увеличение лимитов и переход на более мощный тариф. Иногда сайт просто вырос из своего хостинга. Переход с общего хостинга на выделенный сервер решает вопрос, но это стоит денег, поэтому имеет смысл делать это после оптимизации, а не вместо неё.

Обновление системы управления сайтом. Старые версии часто работают заметно медленнее и содержат неоптимальные запросы.

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

Как это связано с продвижением 3 в 1

Технические сбои бьют по всем трём каналам, из которых приходят обращения.

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

Яндекс.Справочник и карточка в Яндекс Бизнесе. Человек, пришедший из карточки на сайт и увидевший ошибку, обычно возвращается к списку и звонит следующей компании. Здесь важно, чтобы в карточке был указан телефон и он был кликабельным: тогда часть людей позвонит, не заходя на сайт, и сбой их не заденет. Это, кстати, аргумент в пользу полноты карточки: она работает как запасной канал приёма обращений, когда сайт лежит.

2ГИС. То же самое. Заполненная карточка с телефоном, услугами и ценами позволяет получить обращение вообще без перехода на сайт.

Отсюда практический вывод: полностью заполненные карточки — это не только источник новых обращений, но и страховка на случай технических проблем. Компания, у которой все три точки в порядке, теряет во время сбоя часть обращений, а не все.

Что измерять

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

Мониторинг доступности. Внешний сервис, который проверяет сайт раз в минуту и присылает уведомление при сбое. Даёт объективный журнал: сколько минут в месяц сайт был недоступен.

Цели в Яндекс.Метрике на отправку форм. Провал в графике целей часто совпадает с техническими проблемами — это способ заметить, что форма перестала работать, до того как об этом скажет клиент.

Дублирующее уведомление о заявках. Заявка должна приходить не только на почту, но и в мессенджер или СРМ — Битрикс24 или амоСРМ. Если один канал не сработал, второй подстрахует.

Коллтрекинг. Коллтач или Каллибри покажут, не просел ли поток звонков в дни сбоев.

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

Как это предотвратить

Ошибки 502 и 504 почти всегда предсказуемы. Что делает их редкими:

Регулярный мониторинг. Не «узнаём от клиентов», а автоматические уведомления.

Запас по ресурсам. Тариф с запасом на пиковые нагрузки, а не впритык к средним.

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

Кэширование как правило, а не как экстренная мера.

Расписание тяжёлых задач на ночь.

Регулярное обслуживание базы данных. Очистка накопившегося мусора, оптимизация таблиц, контроль размера.

Тестовая копия сайта. Все обновления сначала проверяются на копии, а потом переносятся на рабочий сайт.

Ответственный за техническое состояние. Человек или компания, к которой можно обратиться в момент сбоя, а не искать разработчика, который делал сайт четыре года назад.

Итог

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

Цена вопроса измеряется не в минутах простоя, а в потерянных обращениях: посетитель, увидевший ошибку, уходит к следующей компании, а заполненная и не отправившаяся форма не вернётся никогда. Именно поэтому мониторинг, дублирующие каналы приёма заявок и заполненные карточки в Яндекс Бизнесе и 2ГИС стоят потраченного на них времени.

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