502 Bad Gateway — что это и как исправить

Изображение: экран с сообщением «502 Bad Gateway» — пример ошибки шлюза между серверами.

Что такое 502 Bad Gateway

502 Bad Gateway — это HTTP-статус, который указывает на проблему в цепочке серверов: сервер, к которому обратился клиент (например, прокси или балансировщик нагрузки), получил некорректный или отсутствующий ответ от upstream‑сервера. В одном предложении: клиент связался с сервером A, а сервер A не смог корректно получить ответ от сервера B.

Определение в одну строку: 502 — это временная проблема связи между серверами, а не всегда «сломанный» сайт навсегда.

Важно: это часто не проблема на стороне пользователя, но бывает и локально (браузер, DNS, сеть).

Быстрые причины ошибки 502

• Временный сбой бэкенд‑сервера (упал сервис, перегрузка, рестарт).
• Неправильная конфигурация обратного прокси (NGINX, Apache, HAProxy).
• Ошибки в работе CDN или их неверная настройка.
• Сетевые таймауты между сервисами.
• Проблемы DNS или устаревший DNS‑кэш на клиенте.
• Локальные ограничения в сети (файрвол, политика организации).

Как пользователю быстро исправить 502 — шаги по приоритету

1. Обновите страницу (F5 или Ctrl+R). Иногда ответ приходит при повторном запросе.
2. Подождите 1–5 минут и попробуйте снова. Многие серверы восстанавливаются сами.
3. Очистите кэш браузера и куки. В Chrome: Меню → История → Очистить данные просмотра → Cached images and files.
   • Комментарий: кэш может хранить ошибки старого ответа.
4. Попробуйте другой браузер или приватное/инкогнито окно.
   • Это исключает расширения или плагинов как причину.
5. Сбросьте DNS‑кэш на компьютере:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd)
sudo systemd-resolve --flush-caches

6. Перезапустите маршрутизатор (роутер). Иногда помогает восстановить корректное сетевое соединение.
7. Попробуйте другую сеть (мобильный интернет, VPN). Если сайт работает в другой сети — проблема в локальной сети.
8. Проверьте статус сайта или аккаунты разработчиков в социальных сетях — возможно, они уже в курсе инцидента.

Примечание: большинство действий, перечисленных выше, безопасны и выполняются без знаний сервера.

Что делать владельцу сайта или девопсу — последовательный плейбук

Ниже — упорядоченный набор шагов для быстрого восстановления работы сайта и минимизации времени простоя.

Шаг 1 — подтверждение инцидента

• Попробуйте воспроизвести ошибку с разных точек (curl, браузер, внешний мониторинг).
• Соберите первые артефакты: метки времени, URL, тело ответа и заголовки.

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

curl -I -v https://example.com/path

Посмотрите строки с Server, Via, X-Forwarded-For, Retry-After и прочие заголовки.

Шаг 2 — проверка состояния бэкенда

• Проверьте, отвечает ли upstream‑сервер напрямую (bypassing proxy).
• Посмотрите логи приложений и системные логи (stdout/stderr, systemd, докер‑логи).
• Оцените CPU, память, нагрузку на I/O и число соединений.

Если сервис не отвечает: рестартуйте процесс/контейнер и наблюдайте логи.

Шаг 3 — проверка обратного прокси и конфигураций

• Пересмотрите таймауты (proxy_read_timeout, proxy_connect_timeout).
• Убедитесь, что upstream‑адреса указаны верно и не устарели.
• Проверьте лимиты соединений и очередь запросов.

Шаг 4 — CDN и балансировщик нагрузки

• Отключите временно кеширование CDN для отладки (bypass) и проверьте прямую связь с origin.
• Проверьте health checks и правила маршрутизации у балансировщика.

Шаг 5 — DNS и SSL

• Убедитесь, что DNS A/AAAA записи указывают на правильные IP.
• Проверьте истечение сертификатов и ошибки TLS в цепочке.

Шаг 6 — откат изменений и коммуникация

• Если ошибка появилась после деплоя, откатите изменения.
• Сообщите пользователям о статусе инцидента и ETA для восстановления.

Конкретные проверки и команды (чекист для инженера)

• Проверка доступности бэкенда:
  • curl напрямую на upstream.
  • Проверка health endpoint (например, /health или /status).
• Логи:
  • NGINX/Apache access и error логи.
  • Логи приложения и контейнера.
• Ресурсы: top, ps, docker stats, kubectl top.
• Сеть: traceroute, telnet , ss/netstat.
• CDN: временно отключить, проверить origin.

Типичные сценарии и когда перечисленные шаги не помогут

• Если upstream падает из‑за ошибки в коде — вернуть сайт не поможет простая перезагрузка прокси; нужен исправляющий деплой.
• Если проблема в внешнем API (третья сторона), вы сможете только применить временные кэш‑политики или degrade‑поведение.
• Если причиной служат DDoS‑атаки, необходимо подключать защиту на уровне провайдера или WAF.

Отладочная диаграмма: быстрая эвристика

flowchart TD
  A[Пользователь видит 502] --> B{Работает ли сайт для других?}
  B -- Да --> C[Проблема локальна: очистить кэш, сменить сеть]
  B -- Нет --> D[Проверить CDN/Прокси/Load Balancer]
  D --> E{Отвечает ли origin напрямую?}
  E -- Да --> F[Проверить CDN/Прокси конфигурацию]
  E -- Нет --> G[Проверить бэкенд: логи, рестарт, ресурсы]
  G --> H[Откатить последний деплой / исправить баг]
  F --> I[Промежуточные таймауты / обновить правила]
  I --> J[Временно отключить CDN / переключить трафик]
  J --> K[Мониторинг и уведомления]

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

Роль‑базированные чеклисты

• Для пользователя:

  • Обновить страницу.
  • Очистить кэш и куки.
  • Попробовать в другом браузере/сети.
  • Проверить статус сайта.

• Для разработчика приложения:

  • Проверить логи приложения.
  • Запустить health checks.
  • Откатить подозрительные изменения.

• Для системного администратора/инженера по инфраструктуре:

  • Проверить прокси/балансировщик.
  • Проверить соединения между серверами.
  • Оценить нагрузку и ресурсы.

• Для администратора CDN/поставщика облака:

  • Проверить конфигурацию кеширования и правила маршрутизации.
  • Проверить health checks и временно обойти CDN.

Критерии приёмки (как понять, что проблема решена)

• Пользовательский кейс: страница загружается без 502 в разных браузерах и сетях.
• Инфраструктурный кейс: health‑endpoint возвращает OK не менее 3 последовательных проверок.
• Мониторинг: метрики ошибок 502 вернулись к нормальному уровню и остаются стабильными в течение контролируемого окна (например, 30–60 минут).

Тесты и сценарии при автоматизированном тестировании

• Unit/E2E: симулировать таймаут upstream и проверить корректную обработку (должен возвращаться читаемый ответ/ошибка с логированием).
• Нагрузочное тестирование: повысить количество одновременных запросов и следить за ростом ошибок 502.
• Интеграционные тесты: проверить поведение при неответе внешнего API — fallback или кеширование.

Возможные альтернативы и стратегии смягчения

• Использовать локальный кеш на уровне прокси, чтобы обслуживать устаревшие, но полезные ответы.
• Настроить circuit breaker: при частых ошибках автоматически отключать проблемный upstream на некоторое время.
• Применить rate limiting и WAF для защиты от DDoS и плохих запросов.

Безопасность и конфиденциальность

• Логи и трассировки могут содержать персональные данные. Убедитесь, что доступ к логам ограничен и что они обрабатываются в соответствии с политикой конфиденциальности и местными требованиями (например, GDPR).
• Не публикуйте в открытых каналах headers с авторизацией или cookie. Маскируйте чувствительные поля в логах.

Советы по CDN и настройкам таймаутов

• Увеличьте proxy_read_timeout, если upstream делает тяжёлые вычисления.
• Настройте корректные health checks с адекватным интервалом и порогами.
• Отключение кеша CDN поможет отличить проблему CDN от origin.

Когда ждать и когда действовать немедленно

• Подождите: если ошибка появилась внезапно и покрывает малую долю трафика, возможно решит сам поставщик.
• Действовать немедленно: если 502 охватывает весь сайт, приводит к большим потерям или вызван после деплоя — следуйте плейбуку и откатам.

Примеры ошибок и контрпримеров

• Контрпример: сайт недоступен только внутри корпоративной сети — причина чаще всего в прокси/файрволе компании, а не в CDN.
• Контрпример: единичный 502 в логах при долгом ответе не значит, что весь сайт сломан — это нормально при пиковых задержках.

Мини‑методология диагностики (5 шагов)

1. Подтвердить проблему из разных источников.
2. Получить заголовки и тело ответа для анализа.
3. Проверить доступность upstream напрямую.
4. Проверить логи и ресурсы сервера.
5. Применить временное смягчение (откат, отключение CDN, увеличение таймаутов).

Краткий глоссарий (1‑строчная дефиниция)

• Upstream — сервер, к которому обращается прокси для получения данных.
• Proxy / Reverse proxy — промежуточный сервер, который принимает запросы от клиента и перенаправляет их на backend.
• CDN — сеть доставки контента, ускоряет доступ и может кешировать ответы.
• Health check — автоматическая проверка доступности сервиса.

Заключение

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

Если вы хотите, опишите ваш конкретный случай (URL, время, что вы уже пробовали) в комментариях — это упростит диагностику. Подпишитесь на релевантные каналы поддержки вашего хостинга или CDN, чтобы получать оповещения о проблемах вовремя.

Изображения в статье помогают ориентироваться: они отображают пример ошибки, интерфейс очистки кэша и выбор DNS.

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