health_check
Тема дорожной карты · Nginx
Проверки работоспособности в Nginx подтверждают, что вышестоящие бэкенд-серверы доступны и возвращают корректные ответы, прежде чем балансировщик нагрузки направляет к ним реальный трафик, предотвращая маршрутизацию запросов к отказавшим или деградировавшим узлам. В Nginx с открытым исходным кодом пассивные проверки работоспособности выполняются автоматически: когда вышестоящий сервер возвращает заданное число последовательных ошибок (управляется параметрами max_fails и fail_timeout в блоке upstream), Nginx помечает его как недоступный на указанный период. Nginx Plus предоставляет активные проверки работоспособности через директиву health_check;, которая периодически отправляет синтетические запросы каждому бэкенду с настраиваемым интервалом и исключает серверы, не прошедшие проверку, не дожидаясь отказа реальных пользовательских запросов. Для Nginx с открытым исходным кодом сторонний модуль ngx_http_upstream_check_module добавляет аналогичный функционал активных проверок, настраивая их через check interval=3000 rise=2 fall=3 timeout=1000; внутри блока upstream. Надёжная конфигурация проверок работоспособности необходима для любого развёртывания обратного прокси или балансировщика нагрузки Nginx, требующего высокой доступности и автоматического переключения при отказе.
Как это работает
health_check распределяет трафик между 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 грубый.
Типичные ошибки
Ловушки health_check: ip_hash + клиенты за корпоративным NAT (все на один backend); нет таймаутов — зависший backend никогда не помечен down; round-robin на backend разной capacity (перегружают меньший); вообще нет health check (сбойный backend получает трафик до ручного вмешательства).