How Does Nginx Detect Unhealthy Servers? Passive vs Active Health Checks Explained

If a server in an upstream group fails, NGINX stops forwarding requests to it; to know whether a server is healthy, NGINX performs health checks.

Passive Check

When a request forwarded to a server fails or receives no response, NGINX marks the server as unavailable and stops sending traffic for a timeout period. By default, a single failure triggers a 10‑second pause, but the number of failures (max_fails) and the timeout (fail_timeout) can be configured, e.g.:

upstream backend {
    server backend1.example.com;
    server backend2.example.com max_fails=3 fail_timeout=30s;
    server backend3.example.com max_fails=2;
}

Active Check

NGINX can also actively probe each server at regular intervals, without waiting for real traffic. This is enabled with the health_check directive, typically together with a zone definition:

upstream backend {
    zone backend 64k;
    server backend1.example.com;
    ...
}
server {
    location / {
        proxy_pass http://backend;
        health_check;
    }
}

The default active check sends a request to “/” every 5 seconds; a failure, timeout, or non‑2xx/3xx status marks the server as down.

Customizing Active Checks

Interval and thresholds : health_check interval=10 fails=3 passes=2; checks every 10 seconds, requires three consecutive failures to mark down and two consecutive successes to mark up.

Check URI : health_check uri=/some/path; changes the request path from “/” to a custom one.

Response matching : Define a match block to require specific status codes, headers, or body content, e.g.:

match server_ok {
    status 200-399;
    header Content-Type = text/html;
    body !~ "maintenance mode";
}
...
health_check match=server_ok;

Using these settings, NGINX can reliably detect unhealthy backends and maintain high availability.