Ошибка 502 Bad Gateway: что значит, почему возникает и как исправить

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

Пользователь видит «ошибка 502», сайт недоступен, а у команды начинаются вопросы: это проблема на нашей стороне, у хостинга, у CDN или у клиента? В этом руководстве разберем, почему возникает 502 bad gateway, как быстро диагностировать источник сбоя и что сделать, чтобы такие инциденты не повторялись.

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

Когда клиент открывает страницу, запрос часто проходит цепочку:

1. Браузер -> CDN/WAF
2. CDN/WAF -> Nginx/Ingress
3. Nginx -> приложение (Node.js, PHP-FPM, Python, Go)
4. Приложение -> база/кэш/внешние API

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

Часто это выглядит так:

• Nginx пишет upstream prematurely closed connection
• Ingress отдает 502 при падении пода
• Cloudflare возвращает 502, если origin недоступен или отвечает с ошибкой handshake

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

Обычно причина на стороне инфраструктуры, но для полноты рассмотрим обе стороны.

Причины на стороне сервера

• приложение упало или зависло (OOM, deadlock, panic)
• upstream не слушает нужный порт
• таймаут или разрыв соединения между reverse proxy и приложением
• неправильный протокол между узлами (например, proxy ожидает HTTP, а backend говорит FastCGI)
• перегрузка CPU/RAM/диска, из-за чего backend не успевает отвечать
• ошибка релиза (невалидный конфиг, миграция, несовместимая версия)
• проблемы DNS внутри кластера/сети
• некорректные keep-alive и лимиты соединений

Причины на стороне клиента (встречаются реже)

• агрессивные расширения/прокси/VPN ломают запрос
• устаревший DNS-кэш у клиента
• корпоративный фильтр подменяет/обрывает соединение

Если 502 массовая и воспроизводится из разных сетей, почти всегда это серверная проблема.

Быстрая диагностика 502: пошаговый чеклист

Ниже практичный порядок, который помогает локализовать проблему за 10-20 минут.

1) Подтвердите масштаб инцидента

• проверьте сайт из нескольких геолокаций
• сравните web, API и административные endpoints
• зафиксируйте момент начала сбоя

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

2) Посмотрите логи edge-сервера и reverse proxy

Для Nginx:

sudo tail -n 200 /var/log/nginx/error.log
sudo tail -n 200 /var/log/nginx/access.log

Ищите маркеры:

• connect() failed (111: Connection refused)
• upstream timed out
• no live upstreams
• recv() failed

3) Проверьте здоровье приложения напрямую

С сервера прокси выполните:

curl -I http://127.0.0.1:3000/health
curl -v http://app-service:3000/

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

4) Проверьте ресурсы и рестарты

top
free -h
df -h
dmesg | rg -i "oom|killed process"

Для Kubernetes:

kubectl get pods -n production
kubectl describe pod <pod-name> -n production
kubectl logs <pod-name> -n production --previous

Частая причина 502 bad gateway: pod уходит в restart loop, а ingress продолжает слать трафик.

5) Проверьте конфигурацию upstream

• правильный адрес/порт backend
• доступность всех нод в пуле
• синхронность деплоя конфигов
• соответствие протоколов (proxy_pass, fastcgi_pass, TLS termination)

Ошибка в одном символе в upstream-конфиге может дать 502 на весь сайт.

6) Проверьте внешние зависимости

Даже если веб-сервер жив, приложение может отвечать сбоем при недоступности:

• базы данных
• Redis
• внешних API
• очередей сообщений

Если upstream блокируется на зависимостях, reverse proxy часто фиксирует это как 502/504.

Что делать при ошибке 502: практические сценарии исправления

Сценарий 1: backend недоступен по порту

Симптомы: connection refused.

Что делать:

• убедиться, что процесс реально запущен
• проверить bind-адрес (0.0.0.0 vs 127.0.0.1)
• сверить порт в приложении и в прокси
• перезапустить сервис и проверить readiness

Сценарий 2: таймаут между прокси и приложением

Симптомы: upstream timed out.

Что делать:

• временно поднять таймауты (proxy_read_timeout, proxy_connect_timeout)
• убрать тяжелые синхронные операции из request-path
• вынести тяжелые задачи в очередь
• добавить кэш для дорогих запросов

Сценарий 3: релиз сломал часть инстансов

Симптомы: 502 после деплоя, часть запросов проходит.

Что делать:

• rollback на стабильную версию
• исключить проблемные ноды из балансировки
• сравнить конфиги/ENV между инстансами
• добавить canary и health-gates перед полным rollout

Сценарий 4: проблема на CDN/WAF

Симптомы: при прямом обращении к origin все ок, через CDN — 502.

Что делать:

• проверить origin health-check в панели CDN
• сверить TLS-настройки и сертификаты origin
• проверить firewall-правила и IP allowlist
• временно отключить проблемные правила WAF

Как предотвратить 502 в production

Ошибка 502 что делать — частый экстренный запрос. Но лучше сместиться от «тушения пожара» к профилактике.

1) Нормальные health-checks

• отдельный endpoint /health без тяжелой логики
• readiness зависит от критичных зависимостей
• liveness не должен флапать при кратковременной деградации

2) Таймауты и лимиты по умолчанию

• ограничьте время ожидания между слоями
• настройте circuit breaker для внешних API
• ограничьте очередь и concurrency

3) Безопасный деплой

• blue-green/canary
• автоматический rollback при росте 5xx
• прогрев кэша и соединений до переключения трафика

4) Наблюдаемость и алерты

Минимальный набор метрик:

• доля 5xx по каждому endpoint
• latency p95/p99
• количество рестартов приложения
• доступность upstream и зависимостей

CTA: настройте мониторинг HTTP, чтобы узнавать о 502 мгновенно

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

В Statuser можно:

• настроить HTTP-мониторинг ключевых URL
• проверять сайт из разных локаций
• получать уведомления в Telegram, Slack и email за секунды
• видеть историю инцидентов и время восстановления

Если хотите перестать реагировать постфактум на «ошибка 502», настройте мониторинг доступности и HTTP-статусов заранее: https://statuser.cloud.

Итог

502 bad gateway — не «абстрактная ошибка сервера», а конкретный симптом сбоя между слоями инфраструктуры. Быстрый анализ логов прокси, состояния upstream и ресурсов почти всегда приводит к источнику проблемы.

На практике часто путают 502 и 504: у 502 проблема в некорректном ответе от upstream, а при 504 upstream не успевает ответить в таймаут. Поэтому для полного покрытия сценариев полезно сразу держать под рукой разборы ошибки 503, ошибки 504, Cloudflare 52x и общий справочник HTTP-кодов.

Чтобы такие инциденты не становились сюрпризом, внедрите проактивный мониторинг HTTP и алерты на рост 5xx. Тогда о проблеме узнаете вы раньше пользователей, а не из обращений в поддержку.