Autor: [Robert Zasilny](/autorzy/robert-zasilny) Ekspert bezpieczeństwa i compliance · Zweryfikowano Kwiecień 2026

1.  [Strona główna](/) ›
2.  [Baza wiedzy](/baza-wiedzy/) ›
3.  Nginx load balancer — konfiguracja

# 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

Algorytm

Dyrektywa

Kiedy używać

Round-robin

(domyślny, brak dyrektywy)

Stateless API, backendy identyczne, krótkie żądania

Least connections

`least_conn;`

Długie żądania (video, długi download), nierówne obciążenie

IP hash

`ip_hash;`

Sesje bez shared storage — klient zawsze na ten sam backend

Generic hash

`hash $request_uri;`

Cache affinity — ten sam URL zawsze na ten sam backend

Random two-choices

`random two least_conn;`

Duża liczba backendów (10+), alternatywa dla least\_conn

## 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

Czym różni się Nginx reverse proxy od load balancera? +

Reverse proxy to Nginx stojący przed jedną aplikacją (np. Node.js na porcie 3000) — przekazuje żądania z portu 80/443 do backendu, dodaje SSL, cache, kompresję. Load balancer to reverse proxy, który rozdziela ruch między kilka backendów (np. 3 instancje Node.js). Każdy load balancer jest reverse proxy, ale nie każdy reverse proxy jest load balancerem. W Nginx różnica to liczba serwerów w bloku upstream: 1 = proxy, 2+ = load balancer.

Jakie algorytmy load balancingu obsługuje Nginx? +

Nginx oferuje: round-robin (domyślny, po kolei), least\_conn (do serwera z najmniejszą liczbą aktywnych połączeń — dobry dla długich żądań), ip\_hash (stały backend per IP klienta — przydatny dla sesji bez shared storage), hash (custom key, np. $request\_uri), random (losowy z opcjonalnym two-choices). Weighted round-robin (weight=3) pozwala kierować więcej ruchu na mocniejsze serwery. Algorytm wybierasz w bloku upstream.

Czy darmowy Nginx ma health checks dla backendów? +

Darmowy Nginx (open source) ma pasywne health checks: max\_fails=3 fail\_timeout=30s — jeśli backend zwróci 3 błędy w 30 sekund, zostanie wykluczony na 30s. Aktywne health checks (okresowe requesty HTTP do /health) są dostępne tylko w Nginx Plus (płatny). W open source możesz użyć haproxy albo dodać external monitor (skrypt + API Nginx do usuwania backendów).

Jak obsłużyć SSL w load balancerze Nginx? +

Dwie strategie: (1) SSL termination — Nginx ma certyfikat Lets Encrypt, odszyfrowuje HTTPS i rozmawia z backendami po HTTP (szybsze, prostsze, standard). (2) SSL passthrough — Nginx używa stream module i przekazuje ruch TLS bez deszyfracji (rzadsze, potrzebne dla mTLS). W 99% przypadków wybierasz (1): Lets Encrypt na Nginx + HTTP na backendy w prywatnej sieci VPC.

## Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.

Contabo

VPS z dużym RAM i transferem — idealny Nginx load balancer dla 2-5 backendów

VPS LB

[Aktywuj rabat →](/out/contabo)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/contabo)

Mikrus

Tani VPS do testowania setupu load balancera przed produkcją

Tani VPS

[Aktywuj rabat →](/out/mikrus)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/mikrus)

CyberFolks

LiteSpeed hosting — alternatywa dla samodzielnego Nginx setupu

Managed

[Aktywuj rabat →](/out/cyberfolks)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/cyberfolks)

## Powiązane strony

-   [Nginx — konfiguracja virtual hostów](/baza-wiedzy/nginx-vhost-konfiguracja)
-   [Apache vs Nginx — porównanie](/baza-wiedzy/apache-vs-nginx-hosting)
-   [Varnish cache — konfiguracja VCL](/baza-wiedzy/varnish-cache-konfiguracja)
-   [Wszystkie artykuły](/baza-wiedzy/)