Reverse proxy na VPS: Nginx, Caddy czy Traefik – co wybrać do własnych aplikacji?

Masz jeden VPS, kilka aplikacji i po godzinie zaczyna się bałagan: jedna usługa działa na porcie 3000, druga na 8080, panel administracyjny na 9000, a WordPress jeszcze inaczej. Da się to wystawić bezpośrednio do internetu, ale to proszenie się o chaos. Użytkownik nie powinien wchodzić na domena.pl:3000, a API nie powinno wisieć publicznie na przypadkowym porcie tylko dlatego, że tak uruchomił się kontener.

[ Ruch z internetu: port 80/443 ] 
               │
               ▼
      ┌─────────────────┐
      │  REVERSE PROXY  │ (Nginx / Caddy / Traefik)
      └────────┬────────┘
               │
      ┌────────┼────────┐ (Kierowanie ruchu wewnątrz VPS)
      ▼        ▼        ▼
 ┌────────┐┌────────┐┌────────────┐
 │Next.js ││  API   ││ Analytics  │
 │ :3000  ││ :4000  ││   :8080    │
 └────────┘└────────┘└────────────┘

Reverse proxy rozwiązuje ten problem elegancko: na zewnątrz wystawiasz tylko standardowe porty 80 i 443, a całą resztę ruchu kierujesz wewnątrz serwera do właściwych aplikacji. Dzięki temu możesz mieć:

• app.domena.pl dla aplikacji Next.js,
• api.domena.pl dla backendu,
• analytics.domena.pl dla statystyk,
• status.domena.pl dla status page,
• panel.domena.pl dla narzędzia self-hosted.

Użytkownik widzi normalne adresy HTTPS. Ty widzisz porządek w konfiguracji, firewallu i logach.

Po co reverse proxy, gdy masz kilka aplikacji na jednym VPS?

Najprostszy scenariusz wygląda tak: kupujesz VPS, instalujesz Node.js, Dockera albo PHP, uruchamiasz pierwszą aplikację i wszystko działa. Problem zaczyna się przy drugiej i trzeciej usłudze. Każda chce słuchać na własnym porcie, każda potrzebuje domeny, a każda publiczna ekspozycja portu zwiększa powierzchnię ataku.

Reverse proxy działa jak recepcja na wejściu do budynku. Odbiera ruch z internetu i decyduje, gdzie go wysłać:

app.domena.pl       → localhost:3000
api.domena.pl       → localhost:4000
analytics.domena.pl → localhost:8080
status.domena.pl    → localhost:9000

Z zewnątrz otwarte zostają głównie:

80/tcp  — HTTP, zwykle do przekierowania na HTTPS
443/tcp — HTTPS
22/tcp  — SSH, najlepiej ograniczony i zabezpieczony

Reszta usług może działać lokalnie, w sieci Dockera albo na 127.0.0.1. To ważne, bo panel administracyjny, baza danych, Redis, Prometheus czy prywatne API nie muszą być dostępne dla całego internetu.

Największe korzyści są bardzo praktyczne:

• jedna domena i wiele subdomen zamiast losowych portów,
• SSL/TLS w jednym miejscu, bez konfiguracji certyfikatów w każdej aplikacji osobno,
• łatwiejszy firewall, bo nie trzeba otwierać 3000, 8080, 9000 i kolejnych portów,
• czytelniejsze logi, bo wejście do systemu przechodzi przez jeden punkt,
• łatwiejsze migracje, bo aplikację można przenieść z portu 3000 na 3001, a użytkownik dalej widzi ten sam adres.

Jest tu jeszcze jeden ważny element: SSL termination. To reverse proxy przyjmuje połączenie HTTPS, odszyfrowuje ruch i przekazuje go dalej do aplikacji już po wewnętrznej sieci serwera. Dzięki temu aplikacja Node.js, PHP czy Go nie musi sama obsługiwać certyfikatów TLS ani nasłuchiwać na uprzywilejowanym porcie 443. To porządkuje architekturę: proxy zajmuje się ruchem z internetu, aplikacja robi swoje.

Najczęstszy błąd początkujących: wystawianie każdej usługi jako http://adres-ip:port. Działa przez chwilę, ale potem pojawia się problem z HTTPS, CORS, ciasteczkami, webhookami, OAuth i panelami logowania. W praktyce lepiej od razu przyjąć zasadę: publicznie widoczne są domeny, nie porty aplikacji.

Minimalna kolejność działania powinna wyglądać tak:

1. Ustaw rekordy DNS A lub AAAA dla subdomen na adres VPS.
2. Otwórz w firewallu tylko potrzebne porty, zwykle 80 i 443.
3. Uruchom aplikacje lokalnie albo w Dockerze.
4. Skonfiguruj reverse proxy dla każdej subdomeny.
5. Dopiero potem dodawaj cache, rate limiting, kompresję, nagłówki bezpieczeństwa i monitoring.

Nie zaczynałbym od rozbudowanej automatyzacji, jeżeli na serwerze stoją dwie aplikacje. Najpierw porządek w routingu. Automatyzacja ma sens wtedy, gdy często dodajesz lub usuwasz usługi.

Nginx, Caddy i Traefik — różnice w konfiguracji, SSL i Dockerze

Wybór między Nginx, Caddy i Traefik nie sprowadza się do pytania „który jest najlepszy?”. Lepsze pytanie brzmi: ile masz aplikacji, jak często je zmieniasz i czy pracujesz głównie w Dockerze.

Nginx to klasyk. Jest szybki, dojrzały, dobrze opisany i obecny w ogromnej liczbie poradników. Nadaje się do prostych stron, WordPressa, API, aplikacji Node.js i bardziej złożonych konfiguracji. Daje dużą kontrolę, ale wymaga ręcznej konfiguracji.

Kompletny przykład dla aplikacji działającej lokalnie na porcie 3000:

server {
    listen 80;
    server_name app.domena.pl;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        # Podstawowe nagłówki proxy
        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;

        # Obsługa WebSocketów (kluczowa dla Next.js / Live Preview)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

To jest konfiguracja dla portu 80, czyli HTTP. W produkcji zwykle dochodzi jeszcze blok dla 443 z certyfikatem SSL albo konfiguracja wygenerowana przez Certbota. Sam fragment proxy_pass nie wystarczy, jeżeli chcesz mieć pełne HTTPS.

Nginx wybrałbym, gdy:

• hostujesz WordPressa albo klasyczne strony PHP,
• chcesz mieć największą liczbę poradników i gotowych rozwiązań,
• potrzebujesz precyzyjnej kontroli nad nagłówkami, cache, limitami i routingiem,
• masz bardzo mały VPS, na przykład 512 MB RAM, i liczy się każdy megabajt,
• nie przeszkadza Ci ręczne trzymanie konfiguracji w plikach.

Na małej maszynie Nginx z Certbotem często będzie najbardziej przewidywalny. Caddy i Traefik są pisane w Go i potrafią zużywać więcej pamięci niż minimalistyczna konfiguracja Nginxa, zwłaszcza gdy reverse proxy obsługuje SSL termination, automatyczne certyfikaty, dashboard, dynamiczne wykrywanie usług albo dodatkowe middleware. Przy kilku spokojnych aplikacjach różnica może nie mieć znaczenia. Przy VPS-ie z 512 MB RAM ma.

Caddy jest po drugiej stronie skali. Jego przewaga to prostota. W wielu przypadkach konfiguracja reverse proxy mieści się w kilku liniach, a HTTPS działa automatycznie, gdy Caddy zna nazwę domeny i serwer jest osiągalny z internetu na wymaganych portach.

Przykład:

app.domena.pl {
    reverse_proxy 127.0.0.1:3000
}

api.domena.pl {
    reverse_proxy 127.0.0.1:4000
}

To jest ogromna różnica dla osoby, która nie chce spędzać wieczoru na walce z certyfikatami. Caddy automatycznie obsługuje HTTPS, więc odpada sporo pracy przy pierwszym wdrożeniu. Trzeba jednak rozumieć warunek: domena musi wskazywać na serwer, a porty 80 i 443 muszą być dostępne. Jeżeli VPS stoi za NAT-em, Cloudflare Tunnel, prywatną siecią albo nietypowym firewallem, automatyka może wymagać dodatkowej konfiguracji.

Caddy wybrałbym, gdy:

• chcesz szybko wystawić kilka aplikacji pod subdomenami,
• zależy Ci na prostym SSL bez ręcznego Certbota,
• masz mały lub średni VPS i nie chcesz utrzymywać rozbudowanej konfiguracji,
• serwer nie jest częścią większej infrastruktury kontenerowej.

Przy Dockerze trzeba uważać na jedną rzecz: proxy i aplikacja muszą się widzieć w sieci Dockera. Jeżeli Caddy działa w kontenerze, a aplikacja też działa w kontenerze, samo wpisanie 127.0.0.1:3000 zwykle nie zadziała tak, jak początkujący oczekuje. 127.0.0.1 w kontenerze Caddy oznacza sam kontener Caddy, a nie kontener aplikacji.

Poprawne podejście to wspólna sieć, na przykład:

docker network create proxy

A potem podpięcie Caddy i aplikacji do tej samej sieci. Wtedy można kierować ruch po nazwie usługi, np.:

app.domena.pl {
    reverse_proxy app:3000
}

Brak publicznego wystawiania portów działa tylko wtedy, gdy reverse proxy i aplikacja mają wspólną, wewnętrzną drogę komunikacji. Bez tego kończy się na błędach typu 502 Bad Gateway, mimo że kontener aplikacji „przecież działa”.

Traefik ma największy sens tam, gdzie króluje Docker. Jego moc polega na tym, że potrafi czytać konfigurację z kontenerów — przez labels. Zamiast tworzyć osobny plik dla każdej aplikacji, opisujesz routing przy usłudze w docker-compose.yml.

Przykład etykiet dla aplikacji:

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.app.rule=Host(`app.domena.pl`)"
  - "traefik.http.routers.app.entrypoints=websecure"
  - "traefik.http.routers.app.tls.certresolver=letsencrypt"
  - "traefik.http.services.app.loadbalancer.server.port=3000"

Ten przykład zakłada, że w głównej konfiguracji Traefika masz już zdefiniowany entrypoint o nazwie websecure oraz resolver certyfikatów letsencrypt. Bez tego kontener może wystartować, ale routing albo TLS nie zadziałają poprawnie. Etykiety w Traefiku nie są magiczne — one odwołują się do elementów, które muszą istnieć w konfiguracji statycznej.

To podejście świetnie działa, gdy aplikacje często dochodzą, znikają albo zmieniają porty. Traefik obserwuje kontenery i aktualizuje routing bez ręcznego dopisywania kolejnych bloków konfiguracyjnych. Do tego potrafi obsługiwać certyfikaty przez Let’s Encrypt.

Ale jest cena: Traefik ma wyższy próg wejścia niż Caddy. Trzeba zrozumieć pojęcia takie jak router, service, entrypoint, middleware, provider i certresolver. Przy jednej aplikacji to przerost formy. Przy dziesięciu kontenerach — zaczyna być wygodnie.

Traefik wybrałbym, gdy:

• większość usług działa w Dockerze,
• często dodajesz nowe kontenery,
• chcesz trzymać routing blisko definicji aplikacji,
• potrzebujesz automatycznego wykrywania usług,
• planujesz środowisko, które będzie rosło.

Traefik również wymaga pilnowania sieci Dockera. Kontener Traefika musi być w tej samej sieci co aplikacje, które ma routować. Najczęściej tworzy się jedną sieć typu proxy albo web i podpina do niej wszystkie publiczne usługi. Bazy danych, Redis czy wewnętrzne kolejki zostają w osobnych sieciach aplikacyjnych i nie trafiają do reverse proxy.

To jest dobra praktyka: proxy widzi tylko to, co ma być wystawione przez domenę. Nie powinno mieć dostępu do wszystkiego na serwerze tylko dlatego, że tak było szybciej w docker-compose.yml.

Najkrótsze porównanie wygląda tak:

Decyzja graniczna jest prosta: jeśli konfigurujesz reverse proxy raz na kilka miesięcy, Caddy albo Nginx będą spokojniejsze. Jeśli dodajesz kontenery co tydzień, Traefik zacznie oszczędzać czas.

Które rozwiązanie wybrać dla Next.js, API, WordPressa i paneli self-hosted?

Dla Next.js najważniejsze są poprawne nagłówki proxy, WebSockety w trybie developerskim lub przy live preview, stabilne przekazywanie hosta i protokołu oraz brak publicznego wystawiania portu 3000. Produkcyjnie aplikacja zwykle działa za reverse proxy na localhost:3000 albo w kontenerze. Tutaj sprawdzą się wszystkie trzy narzędzia, ale wybór zależy od sposobu wdrożenia.

Dla pojedynczej aplikacji Next.js na VPS-ie wybrałbym Caddy albo Nginx. Caddy, jeśli ma być szybko i bez walki z SSL. Nginx, jeśli na tym samym serwerze masz już WordPressa, cache albo bardziej szczegółowe reguły. Traefik ma sens dopiero wtedy, gdy Next.js jest jednym z kilku kontenerów w większym docker-compose.

Dla API priorytety są inne. Liczą się nagłówki, limity, CORS, logi, timeouty i możliwość odcięcia ruchu, który nie powinien trafić do backendu. Proste API spokojnie obsłuży Caddy. Bardziej kontrolowane środowisko — Nginx. API w Dockerze, z kilkoma mikroserwisami — Traefik.

Przy API pilnowałbym szczególnie:

• przekazywania X-Forwarded-For, żeby backend znał prawdziwy adres klienta,
• ustawienia timeoutów, żeby długie żądania nie kończyły się przypadkowym błędem,
• niewystawiania portu backendu publicznie,
• rozdzielenia publicznego API od paneli administracyjnych,
• rate limitingu, jeśli endpointy są podatne na spam lub brute force.

Dla WordPressa najbezpieczniejszy wybór to nadal Nginx, ewentualnie Apache za Nginxem, zależnie od stacku. WordPress ma mnóstwo specyficznych zachowań: uploady, permalinki, cache, PHP-FPM, pliki statyczne, limity rozmiaru uploadu i wtyczki bezpieczeństwa. Tu ogromna liczba przykładów dla Nginxa naprawdę pomaga.

Caddy też da radę, zwłaszcza przy prostym WordPressie, ale jeżeli problem dotyczy nietypowej wtyczki, reguł cache albo konfiguracji PHP, szybciej znajdziesz gotową odpowiedź dla Nginxa. Traefik przy WordPressie ma sens głównie wtedy, gdy WordPress działa jako kontener obok innych usług.

Dla paneli self-hosted — takich jak Uptime Kuma, Grafana, Plausible, Matomo, Portainer, n8n czy Home Assistant — decyzja zależy od tego, czy wszystko działa w Dockerze.

Jeżeli używasz docker-compose, Traefik jest bardzo wygodny. Każda usługa ma własne labels, własną domenę i może dostać certyfikat bez osobnego pliku proxy. To skaluje się lepiej niż ręczne kopiowanie bloków Nginxa.

Jeżeli masz trzy usługi i chcesz minimum komplikacji, Caddy będzie szybszy:

status.domena.pl {
    reverse_proxy uptime-kuma:3001
}

analytics.domena.pl {
    reverse_proxy analytics:8080
}

panel.domena.pl {
    reverse_proxy panel:9000
}

W tym przykładzie nazwy uptime-kuma, analytics i panel mają sens wtedy, gdy kontenery działają we wspólnej sieci Dockera. Jeżeli aplikacje działają bez Dockera na hoście, wtedy używasz adresów typu 127.0.0.1:3001.

Najbardziej praktyczna rekomendacja:

• wybierz Caddy, jeśli zaczynasz i chcesz szybko, czysto, z automatycznym HTTPS;
• wybierz Nginx, jeśli potrzebujesz kontroli, pracujesz z WordPressem, masz mało RAM-u albo chcesz iść ścieżką z największą liczbą poradników;
• wybierz Traefik, jeśli Twoje aplikacje żyją w Dockerze i chcesz automatycznego routingu przez labels.

Nie mieszałbym wszystkich trzech narzędzi na jednym małym VPS-ie bez powodu. Jeden reverse proxy na wejściu wystarczy. Dwa reverse proxy mają sens dopiero przy konkretnym powodzie: migracji, testach, osobnej sieci wewnętrznej albo bardziej rozbudowanej architekturze.

Przed wyborem sprawdź cztery rzeczy:

1. Czy aplikacje działają w Dockerze?
   Jeśli tak, Traefik ma mocny argument.
2. Czy zależy Ci na najprostszym SSL?
   Jeśli tak, Caddy jest najwygodniejszy.
3. Czy hostujesz WordPressa albo klasyczny PHP stack?
   Jeśli tak, Nginx będzie najbardziej przewidywalny.
4. Czy będziesz często dodawać nowe usługi?
   Jeśli tak, ręczna konfiguracja Nginxa może szybko zacząć irytować.

Najgorszy wybór to nie Nginx, Caddy ani Traefik. Najgorszy wybór to serwer, na którym każdy panel ma wystawiony własny port, SSL jest „do zrobienia później”, a dokumentacja konfiguracji istnieje tylko w historii terminala.

FAQ

Czy reverse proxy jest potrzebny przy jednej aplikacji?
Nie zawsze, ale często i tak warto go użyć. Reverse proxy odseparowuje warstwę aplikacji od warstwy kryptograficznej: aplikacja Node.js, PHP albo Go nie musi sama obsługiwać certyfikatów TLS ani uruchamiać się z uprawnieniami roota tylko po to, żeby bindować port 443. Przy jednej aplikacji zyskujesz też prostsze przekierowanie HTTP → HTTPS, czytelniejsze logi i łatwiejszą przyszłą rozbudowę.

Czy mogę wystawiać aplikacje bezpośrednio na portach typu 3000, 8080 albo 9000?
Technicznie tak, produkcyjnie nie warto. Lepiej zostawić publicznie porty 80 i 443, a aplikacje trzymać lokalnie albo w prywatnej sieci Dockera. Publiczny port aplikacji to dodatkowe miejsce do skanowania, ataku i przypadkowej pomyłki konfiguracyjnej.

Co jest najłatwiejsze dla początkującego: Nginx, Caddy czy Traefik?
Najłatwiejszy jest Caddy. Ma krótką konfigurację i automatyczny HTTPS. Nginx wymaga więcej ręcznej pracy, ale ma najwięcej poradników. Traefik jest prosty dopiero wtedy, gdy rozumiesz Dockera, labels, entrypointy i cert resolvery.

Czy Traefik nadaje się bez Dockera?
Tak, ale jego największa przewaga ujawnia się właśnie przy Dockerze i automatycznym wykrywaniu kontenerów. Bez Dockera często prościej użyć Caddy albo Nginxa.

Czy Caddy sam odnawia certyfikaty SSL?
Tak, Caddy automatyzuje obsługę HTTPS dla poprawnie skonfigurowanych domen. Warunek jest praktyczny: domena musi wskazywać na serwer, a serwer musi być dostępny na wymaganych portach. Jeżeli ruch przechodzi przez nietypowy tunel, NAT albo zamknięty firewall, konfigurację trzeba dopasować.

Czy Nginx automatycznie obsługuje Let’s Encrypt?
Sam Nginx nie działa jak automatyczny menedżer certyfikatów w stylu Caddy. Najczęściej łączy się go z Certbotem albo innym narzędziem do wystawiania i odnawiania certyfikatów.

Co wybrać do WordPressa na VPS?
Najczęściej Nginx. Daje dużą kontrolę nad PHP-FPM, cache, uploadami, plikami statycznymi i regułami specyficznymi dla WordPressa. Caddy też może działać, ale przy problemach z wtyczkami, cache albo konfiguracją PHP szybciej znajdziesz gotowe przykłady dla Nginxa.

Co wybrać do kilku aplikacji self-hosted w docker-compose?
Traefik, jeśli chcesz mieć routing opisany w labels przy każdej usłudze. Caddy, jeśli wolisz prosty plik konfiguracyjny i nie dodajesz nowych kontenerów zbyt często. W obu przypadkach zadbaj o wspólną sieć Dockera dla proxy i aplikacji.

Czy reverse proxy musi być w tej samej sieci Dockera co aplikacja?
Tak, jeśli reverse proxy i aplikacja działają jako kontenery. Inaczej proxy nie będzie miało jak połączyć się z usługą po nazwie kontenera. To jeden z najczęstszych powodów błędów 502 Bad Gateway.

Czy Nginx jest zawsze lżejszy od Caddy i Traefika?
W typowych minimalistycznych konfiguracjach Nginx ma bardzo niski narzut i dobrze sprawdza się na małych VPS-ach. Caddy i Traefik oferują wygodną automatyzację, ale ta wygoda kosztuje zasoby. Na maszynie z 512 MB RAM zacząłbym od Nginxa albo bardzo oszczędnej konfiguracji Caddy, a Traefika zostawiłbym dla środowiska, w którym Docker i automatyczne wykrywanie usług naprawdę rozwiązują problem.

Od czego zacząć na świeżym VPS-ie?
Najpierw ustaw DNS i firewall, potem uruchom jedną aplikację lokalnie, a dopiero później dodaj reverse proxy. Jeśli chcesz najkrótszą ścieżkę, zacznij od Caddy. Jeśli już wiesz, że cały serwer będzie oparty o Dockera, zacznij od Traefika. Jeśli planujesz WordPressa, klasyczny stack albo bardzo mały VPS, wybierz Nginx.