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

Ошибка 502 Bad Gateway означает, что между посетителем и вашим сайтом стоит сервер-посредник (веб-сервер, прокси, CDN или балансировщик), и он получил от следующего звена недопустимый ответ или вообще не смог до него достучаться. Сам посредник работает, а вот приложение за ним упало, зависло или отвечает мусором. Стандарт описывает это так: сервер, выступая шлюзом или прокси, получил недопустимый ответ от входящего сервера, к которому обратился.

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

Что значит 502 простыми словами

Сайт редко отвечает посетителю напрямую. Обычно цепочка выглядит так: браузер → CDN или балансировщик → веб-сервер (чаще всего nginx) → приложение (PHP-FPM, Node.js, Python и т. п.) → база данных.

Код 502 появляется на стыке двух звеньев. Звено, которое видит посетитель, отправило запрос дальше и получило в ответ обрыв соединения, пустоту или неразборчивые данные. Тогда оно отдаёт посетителю 502: само звено живо, а то, что стоит за ним, сломалось. Описание кода есть и в документации MDN.

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

502 легко спутать с соседними кодами:

Почему сайт отдаёт 502

Чаще всего причина в одном из пяти мест.

Приложение не запущено или упало. Процесс PHP-FPM, Node.js или другой backend остановился: кончилась память, его убил менеджер процессов, он завис после обновления. Nginx пытается передать запрос, а принимать некому.

Приложение не успевает. Все рабочие процессы заняты долгими запросами, новые не обрабатываются. Это часто бывает при наплыве посетителей, тяжёлом отчёте, зависшем обмене с внешним сервисом.

Неверная связь между nginx и приложением. После смены версии PHP, переезда или правки конфигурации nginx может смотреть на сокет или порт, которых больше нет. Такие 502 появляются сразу после работ.

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

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

Как понять, где обрыв

Первый вопрос: ошибка у всех или только у вас. Откройте сайт с другого устройства и из другой сети, например с телефона через мобильный интернет. Если везде 502, дело в сервере. Если только у вас, смотрите кэш браузера, VPN, прокси. Подробный разбор такой развилки есть в статье Сайт не открывается: как понять, у кого проблема, а про случаи, когда сайт доступен не всем, в материале Сайт открывается не у всех.

Второй вопрос: чья страница показана. Если на экране оформление nginx или текст «502 Bad Gateway nginx», ошибку отдаёт ваш веб-сервер. Если страница в стиле CDN с названием провайдера, ошибка на уровне CDN, и сначала нужно выяснить, видит ли он ваш сервер.

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

Что делать, по шагам

Порядок рассчитан на владельца с доступом к хостингу или на студию, которая поддерживает сайт.

1. Убедитесь, что ошибка не локальная: откройте сайт с телефона через мобильную сеть и через внешнюю проверку доступности.
2. Зафиксируйте время начала и что менялось перед этим: обновление CMS, плагина, версии PHP, настроек хостинга, тарифа.
3. Откройте журнал ошибок веб-сервера. Для nginx это обычно error.log. Записи вроде «connect() failed» или «upstream prematurely closed connection» прямо указывают, что приложение недоступно или оборвало соединение.
4. Проверьте, запущено ли приложение: статус сервиса PHP-FPM, Node.js-процесса или контейнера. Если он остановлен, запустите и сразу прочитайте журнал: почему он упал.
5. Проверьте ресурсы: свободную память, место на диске, нагрузку на процессор. Переполненный диск — частая и неочевидная причина.
6. Если работает цепочка через CDN, временно проверьте сайт напрямую по адресу сервера (если это безопасно и настроено), чтобы отделить проблему CDN от проблемы источника.
7. Если причина в последнем изменении, откатите его. Разбираться в деталях можно после того, как сайт снова отвечает.

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

Если 502 вызвана таймаутом, полезно знать, как работает nginx: по документации, время ожидания ответа от проксируемого сервера (proxy_read_timeout) по умолчанию составляет 60 секунд. Но увеличивать таймаут как лекарство стоит осторожно: он скрывает медленный запрос, а не устраняет его. Если приложение отвечает слишком долго, это уже тема скорости сайта.

Чем опасна 502 для поиска и бизнеса

Для посетителя это тупик: страница не открывается, и он уходит к конкуренту. Для поисковых систем 5xx-ответы — сигнал, что у сайта проблемы с сервером. По справке Google, ошибки 5xx заставляют робота временно замедлить обход, а замедление пропорционально числу URL, которые отдают ошибку. Короткий сбой обычно безопасен, а затяжной может повредить индексации. Если вы уже заметили просадку, посмотрите, почему сайт мог пропасть из поиска Яндекса.

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

Как не пропустить следующий 502

Исправить текущий сбой — половина дела. Вторая половина — узнать о следующем раньше клиентов.

• Проверяйте доступность автоматически, с интервалом в несколько минут, а не вручную раз в день.
• Следите не только за главной, но и за страницами, где зарабатывает сайт: каталогом, корзиной, формой заявки.
• Настройте уведомления туда, где вы реально их увидите: почта, мессенджер, а не папка «Спам».
• Проверяйте ответ по содержимому, а не только по коду: страница может отдавать 200 и при этом показывать заглушку.
• После каждого обновления сервера, CMS или плагинов просматривайте журнал ошибок и открывайте ключевые страницы.

Как студии узнавать о падении раньше заказчика, описано в статье Сайт упал: как узнать об этом раньше клиента.

Как проверить сайт прямо сейчас

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

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