Не забудьте повысить шанс ответа клиенту, используя повторный запрос в L7 балансировке

Что если не пытаться тюнить пассивные проверки, а сразу перейти на активные?

В вашем примере есть гораздо более важный и тоже не очевидный из документации nginx нюанс — при proxy_next_upstream_tries 1 на второй бэкенд запросы не пойдут. За 1 считается уже попытка соединения с первым же сервером. Так что если вы хотите ограничить попытки например двумя серверами из четырех — ставьте proxy_next_upstream_tries 2. А proxy_next_upstream_tries 1 сработает по сути аналогично proxy_next_upstream off — запретит перебирать бэкенды и заставит отдать ответ от первого выбранного. Я проверял это поведение вживую.

Еще обязательно ставьте proxy_connect_timeout в значения не более 1 секунды. А параметры proxy_read_timeout и proxy_send_timeout считайте как общее время на весь запрос для клиента разделенное на количество попыток: proxy_next_upstream_timeout / proxy_next_upstream_tries. С округлением в меньшую сторону.

Из персонального опыта — люди не готовы ждать больше нескольких секунд, и уже после пяти секунд ожидания — некоторые просто закрывают сайт или приложение. Это видно по коду 499 в логах. Поэтому и proxy_next_upstream_timeout нет смысла делать больше тех же 10 секунд, а таймауты на бэкенд соответственно не должны превышать нескольких секунд. Лучше быстро попробовать несколько серверов и если кто-то живой — отдать ответ, а нет — вернуть клиенту ошибку. Чем ждать таймаута на его устройстве или пока терпение лопнет.

И вот еще очень полезная статья на тему high availability балансировки — https://m.habr.com/ru/company/oleg-bunin/blog/423085/