ip_hash
Тема дорожной карты · Nginx
Метод балансировки нагрузки ip_hash в Nginx направляет все запросы с одного IP-адреса клиента на один и тот же вышестоящий бэкенд-сервер, хэшируя первые три октета IPv4-адреса клиента (или полный IPv6-адрес), обеспечивая тем самым постоянство сессии без сticku-куков на уровне приложения. ip_hash настраивается добавлением директивы внутри блока upstream рядом со списком бэкенд-серверов, заменяя поведение round-robin по умолчанию: upstream backend { ip_hash; server 10.0.0.1; server 10.0.0.2; }. Эта стратегия балансировки нагрузки особенно полезна для приложений с состоянием, хранящих данные сессии локально на каждом бэкенде, а не в общем кэше или базе данных, поскольку ip_hash гарантирует, что вернувшийся пользователь всегда попадёт на сервер с его сессией. Одним из ограничений ip_hash является то, что клиенты за корпоративным NAT или крупными общими прокси попадают в одну хэш-корзину, что может концентрировать трафик на одном upstream и нарушать балансировку. Для современных приложений без состояния, использующих распределённое хранилище сессий, least_conn или round-robin с proxy_pass обычно предпочтительнее ip_hash в конфигурациях обратного прокси Nginx.
Как это работает
ip_hash распределяет трафик между upstream-backend. Методы: round-robin (дефолт), least_conn (наименьшее число активных соединений), ip_hash (sticky session по client IP), hash $request_uri consistent (consistent hashing для кешей). Помечайте backend как backup (backup) или down (down). Health checks: пассивный (помечает down после N сбоев через max_fails + fail_timeout); активный health check требует nginx-plus или third-party модулей.
Когда применять
least_conn лучше round-robin, когда время запросов варьируется (одни быстрые, другие медленные). ip_hash — только если backend реально нуждается в sticky session (stateless приложения нет). max_fails 3 fail_timeout 30s — для пометки нездоровых backend. Комбинируйте с health-эндпойнтом backend + реальным health check-тулом (Consul, k8s probes); пассивный health check грубый.
Типичные ошибки
Ловушки ip_hash: ip_hash + клиенты за корпоративным NAT (все на один backend); нет таймаутов — зависший backend никогда не помечен down; round-robin на backend разной capacity (перегружают меньший); вообще нет health check (сбойный backend получает трафик до ручного вмешательства).