Клиентский запрос обрабатывается с заметной задержкой, после чего в журнале error.log Nginx фиксируется событие переключения между бэкенд-нодами: proxy_next_upstream triggered: http_502 fallback executed, client: ..., server: ..., upstream: "http://10.0.1.12:8080".

• Успешные ответы отдаются клиентам с повышенным p99 latency (время суммируется из таймаутов всех опрошенных серверов).
• При падении одной из нод нагрузка мгновенно перераспределяется на оставшиеся серверы пула.

1. Проверьте текущую конфигурацию директивы proxy_next_upstream в файлах виртуального хоста:

   location / {
       proxy_pass http://backend_pool;
       
       # Условия, при которых запрос перенаправляется следующему бэкенду:
       proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;
       
       # Ограничение количества попыток (включая первую):
       proxy_next_upstream_tries 3;
       
       # Суммарный лимит времени на все попытки:
       proxy_next_upstream_timeout 10s;
   }

2. Уменьшите тайм-аут на установление первичного соединения, чтобы переключение происходило мгновенно:

   proxy_connect_timeout 2s;

3. Изучите состояние упавшего upstream-сервера, зафиксированного в логах, и устраните первопричину сбоя на самом бэкенде.
4. Если бэкенд обрабатывает мутирующие запросы (POST/PATCH/DELETE), убедитесь, что параметр non_idempotent НЕ включен без необходимости, во избежание дублирования бизнес-операций.
5. Примените обновленные параметры: sudo nginx -s reload.