Ошибка 502 Bad Gateway — что значит и как исправить

Код 502 Bad Gateway означает, что сервер-посредник — шлюз или прокси — получил от сервера за ним некорректный ответ или не получил его вовсе. Классическая схема: nginx принял запрос, передал его приложению, а приложение упало или ответило неправильно. Для владельца сайта 502 — сигнал, что веб-сервер жив, но бэкенд, который готовит страницы, не справляется.

Что означает код 502

502 — серверная ошибка из группы 5xx, описанная в RFC 9110. Стандарт формулирует её так: сервер, выступая шлюзом или прокси, получил недопустимый ответ от вышестоящего сервера. Код возвращает именно посредник: nginx перед PHP-FPM, балансировщик нагрузки перед группой серверов, CDN перед origin-сервером.

Смежные коды легко перепутать. 500 Internal Server Error отдаёт сервер, который сам обрабатывал запрос и столкнулся с ошибкой; 502 отдаёт посредник, не получивший нормальный ответ от обработчика. При 504 Gateway Timeout бэкенд не ответил за отведённое время, а при 502 соединение отклонено или ответ пришёл, но оказался сломанным. 503 Service Unavailable сервер возвращает сам, когда перегружен или закрыт на обслуживание. У Cloudflare для проблем с origin есть и собственные коды — ошибка 520 и ошибка 521. Позиция 502 среди остальных кодов — в полном списке кодов ответа HTTP.

Считает ли Tracker.ru 502 падением

Да. Успешной Tracker.ru считает только проверку с кодом 2xx. Ответ 502 помечает сайт недоступным, тип ошибки — «HTTP-ошибка», и вы получаете уведомление на email, в Telegram или по webhook. Проверки идут из нескольких регионов, поэтому случайный сетевой сбой по пути легко отличить от настоящего падения бэкенда: его фиксируют все регионы сразу. Периоды недоступности попадают в статистику аптайма. Если же бэкенд молчит, а посредника перед ним нет, проверка завершится не кодом 502, а ошибкой таймаута.

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

Упал процесс приложения. PHP-FPM, Node.js или Python-сервис не запущен, и nginx получает отказ соединения на сокете или порту. Самая частая причина 502.
Закончились worker-процессы PHP-FPM. Лимит pm.max_children исчерпан, очередь переполнена, новые запросы отклоняются.
Нехватка памяти. Система убила процесс приложения (OOM-killer). После автоперезапуска сайт оживает — до следующего пика нагрузки.
Перезапуск при деплое. Пока приложение стартует, шлюз несколько секунд получает отказы. Отсюда короткие 502 после каждого релиза.
Некорректный ответ бэкенда. Слишком большие заголовки, не влезающие в буферы прокси (proxy_buffer_size), или оборванный на середине HTTP-ответ.
Ошибка конфигурации шлюза. proxy_pass в nginx указывает не на тот порт или сокет — например, после переезда приложения.
Сбой между CDN и origin. Cloudflare или другой CDN не получил корректный ответ от вашего сервера и отдал посетителям 502 со своей страницей ошибки.

Что проверить владельцу сайта

Откройте онлайн-проверку кода ответа своего сайта — она покажет фактический ответ сервера без кэша браузера и без регистрации.
Убедитесь, что процесс приложения запущен: PHP-FPM, Node.js, Python-сервис. Если он падает — перезапустите и изучите его логи.
Загляните в error-лог веб-сервера (например, /var/log/nginx/error.log). Строки «connect() failed» или «upstream prematurely closed connection» прямо называют виновника.
Проверьте память сервера: частые 502 после пиков трафика — типичный след сработавшего OOM-killer.
Если сайт за CDN — запросите origin напрямую, минуя CDN. Отвечает нормально — проблема в связке CDN и origin; не отвечает — на самом сервере.
Если 502 началась после релиза или правки конфигурации — откатите изменение и проверьте снова.

Как часто встречается 502 на практике

По данным проверок Tracker.ru, код 502 встречается примерно в 0,04% проверок (по данным на июль 2026). Кажется, что немного, но среди серверных ошибок 5xx это самый частый код: он опережает и 500, и 503. Причина — в популярности связки «прокси + приложение»: почти любой современный сайт работает за nginx, балансировщиком или CDN, и сбой бэкенда превращается именно в 502.

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

Почему 502 появляется на минуту-две и исчезает сама?

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

Чем 502 отличается от 504 Gateway Timeout?

При 504 Gateway Timeout бэкенд не успел ответить за отведённое время — запрос выполняется слишком долго. При 502 посредник получил ответ быстро, но некорректный, либо соединение было отклонено. Упрощённо: 504 — «бэкенд молчит слишком долго», 502 — «бэкенд ответил ерундой или не принял соединение».

Сайт за Cloudflare показывает 502 — проблема у Cloudflare или у меня?

Почти всегда у origin-сервера: CDN лишь транслирует ошибку, которую получил от него, или не смог добиться корректного ответа. Запросите сервер напрямую, минуя CDN: если 502 воспроизводится — чините бэкенд. Сбои на стороне самого Cloudflare случаются, но редко и видны на его публичной статус-странице.