К содержанию

Главная · Блог · Ошибка 502 Bad Gateway: что значит и что делать

Оставить заявку

Новый формат

Ошибка 502 Bad Gateway: что значит и что делать

502 Bad Gateway значит: прокси или шлюз (часто nginx/CDN) не получил корректный ответ от upstream-сервера (PHP, Apache, приложение).

Ниже — частые причины и что проверить. Это не «штраф SEO», но простой сайт режет трафик и индексацию, пока ошибка висит.

Поделиться
Telegram VK

Типичные причины

Упал или не отвечает PHP-FPM или приложение, истёк таймаут upstream, сервер перегружен, сломан конфиг прокси, сбоит CDN или SSL-соединение между прокси и бэкендом.

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

Часто после:

  • деплоя и смены конфига;
  • скачка трафика;
  • зависших плагинов CMS;
  • исчерпания лимитов хостинга.

Проверьте себя

Мини-тест: 502

Два вопроса.

1 502 Bad Gateway обычно про…
2 Маскировать 502 редиректом…

Как исправлять

Проверьте статус хостинга и мониторинг. Смотрите логи nginx или Apache и PHP. Перезапуск пула PHP или контейнера выполняют по регламенту; недавно установленный плагин CMS отключают, если связь с ошибкой подтверждается.

Не начинайте с случайной смены DNS, версии PHP или десятка настроек. Сначала локализуйте слой: CDN, веб-сервер, приложение, база или внешний API. Так исправление не замаскирует причину и не создаст новую.

Порядок:

  • подтвердить 502 снаружи (`curl -I`);
  • логи шлюза и приложения;
  • нагрузка CPU/RAM/диск;
  • таймауты upstream;
  • откат последнего изменения.

Веб-сервер Логи сервера

Практика

Чеклист при 502

Пока сайт лежит.

0 / 7 готово

Профилактика

Нужны мониторинг доступности, адекватные лимиты, staging перед релизом, кэш и очередь для тяжёлых задач, а также запас по ресурсам.

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

Для SEO-команды:

  • алерт, если главные URL отдают 5xx;
  • не путать 502 с фильтром поиска;
  • после восстановления — проверка индексации ключевых страниц.

Диагностика по логам и метрикам

В журнале прокси найдите запрос по времени, URI и идентификатору запроса, затем сопоставьте его с логом приложения. Сообщения о connect() failed, premature response, timeout или исчерпании воркеров укажут, куда копать дальше.

Метрики помогают отличить разовый сбой от системной проблемы. Смотрите загрузку CPU и памяти, место на диске, число процессов, время ответа базы и очередь запросов до, во время и после инцидента.

Для обращения к разработчику или хостеру подготовьте:

  • точный URL и время с часовым поясом;
  • код ответа и частоту повторения;
  • фрагменты логов без паролей и токенов;
  • список последних релизов и изменений конфигурации.

Что проверить после восстановления

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

Если 502 была заметна роботам и посетителям долго, проверьте отчёты вебмастеров и динамику обхода. Не отправляйте на переобход тысячи URL автоматически: сначала убедитесь в стабильном ответе сервера.

Закройте инцидент, когда:

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

Частые вопросы

502 — это проблема SEO?

Косвенно: робот и пользователи не видят страницу. Долгий даунтайм вреден. Сама цифра 502 — про инфраструктуру.

Чем отличается от 500 и 504?

500 — ошибка приложения. 504 — шлюз не дождался ответа (таймаут). 502 — ответ от бэкенда битый/отсутствует.

Может ли быть у посетителя, а у меня нет?

Да: локальный кэш, другой POP CDN, краткий сбой. Проверьте с инкогнито и внешнего монитора.

Поможет ли смена DNS сразу?

Редко первая помощь. Сначала логи, статус бэкенда, лимиты PHP/воркеров.

Нужен ли редирект?

Нет. Чинят сервер/приложение, а не маскируют 502 редиректом.

Нужно ли очищать кэш при 502?

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

Когда обращаться в поддержку хостинга?

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

Сайт отдаёт 502?

Поможем с диагностикой хостинга и логов — чтобы страницы снова открывались.

Обсудить задачу