Геннадий прав. Проблемма актуальная.
Nginx потому так и популярен, что разработчик прислушивается к
коммунити и реализовывает нужные механизмы,
в том числе и обработку ситуаций "кривых бекендов".
Сам себе злой буратино с писаниной на пхп - это всё идет лесом при
командной работе, где за бекенд и приложение отвечают и
разрабатывают совершенно другие люди.
Пример из жизни.
Nginx load-balancer с ip_hash , бекенды - два томката.
proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для
томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем,
нормально.
В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но
при этом продолжал принимать соединения.
Картина стала следующей: Юзер конектится на приложение (лоад-балансер
отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты,
потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и
послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой
страничке - ситуация повторяется.
Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял
бекенды на "дохлость", и если бекенд не отвечает - то не слать на
него запросы вообще, покуда он не подымется.
Фича востребованная. Если вам она не нужна, то это не значит, что
она не нужна вообще.
