Ошибка 502

Ошибка 502: почему шлюз не получил корректный ответ

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

Краткий ответ

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

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

Диагностику нужно вести с самого прокси: проверить его журнал ошибок, затем обратиться к upstream напрямую из того же окружения. Проверка с ноутбука может пройти, хотя контейнер прокси не видит приложение.

Как проявляется проблема

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

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

Почему возникает ошибка 502

Ключевой вопрос: смог ли прокси установить соединение и получить корректный HTTP-ответ от приложения.

Процесс приложения не запущен

Прокси направляет запрос на адрес, где никто не принимает соединение.

Что обычно видно

Отказ в соединении.
Контейнер остановлен или постоянно перезапускается.
Порт не прослушивается.

Неверный адрес или порт upstream

После изменения инфраструктуры конфигурация прокси указывает на старое имя, порт или сеть.

Что обычно видно

Прямой запрос на правильный адрес работает.
Ошибка появилась после переноса сервиса.
Имя не разрешается внутри контейнера.

Неправильный протокол

Прокси пытается говорить по HTTP с TLS-портом либо наоборот.

Что обычно видно

Ошибки рукопожатия или неверного заголовка.
Приложение доступно по HTTPS, а upstream настроен как HTTP.
Ошибка появилась после включения TLS между сервисами.

Приложение преждевременно закрывает соединение

Процесс принимает запрос, но падает, перезапускается или закрывает сокет до полного ответа.

Что обычно видно

В прокси указано преждевременное закрытие.
В приложении есть паника или аварийное завершение.
Ошибка зависит от конкретного тяжёлого запроса.

Сетевой отказ между компонентами

Контейнеры, узлы или правила межсетевого экрана не позволяют установить стабильное соединение.

Что обычно видно

Таймаут соединения.
Запрос работает только с одного узла.
После изменения сети сервисы перестали видеть друг друга.

Некорректный ответ upstream

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

Что обычно видно

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

Как диагностировать 502 по шагам

Не начинайте с увеличения таймаутов. Сначала установите, на каком этапе разрывается цепочка.

Шаг 1

Определите, кто вернул 502

Посмотрите заголовки ответа и журналы фронтового сервера. Это может быть Nginx, балансировщик, CDN или другой шлюз.

Какой компонент первым записал 502.
Какой upstream был выбран.
Есть ли идентификатор запроса.

curl -i -sS https://example.ru/

# Показать только заголовки
curl -I -sS https://example.ru/

Шаг 2

Проверьте upstream напрямую с прокси

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

Разрешается ли имя сервиса.
Открыт ли нужный порт.
Совпадает ли протокол.

curl -i -sS http://app:8080/health

# Проверка TCP-порта
nc -vz app 8080

Шаг 3

Проверьте состояние приложения

Убедитесь, что процесс не только запущен, но и готов принимать запросы.

Нет ли цикла перезапусков.
Проходит ли проверка готовности.
Не исчерпаны ли память и соединения.

Шаг 4

Сопоставьте журналы прокси и приложения

Запись прокси показывает симптом, журнал приложения — возможную внутреннюю причину.

Отказ в соединении означает одно, преждевременное закрытие — другое.
Есть ли запрос в журнале приложения.
Совпадает ли время с перезапуском.

Шаг 5

Проверьте конфигурацию после изменений

Сравните рабочую и текущую конфигурацию, особенно адрес, порт, схему и имена сервисов.

Применена ли новая конфигурация.
Не остался ли старый адрес в одном из узлов.
Проходит ли проверка конфигурации перед перезагрузкой.

502, 503 и 504: в чём разница

Коды близки, но указывают на разные типы отказа.

Код	Смысл	Типичный пример	Главная проверка
502	Шлюз получил некорректный ответ	Соединение отклонено или закрыто	Процесс, адрес, порт, протокол
503	Сервис временно не готов	Нет готовых экземпляров или обслуживание	Готовность и нагрузка
504	Шлюз не дождался ответа	Upstream отвечает слишком долго	Задержка, зависимость, таймаут

Что делать в зависимости от роли

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

Посетителю сайта

502 обычно нельзя исправить настройками браузера.

Повторите запрос позже.
Не дублируйте оплату или отправку формы без проверки результата.
Сообщите владельцу адрес и время.

Владельцу сайта

Нужно проверить, работает ли само приложение.

Проверьте несколько критичных URL.
Посмотрите состояние контейнеров и узлов.
Уточните, были ли изменения прокси или сети.

Инженеру

Проверяйте цепочку из окружения прокси.

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

Как мониторить ошибку 502

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

Отдельные проверки маршрутов

Разные URL могут обслуживаться разными приложениями. Один успешный маршрут не исключает 502 на другом.

История статусов и времени ответа

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

Уведомления об инциденте

При повторяющемся неуспешном ответе команда получает сигнал и затем сообщение о восстановлении.

Сопоставление с внутренними метриками

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

Ограничения внешней проверки

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

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

Ошибка 502 означает, что сайт полностью выключен?

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

Поможет ли увеличение таймаута?

Только если upstream действительно отвечает дольше допустимого времени. При отказе в соединении, неверном порте или падении процесса увеличение таймаута ничего не исправит.

Почему прямой запрос к приложению работает, а через домен — нет?

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

Почему 502 появляется только на одном сервере?

Один узел может иметь старую конфигурацию, недоступную сеть или неисправный экземпляр приложения.

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

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

Считает ли UpWatch 502 ошибкой?

Да. В текущей реализации любой HTTP-статус 400 и выше делает проверку неуспешной.

Связанные материалы

Перейдите к отдельной инструкции, если код ответа или тип отказа уже известен.

Ошибка HTTP 500

Внутренняя ошибка приложения или сервера.

Ошибка 503

Сервис временно не готов принимать запросы.

API недоступен

Диагностика DNS, соединения, TLS и таймаутов.

Мониторинг сайта

Регулярная внешняя проверка критичных URL.

Узнавайте о 502 до жалоб пользователей

Добавьте критичные URL в UpWatch, чтобы фиксировать ответы прокси, историю инцидента и момент восстановления.

Создать аккаунт Как работает мониторинг

Мониторинг сайтов, API и фоновых задач.

info@upwatch.ru