Nginx load balancer — konfiguracja upstream, algorytmy i health checks

Opublikowano: 9 kwietnia 2026 · Kategoria: VPS

Jeden VPS nie wyrabia z ruchem? Zamiast kupować większy serwer (scale up), dodaj drugi i rozdziel ruch (scale out). Nginx od lat jest darmowym, wydajnym load balancerem — potrafi obsłużyć dziesiątki tysięcy połączeń na sekundę i rozdzielać je między backendy według kilku algorytmów. Oto kompletny przewodnik po konfiguracji.

Podstawowy setup — blok upstream

Konfiguracja load balancera to dwa bloki: upstream (lista backendów) oraz server z proxy_pass:

# /etc/nginx/sites-available/loadbalancer.conf

upstream backend {
    server 10.0.0.10:3000;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

# Aktywacja
sudo ln -s /etc/nginx/sites-available/loadbalancer.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Algorytmy load balancingu

Weights — nierówne serwery

Masz jeden mocny serwer i dwa słabsze? Użyj weight — wyższa waga = więcej ruchu. Przy weight=3 serwer dostanie 3× więcej requestów niż przy weight=1:

upstream backend {
    server 10.0.0.10:3000 weight=3;  # 60% ruchu
    server 10.0.0.11:3000 weight=1;  # 20% ruchu
    server 10.0.0.12:3000 weight=1;  # 20% ruchu
}

Pasywne health checks

Darmowy Nginx nie pinguje backendów aktywnie — czeka aż pojawi się błąd. Parametry max_fails i fail_timeout kontrolują kiedy wykluczyć backend:

upstream backend {
    # Jeśli 3 błędy w 30s — wyklucz na 30s
    server 10.0.0.10:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;

    # Backup — używany tylko gdy wszystkie główne padną
    server 10.0.0.99:3000 backup;

    # Tymczasowo wyłączony (np. podczas deploymentu)
    server 10.0.0.12:3000 down;
}

Co liczy się jako "błąd"? Domyślnie: timeout połączenia, reset, HTTP 5xx. Dodaj 404/403 do listy przez proxy_next_upstream:

location / {
    proxy_pass http://backend;
    proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    proxy_next_upstream_tries 3;
    proxy_next_upstream_timeout 10s;
}

SSL termination + redirect HTTP→HTTPS

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://backend;  # Backend mówi HTTP — Nginx odszyfrowuje
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
    }
}

Best practices

• Backendy w prywatnej sieci (VPC) — nigdy nie wystawiaj backendów na publiczne IP. Tylko load balancer jest dostępny z internetu.
• Stateless backendy — sesje trzymaj w Redis/DB, nie w pamięci procesu. Wtedy możesz używać round-robin zamiast ip_hash i łatwiej skalujesz.
• Keepalive do backendów — dodaj keepalive 32; w upstream (utrzymuje 32 otwarte połączenia) + proxy_http_version 1.1; + pusty proxy_set_header Connection "";. Zmniejsza overhead TCP handshake.
• Monitoring stub_status — włącz endpoint /nginx_status (z allow tylko z localhost) żeby śledzić aktywne połączenia i reqps.
• Zero-downtime deploy — używaj down na backendzie przed deployem, potem reload Nginx, deploy, usuń down, reload. Ruch nie trafia na aktualizowany serwer.

Uwaga: Sam load balancer jest nowym SPOF. Dla prawdziwego HA potrzebujesz 2 load balancery + keepalived (VRRP) z wspólnym virtual IP, albo zewnętrzny LB (Cloudflare, AWS ALB).

Najczęstsze pytania