gwynn Wrote:
-------------------------------------------------------
> Решилось таким способом:
>
> upstream detected_upstream {
> server 192.168.1.1:8010;
> server 192.168.1.1:8010 weight=5;
> }
>
> Т.е. добавил еще один
> сервер, ссылающийся на тот
> же хост.
> За 20 дней после такого
> решения, полет нормальный,
> проблема не появлялась
> больше


Спасибо, обязательно попробую ваш вариант если не помогут мои изыскания. Я же решил попробовать функцию

syntax: proxy_next_upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_404 | off] [...]
default: proxy_next_upstream error timeout
context: http, server, location

Директива определяет, в каких случаях запрос будет передан следующему серверу:

* error — произшла ошибка соединения с сервером, передачи ему запроса или чтения заголовка ответа сервера;
* timeout — произошёл таймаут во время соединения с сервером, передачи ему запроса или чтения заголовка ответа сервера;
* invalid_header — сервер вернул пустой или неверный ответ;
* http_500 — сервер вернул ответ с кодом 500;
* http_502 — сервер вернул ответ с кодом 502;
* http_503 — сервер вернул ответ с кодом 503;
* http_504 — сервер вернул ответ с кодом 504;
* http_404 — сервер вернул ответ с кодом 404;
* off — запрещает передачу запроса следующему серверу;
http://sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_next_upstream

Если ngnix всегда ищет следующий апстрим (фича), то установка флага proxy_next_upstream off по идее должно отключить такое поведение. Два одинаковых хоста в апстриме наверно достигают того же эффекта, но как то кривенько смотрится.

Подождем 20 дней.