upstream fail_timeout

Maxim Dounin mdounin на mdounin.ru
Вс Окт 23 16:31:17 UTC 2011


Hello!

On Sun, Oct 23, 2011 at 05:55:06PM +0300, Sergey Kobzar wrote:

> On 10/23/11 17:49, Maxim Dounin wrote:
> >Hello!
> >
> >On Sat, Oct 22, 2011 at 06:08:43PM +0300, Sergey Kobzar wrote:
> >
> >[...]
> >
> >>Есть одна проблема при max_fails>  1 - клиенту будет одана
> >>стандартная error page, N раз (пока Nginx не выкинет дохлый бэкенд
> >
> >Это не имеет никакого отношения ни к max_fails (т.к. даже при
> >max_fails == 1 клиенту будет отдана ошибка, если таки ошибка
> >произойдёт), ни собственно к обсуждаемому вопросу (как
> >обрабатывать ошибки на фронтенде, и обрабатывать ли вообще, -
> >вопрос совершенно отдельный).
> >
> >>из пула). В принципе это не критично при высокой нагрузке, т.к.
> >>пострадают всего пару человек. Решение - описать custom error page 2
> >>раза - на фронтенде + на backup сервере.
> >
> >Я лично предпочитаю использовать proxy_intercept_errors, это
> >позволяет централизованно конфигурировать страницы ошибок на
> >фронтенде/ах.  Но, по понятным причинам, такой подход не всегда
> >применим.
> 
> Максим, а можно немного подробней про proxy_intercept_errors с
> примером? Из документации не совсем все понятно.


Директива proxy_intercept_errors позволяет перехватывать 4xx, 5xx 
ошибки, возвращённые бекендом, и выдавать вместо них то, что 
задано с помощью директивы error_page.

Пример:

    location / {
        proxy_pass http://backend;
        proxy_intercept_errors on;
        error_page 404 /404.html;
    }

    location = /404.html {
        # serve static file here
    }

Если бекенд ответит 404, то клиенту уйдёт ответ 404 с телом из 
/404.html (а не то, что прислал бекенд).
 
> Если бэкенд сдулся окончательно, то что от него можно требовать?

Если бекенд сдулся окончательно - то proxy_intercept_errors роли 
не играет.  Он имеет смысл только в том случае, если бекенд ещё 
способен вернуть ответ.

Maxim Dounin



Подробная информация о списке рассылки nginx-ru