RSS
2 октября 2026

Как nginx выбирает бэкенд — и почему это может сломать сайт

Попался разбор, как nginx выбирает бэкенд — и это не про «хакеров», а про то, как система ведёт себя после сбоя. Я не просто читаю — я проверяю, как это работает у клиентов. И что важно: даже простые настройки могут сломать трафик. Не потому что «взломали», а потому что система не восстановилась.

О чём речь и почему это важно для сайта

Читал статью про балансировку в nginx — не просто так, а потому что это напрямую влияет на доступность сайта. Особенно если у клиента один бэкенд с весом 10, другой — с весом 1. Всё кажется стабильным, пока не случится сбой. Даже кратковременный. И тогда — трафик уходит на слабый сервер, хотя главный жив. Это не ошибка, а поведение, которое документация не объясняет.

Как это устроено — что тут вообще происходит

В nginx нет восьми разных алгоритмов. Есть один — smooth weighted round-robin. Остальные — просто фильтры, которые выбирают кандидатов. А победителя — выбирает тот же цикл. И тут ключевое: если бэкенд упал, его вес не просто падает — он просаживается по шагу. И если max_fails высок, то шаг мал. А если max_fails=0 — вес не восстанавливается вообще. Даже после того, как сбой прошёл. Это не баг — это поведение, которое не видно в логах.

Как понять, что это касается вашего сайта

Проверяю это первым делом, если в конфиге есть upstream с weight и max_fails. Особенно если бэкенд с высоким весом — и он хоть раз отваливался. Даже на секунду. Потому что в этом случае вес не восстановится, пока fail_timeout не истечёт. А если он на час — трафик будет идти на слабый сервер ещё долго. И никто не скажет, почему.

Что с этим делать

Сначала проверяю, как настроены веса и max_fails. Если max_fails=0 — меняю. Если веса высокие, а max_fails низкие — пересматриваю. И да, не просто «обновлю» — это может сломать. Делаю всё в плановом окне, с резервной копией. Потому что слепое обновление — типовая причина падений. А если что-то не так — возвращаю обратно.

Что здесь даёт поддержка

На поддержке эту задачу закрываю не «вчера», а в плановом окне. Сначала делаю резервную копию, потом проверяю, как работает балансировка после сбоя. Если нужно — пересматриваю max_fails и weight. И всё это — без риска для сайта. У нас в компании сертификаты PHP и MySQL у всех разработчиков. Это не про меня — это про то, что каждый, кто работает с кодом, знает, как не сломать систему. А ещё — приглашаю на бесплатный аудит сайта, чтобы проверить, как он ведёт себя после сбоя.

Как nginx выбирает бэкенд — и почему это может сломать сайт

← Все материалы