Maxim Dounin Wrote:
-------------------------------------------------------
> Соединение с бекендом, какое бы оно ни было постоянное,
> периодически закрывается. Если это происходит в тот момент, когда
> nginx послал в соединение запрос - с точки зрения nginx'а это
> выглядит как ошибка.
>
> Чтобы nginx имел возможность в такой ситуации перепослать запрос
> ещё раз - стоит описать ещё один server в блоке upstream, можно
> тот же самый. Тогда вместо возврата 502 клиенту nginx пойдёт на
> следующий сервер в соответствии с настройкой proxy_next_upstream,
> и вернёт пользователю полученный ответ.

Похоже, что даже с одним server в блоке upstream уже происходит перепосылка запроса, судя по нескольким ответам, сначала 502, потом 200 в логах в $upstream_status, предположу, что такое поведение обеспечивается за счет max_fails. То есть можно игнорировать эти ошибки или может как-то можно их минимизировать, скажем, выставив keepalive_timeout на бэкенде больше, чем что-либо на прокси (правда не знаю что)?

> Задержки в $upstream_connect_time - это скорее всего либо потери
> пакетов, либо переполненная listen queue на бекенде (что на
> Linux'е при настройках по умолчанию выглядит как потеря
> SYN-пакета).

Вряд ли это переполненная очередь на бэкенде, там сейчас backlog=65535 и net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535 и net.ipv4.ip_local_port_range = 16384 65535. Такие же задержки возникают и на уровне upstream_header_time, например, upstream_header_time > 1, а upstream_connect_time=0.02. Бывает вообще только upstream_response_time > 1, а все остальные = 0.02. Это и странно, поскольку трафик и нагрузка на бэкенде небольшие.

Большое спасибо за ответы.