Открыть сервисСервис
Главная → Блог → Ошибка 502 Bad Gateway: причины и способы устранения

Ошибка 502 Bad Gateway: причины и способы устранения

502 Bad Gateway — код состояния HTTP, обозначающий, что сервер-шлюз или прокси-сервер получил недопустимый ответ от вышестоящего (внутреннего) сервера. Ошибка относится к классу серверных ошибок 5xx и указывает на сбой коммуникации между двумя компонентами инфраструктуры, а не на проблему на стороне клиента. Появляется в браузере в виде страницы с текстом «502 Bad Gateway» или «502 Bad Gateway — nginx».

Природа ошибки

Код 502 определён в стандарте RFC 7231 (секция 6.6.3). Согласно спецификации, 502 означает, что сервер, выступающий в роли шлюза или прокси, получил от upstream-сервера ответ, который не смог интерпретировать. Типичная цепочка запроса выглядит так:

  1. Клиент (браузер) отправляет запрос к домену.
  2. Запрос принимает внешний сервер — обычно nginx, Apache, балансировщик нагрузки или CDN.
  3. Шлюз пересылает запрос на внутреннее приложение (backend) — например, PHP-FPM, Node.js-процесс, Gunicorn, uWSGI.
  4. Если backend не отвечает, отвечает с некорректным форматом или обрывает соединение — шлюз возвращает клиенту 502.

Таким образом, ошибка почти всегда означает проблему между проксирующим сервером и backend-приложением.

Основные причины

Недоступность backend-процесса

Наиболее частая причина. Приложение-обработчик упало, не запустилось после перезагрузки или было убито по нехватке памяти. Примеры: остановлен сервис php-fpm, завершился процесс Gunicorn, упал веб-сервер Tomcat.

Переполнение пула процессов или очереди

Если пул воркеров (например, php-fpm pool) исчерпан, а очередь запросов переполнена, новые соединения отклоняются, и nginx возвращает 502. Аналогичная ситуация возникает при исчерпании лимита соединений на стороне backend.

Таймауты

Если приложение обрабатывает запрос дольше, чем отведено таймаутом прокси (параметры proxy_read_timeout, proxy_connect_timeout в nginx), соединение разрывается и клиент получает 502. Таймауты могут быть вызваны медленными запросами к базе данных, внешним API или сложными вычислениями.

Ошибки конфигурации

Некорректно указанный адрес backend (proxy_pass http://127.0.0.1:8080` при том, что приложение слушает другой порт), неправильные заголовки, несовместимые версии протоколов между прокси и backend.

Проблемы с сетью и DNS

Разрыв соединения между прокси и backend, блокировка портов файрволом, нерабочий DNS-запрос при попытке разрешить имя внутреннего сервера.

Перегрузка сервера

Высокая загрузка CPU, исчерпание оперативной памяти, переполнение диска (в частности, логами) приводят к тому, что backend перестаёт отвечать вовремя.

Сбои в CDN и балансировщиках

При использовании Cloudflare, AWS ELB, Google Cloud Load Balancing ошибка 502 может генерироваться самим балансировщиком, если ни один из бэкендов недоступен или не прошёл health check.

Диагностика

Первый шаг — проверка логов. В nginx ошибки записываются в /var/log/nginx/error.log и обычно содержат конкретную причину: «connect() failed», «upstream prematurely closed connection», «no live upstreams». Логи backend-приложения (журналы PHP, системный journalctl -u myapp, логи приложения) уточняют, что происходило на стороне обработчика.

Полезные команды:

  • systemctl status <сервис> — проверка состояния backend-сервиса;
  • ss -tlnp или netstat -tlnp — проверка, слушает ли процесс нужный порт;
  • curl -I http://127.0.0.1:8080` — прямой запрос к backend мимо прокси;
  • df -h и free -m — проверка диска и памяти;
  • tail -f /var/log/nginx/error.log — наблюдение ошибок в реальном времени.

Способы устранения

Перезапуск сервисов

systemctl restart nginx php-fpm — базовое действие, часто решающее проблему, если процесс просто завис.

Увеличение таймаутов

В конфигурации nginx:

`` proxy_connect_timeout 60s; proxy_read_timeout 120s; proxy_send_timeout 120s; ``

Расширение пула воркеров

В www.conf для php-fpm увеличиваются pm.max_children, pm.start_servers и связанные параметры. Для Gunicorn — число воркеров через параметр -w`.

Проверка конфигурации

nginx -t — проверка синтаксиса конфигурации перед перезагрузкой. Убедиться, что proxy_pass указывает на реальный адрес и порт backend.

Освобождение ресурсов

Очистка логов, расширение диска, настройка ротации через logrotate, оптимизация запросов к базе данных, кэширование тяжёлых операций.

Health check и автоперезапуск

Настройка мониторинга (Monit, systemd Restart=always, supervisord) для автоматического восстановления упавших процессов.

Если ошибка на стороне стороннего сайта

Когда 502 возвращается чужим сервисом, на стороне пользователя доступные действия ограничены: обновить страницу, очистить кэш DNS (ipconfig /flushdns в Windows, sudo systemd-resolve --flush-caches в Linux), временно отключить VPN или прокси, попробовать другую сеть. Дальнейшее устранение — задача администратора ресурса.

Источники

  • RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
  • Документация nginx: директивы модуля ngx_http_proxy_module
  • Документация PHP: настройка пула PHP-FPM
  • Документация Cloudflare: HTTP error codes

Похожие материалы

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru