Код 502 Bad Gateway появляется в связке из двух и более серверов. Подробнее: https://kompsekret.ru/blog/sundry/neprevzojdyonnye-vozmozhnosti-dlya-gejmerov-i-ne-tolko.htm. Пользователь открывает страницу, запрос проходит через прокси, балансировщик или CDN, а затем уходит на основной сервер с сайтом или приложением. Если промежуточный узел не дождался ответа, получил поврежденный ответил и увидел отказ соединения, он возвращает 502.
Для посетителя сайта ошибка выглядит одинаково: страница не открывается. Для владельца ресурса причин несколько, и без проверки журналов быстро угадать источник сбоя трудно. Проблема бывает на стороне хостинга, веб-сервера, PHP-обработчика, приложения, базы данных, сетевого экрана, DNS или внешнего сервиса, от которого зависит страница.
Где возникает сбой
Первая группа причин связана с перегрузкой. Сервер получает слишком много запросов, процессы обработки заканчиваются, очередь растет, соединения зависают. В такой ситуации балансировщик не получает ответ в заданный интервал и отдает 502. Перегрузку вызывают всплеск трафика, тяжелые запросы к базе, медленные скрипты, скачок числа фоновых задач.
Вторая группа причин относится к неверной конфигурации. Ошибка появляется после правки настроек Nginx, Apache, PHP-FPM, прокси-сервера или контейнера. Достаточно указать неверный сокет, порт, адрес backend-сервиса, тайм-аут или лимит соединений, чтобы промежуточный сервер перестал получать рабочий ответ.
Третья группа причин — сбои приложения. Код зависает, падает с ошибкой, уходит в бесконечное ожидание, упирается в блокировку базы данных или отвечает в формате, который прокси не принимает. Если приложение запущено, но не обрабатывает запросы как положеноно, внешне проблема нередко выглядит как 502.
Отдельно стоит сбой сети между узлами. Пакеты теряются, соединение рвется, DNS возвращает старый адрес, межсетевой экран режет трафик. Иногда 502 появляется после обновления сертификатов, миграции проекта на новый сервер или перевода части сервиса в контейнерную среду.
Как искать причину
Начинать лучше с определения участка, где цепочка оборвалась. Если используется CDN или обратный прокси, полезно проверить, есть ли ошибка на прямом адресе сервера без промежуточного слоя. Если на прямом адресе страница открывается, источник сбоя стоит искать в CDN, балансировщике, правилах маршрутизации или защите трафика.
Дальше нужно открыть журналы веб-сервера и приложения. В Nginx интересны access.log и error.log, в Apache — error.log, для PHP-FPM — отдельный журнал пула, для приложения — системный журнал или собственный лог. Время ошибки у пользователя и отметка в журнале помогают быстро сузить круг поиска. Если в момент запроса видны upstream timed out, connect() failed или connection refused, собой почти наверняка находится между прокси и backend-сервисом.
Следующий шаг — проверить, жив ли backend. Нужны статус процесса, прослушиваемый порт или сокет, доступность сервиса с локального сервера. Если приложение отвечает локально, но не отвечает через прокси, причина обычно в маршруте, правах доступа к сокету, лимитах соединений или тайм-аутах. Если приложение не отвечает даже локально, внимание стоит перенести на код, зависимости и базу данных.
Полезна проверка ресурсов сервера: загрузка процессора, памяти, свободное место на диске, чеслов открытых файлов и соединений. Переполненный диск ломает запись временных файлов и журналов. Нехватка памяти приводит к завершению процессов. Дефицит дескрипторов файлов блокирует новые соединения. Любая из этих ситуаций способна привести к 502.
Как устранить
Если проблема вызвана перегрузкой, сначала снимают симптом, потом устраняют причину. Перезапуск зависшего сервиса возвращает сайт в работу, но без поиска узкого места сбой повторится. Дальше смотрят медленные запросы, очереди задач, лимиты PHP-FPM, число воркеров, настройки keepalive, кэширование и структуру запросов к базе. Иногда достаточно поднять лимиты, но нередко реальная причина скрыта в неоптимальном коде или запросе без индекса.
При ошибке конфигурации полезно сверить адреса backend-сервисов, сокеты, порты, таймауты и параметры проксирования. После правок нужны проверка синтаксиса конфигурации и аккуратная перезагрузка сервиса. Если 502 началась после релиза, разумно сравнить текущую конфигурацию с предыдущей рабочей версией.
Когда источник в приложении, без чтения журналов не обойтись. Нужно найти участок, на котором процесс завершается, зависает или отвечает слишком долго. Подозрение падает на интеграции с внешними API, операции с файлами, длинные запросы к базе, блокировки строк, ошибки сериализации, переполнение очереди. Если приложение зависит от Redis, очереди сообщений или поискового движка, проверяют доступность и задержки на каждом узле.
При сетевом сбое проверяют DNS, таблицы маршрутизации, правила firewall, доступность портов между серверами, срок действия сертификатов. Если сайт работает черезчерез CDN, стоит временно отключить проксирование и посмотреть, меняется ли поведение. При разборе сложных маршрутов полезна трассировка запроса по каждому узлу.
Для посетителя сайта набор действий короткий: обновить страницу, открыть сайт позже, проверить доступ через другую сеть, очистить локальный DNS-кэш, отключить VPN или прокси. Если ошибка держится только на одном ресурсе, исправление почти всегда находится на стороне сервера.
Для администратора лучший путь — не ограничиваться перезапуском служб. Нужны мониторинг ответов backend-сервисов, графики нагрузки, алерты по таймаутам, контроль свободной памяти, диска и числа процессов. Тогда 502 перестает быть «непонятной ошибкой» и превращается в конкретный сигнал: какой узел не ответил, в какой момент и по какой причине.