Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
Nginx Error 502: Bad Gateway (no live upstreams while connecting to upstream) Linux / DevOps

Nginx 502: no live upstreams while connecting — Причины и решение

Обновлено: 18.08.2026  ·  Официальная база знаний

Nginx выводит клиентам ошибку 502 Bad Gateway. В системном журнале фиксируется полная деградация пула серверов: no live upstreams while connecting to upstream, client: ..., server: ..., request: "GET / HTTP/1.1".

Параметр UpstreamЗначение по умолчаниюСледствие при ошибке
max_fails1 попыткаСервер помечается мертвым после первого же сбоя
fail_timeout10 секундСервер полностью исключается из балансировки на этот срок
Состояние пулаВсе ноды downNginx мгновенно отдает 502 без попытки связи
  • Все бэкенд-серверы из блока upstream были помечены Nginx как неработоспособные.
  • Запросы от клиентов перестают отправляться на бэкенды на время действия fail_timeout.
  1. Проверьте блок upstream в вашей конфигурации Nginx:
    upstream my_app {
        server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
        server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    }
  2. Увеличьте порог max_fails и уменьшите fail_timeout, чтобы временные сетевые флуктуации не выбивали все ноды из пула:
    upstream my_app {
        server 10.0.0.1:8080 max_fails=5 fail_timeout=10s;
        server 10.0.0.2:8080 max_fails=5 fail_timeout=10s;
    }
  3. Если все серверы действительно недоступны, восстановите работу самих приложений на бэкенд-хостах.
  4. Если бэкенды используют динамические DNS-имена (AWS ALB, Docker services), добавьте директиву resolver, чтобы предотвратить кэширование устаревших IP:
    resolver 127.0.0.53 valid=10s;
    
    location / {
        set $backend_pool "http://app.internal:8080";
        proxy_pass $backend_pool;
    }
  5. Примените конфигурацию: sudo nginx -s reload.
Архитектурная подсказка: Добавьте в upstream резервную ноду с параметром backup. На ней можно разместить легковесную страницу-заглушку (maintenance page) с кодом ответа 503, которая спасет пользователей от «сырой» 502 ошибки: server 127.0.0.1:8088 backup;.
Практический опыт инженера: Если пул состоит всего из 1 сервера, при первой же ошибке (даже случайном таймауте) Nginx выведет `no live upstreams` на 10 секунд. Всегда выставляйте `max_fails=0` для одиночных апстримов.

Частые вопросы (FAQ)

Почему Nginx выключает работающий сервер из пула?

Если сервер ответил ошибкой (например, 504 или TCP timeout) количество раз, превышающее max_fails, Nginx временно считает его мертвым и перестает слать трафик на период fail_timeout.

Что произойдет, если выставить max_fails=0?

Значение max_fails=0 полностью отключает учет неудачных попыток — Nginx будет считать сервер всегда живым и никогда не исключит его из ротации.

Как Nginx понимает, что сервер снова ожил?

По истечении интервала fail_timeout Nginx направляет на сервер один клиентский запрос. В случае успешного ответа сервер возвращается в статус рабочего.

Поддерживает ли бесплатный Nginx активные Health Checks?

В Nginx Open Source проверка работоспособности только пассивная (во время клиентских запросов). Активные health_check доступны в Nginx Plus или через сторонние модули (например, nginx_upstream_check_module).