Nginx czy Caddy czy Traefik: co wybrać na VPS?

Nginx kontra Caddy kontra Traefik: krótka odpowiedź

Nginx, Caddy oraz Traefik pełnią tę samą funkcję jako reverse proxy: nasłuchują na porcie 443, odczytują nazwę hosta w każdym żądaniu i przekazują je do właściwej usługi na VPS. Każde z tych rozwiązań pozwoli umieścić cztery własne aplikacje za jednym publicznym adresem IP, a wszystkie są na tyle wydajne, że to same aplikacje będą stanowić wąskie gardło. Różnica polega na sposobie uzyskiwania certyfikatu TLS (transport layer security) oraz nakładzie pracy potrzebnym na konfigurację każdej kolejnej usługi. Kolejna różnica ujawnia się w momencie, gdy wymagane jest rozwiązanie wykraczające poza standardowe poradniki.

Wybierz Caddy, jeśli obsługa HTTPS ma odbywać się automatycznie, a usługi to typowe aplikacje webowe. Wybierz Traefik, jeśli całość działa w Docker Compose, a nowe usługi są dodawane regularnie. Wybierz Nginx, jeśli już go używasz lub gdy wymagane jest buforowanie odpowiedzi, certyfikaty klienckie, przekazywanie surowego ruchu TCP albo posiadasz rozbudowaną konfigurację, której nie chcesz przepisywać.

W jaki sposób każda z nich uzyskuje certyfikat TLS?

Ta kwestia jest dla większości użytkowników rozstrzygająca, dlatego warto zacząć od niej. Wszystkie trzy rozwiązania kończą z tym samym certyfikatem od tego samego urzędu certyfikacji. Nakład pracy potrzebny do osiągnięcia tego celu jest jednak różny.

Caddy żąda certyfikatu, ponieważ zdefiniowano nazwę hosta. Wpisz app.example.com jako adres witryny, a Caddy zażąda certyfikatu przez ACME (automatic certificate management environment) od Let's Encrypt. W razie niepowodzenia automatycznie przełączy się na ZeroSSL, obsłuży przekierowanie HTTP na HTTPS na porcie 80 i samodzielnie zajmie się odnawianiem. Nie ma tu drugiego narzędzia ani timera do sprawdzania. Certyfikaty znajdują się w katalogu danych użytkownika caddy, /var/lib/caddy/.local/share/caddy w przypadku instalacji z pakietu, więc należy dodać tę ścieżkę do kopii zapasowych lub zaakceptować konieczność ponownego wydania certyfikatu po przebudowie. W przypadku hosta, który nie jest publiczny, tls internal podpisuje certyfikat własnym lokalnym urzędem certyfikacji Caddy. Daje to ten sam efekt co tworzenie certyfikatu z podpisem własnym w systemie Ubuntu, przy czym odnawianie odbywa się automatycznie.

Nginx nie posiada klienta ACME. Certyfikat uzyskuje Certbot, a jego wtyczka --nginx modyfikuje blok serwera, dodając nasłuchiwanie na porcie 443 oraz przekierowanie. Odnawianie jest uruchamiane przez timer systemd instalowany wraz z pakietem, więc istnieją dwa ruchome elementy i dwa miejsca do weryfikacji: systemctl list-timers | grep certbot potwierdza istnienie timera, a sudo certbot renew --dry-run sprawdza, czy ścieżka odnawiania nadal działa. Instrukcja krok po kroku znajduje się w Certbot w systemie Ubuntu 24.04 z Nginx, a to samo narzędzie obsługuje certyfikat typu wildcard poprzez wyzwanie DNS-01, gdy liczba subdomen jest zbyt duża, aby wymieniać je pojedynczo.

Traefik posiada własnego klienta ACME. W konfiguracji statycznej definiuje się jeden mechanizm rozwiązywania certyfikatów (certificate resolver), z którego może korzystać każdy router. Cały stan, w tym klucz konta i certyfikaty, znajduje się w jednym pliku acme.json. Traefik odmawia użycia tego pliku, jeśli jest on dostępny do odczytu dla kogokolwiek poza właścicielem, o czym informuje przed wyłączeniem mechanizmu rozwiązywania:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

Należy zamontować katalog i pozwolić Traefikowi na samodzielne utworzenie pliku. Jeśli utworzysz go wcześniej za pomocą touch, przejmie on Twoją maskę umask, co jest najczęstszą przyczyną napotkania tego błędu.

Jedna zasada dotyczy wszystkich trzech rozwiązań. Wyzwanie HTTP-01 wymaga, aby port 80 był dostępny z Internetu, ponieważ urząd certyfikacji musi nawiązać połączenie zwrotne. Otwarcie tylko portu 443 spowoduje niepowodzenie wydania certyfikatu, co w logach może być błędnie interpretowane jako problem z DNS.

To samo zadanie routingu dla dwóch aplikacji w trzech konfiguracjach

Zadanie: app.example.com kieruje ruch do usługi na 127.0.0.1:8080, files.example.com kieruje do usługi na 127.0.0.1:8081, obie przez HTTPS. Poniżej przedstawiono pełną konfigurację dla każdego proxy, aby różnica w zwięzłości była widoczna, a nie tylko deklarowana.

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Następnie należy utworzyć dowiązanie, przetestować konfigurację, przeładować usługę i dodać certyfikat.

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

nginx -t wyświetlające syntax is ok oraz test is successful to test, który należy wykonać przed każdym przeładowaniem. Druga aplikacja to ten sam blok z inną nazwą hosta i portem. Linie proxy_set_header nie są dekoracją: gdy proxy_pass wskazuje adres, nginx domyślnie przesyła Host: 127.0.0.1:8080 do backendu, więc aplikacja budująca bezwzględne adresy URL na podstawie nagłówka Host przekieruje użytkowników na localhost. Cel każdego z tych czterech nagłówków oraz powód, dla którego ukośnik na końcu proxy_pass zmienia ścieżkę otrzymywaną przez aplikację, zostały szczegółowo omówione w tym przewodniku po bloku serwera nginx.

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

To cały plik. reverse_proxy samodzielnie konfiguruje X-Forwarded-For, X-Forwarded-Proto oraz X-Forwarded-Host i domyślnie ignoruje nagłówki przesyłane przez klienta, dzięki czemu żądanie nie może wprowadzić backendu w błąd co do swojego pochodzenia. Certyfikaty, przekierowanie z portu 80 oraz odnawianie wynikają bezpośrednio z dwóch adresów witryn. Żaden inny element pliku nie wymaga dodatkowej konfiguracji.

Traefik

Traefik wymaga statycznej konfiguracji przed rozpoczęciem routingu. Jako usługa Compose, z obrazem aktualnym na sierpień 2026:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

Każda aplikacja posiada własną konfigurację routingu w etykietach, wewnątrz własnego pliku compose:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

loadbalancer.server.port to port wewnątrz kontenera, a nie port opublikowany, ponieważ Traefik łączy się z kontenerem przez współdzieloną sieć Docker. Aplikacja nie wymaga żadnej linii ports: i to jest główna zaleta: opublikowany jest tylko Traefik. Pełna implementacja, w tym współdzielona sieć i middleware przekierowujący, znajduje się w routingu wielu aplikacji za pomocą Traefik i Docker Compose.

Jaki jest koszt konfiguracji każdej dodatkowej aplikacji?

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

Liczba ta wynika z powyższych bloków. Blok serwera Nginx zajmuje 11 niepustych linii, które należy powielać dla każdej nazwy hosta. Blok witryny Caddy zajmuje 3 linii. Traefik wymaga 17 linii konfiguracji statycznej przed obsłużeniem pierwszego żądania, a następnie 5 etykiet na każdą aplikację.

Należy ocenić kompromisy, a nie wyłaniać zwycięzcę. Traefik generuje najwyższy koszt początkowy przed dodaniem pierwszej aplikacji, ale najniższy koszt dla każdej kolejnej; oba podejścia zrównują się w okolicach trzeciej witryny. Poniżej tej liczby konfiguracja statyczna stanowi zbędny narzut. Powyżej niej etykiety zyskują przewagę, ponieważ routing znajduje się bezpośrednio przy obsługiwanej usłudze. Usunięcie usługi powoduje automatyczne usunięcie jej routingu, co jest słabym punktem centralnych plików konfiguracyjnych, w których często pozostają nieaktualne bloki serwera dla aplikacji nieistniejących od miesięcy.

Liczba linii jest również myląca na korzyść Nginx. Każdy z tych bloków wymaga utworzenia dowiązania symbolicznego, nginx -t, przeładowania konfiguracji oraz uruchomienia certbot, podczas gdy edycja Caddy wymaga tylko przeładowania, a w przypadku Traefik nie jest wymagane żadne polecenie. Wszystkie trzy rozwiązania przeładowują konfigurację bez przerywania aktywnych połączeń. Różnica polega na liczbie odrębnych kroków, o których trzeba pamiętać o pierwszej w nocy.

Które rozwiązanie posiada wiedzę o kontenerach?

Traefik monitoruje socket Docker i tworzy routery na podstawie etykiet kontenerów w momencie ich uruchamiania oraz zatrzymywania. Żadne inne rozwiązanie tutaj tego nie robi. Zarówno Nginx, jak i Caddy wymagają edycji konfiguracji oraz przeładowania po pojawieniu się nowego kontenera, a także wymagają adresu, pod którym mogą uzyskać dostęp do usługi: portu opublikowanego na interfejsie loopback lub współdzielonej sieci Docker, do której podłączone jest proxy.

Ta funkcjonalność ma swoją cenę, którą warto jasno określić. Traefik odczytuje /var/run/docker.sock. Każdy, kto może komunikować się z tym socketem, jest w stanie uruchomić kontener z zamontowanym systemem plików hosta, co oznacza uprawnienia root na hoście. Montowanie go w trybie tylko do odczytu zmniejsza ryzyko, ale go nie eliminuje. Jeśli ma to znaczenie dla modelu zagrożeń, należy umieścić pomiędzy nimi socket proxy, które udostępnia tylko te punkty końcowe listy kontenerów, których wymaga Traefik.

Caddy może realizować wykrywanie oparte na etykietach za pomocą wtyczki społecznościowej, jednak wtyczki Caddy są kompilowane wewnątrz binarki. Wymaga to zbudowania własnego pliku binarnego lub własnego obrazu za pomocą xcaddy, co oznacza przejęcie odpowiedzialności za ten build i jego aktualizacje. W przypadku trzech lub czterech usług edycja pliku Caddyfile jest mniej pracochłonna.

Websockety i strumieniowanie: co ulega awarii i dlaczego

Nginx wymaga dodatkowej konfiguracji. Połączenie WebSocket rozpoczyna się jako żądanie HTTP zawierające Upgrade: websocket, a Nginx nie przekazuje nagłówków typu hop-by-hop do backendu, chyba że zostanie do tego jawnie skonfigurowany.

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Następnie wewnątrz bloku location należy umieścić trzy linie, które muszą wystąpić łącznie:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

Ich pominięcie spowoduje wyświetlenie błędu WebSocket connection to 'wss://app.example.com/ws' failed w konsoli przeglądarki, podczas gdy w dzienniku backendu widoczne będzie zwykłe żądanie GET. Zmienna map jest niezbędna, ponieważ zakodowane na sztywno Connection: upgrade byłoby wysyłane przy każdym żądaniu, w tym przy zwykłych zapytaniach, które powinny zawierać close.

Problemem są również dwa inne ustawienia domyślne Nginx. Parametr proxy_read_timeout wynosi 60 sekund i ma zastosowanie do tunelu po aktualizacji, więc WebSocket bez ruchu przez minutę zostanie zamknięty przez proxy. Z kolei zdarzenia wysyłane przez serwer (Server-Sent Events) docierają z opóźnieniem lub w paczkach, dopóki dla danej lokalizacji nie zostanie ustawione proxy_buffering off;, ponieważ Nginx przetrzymuje odpowiedź w buforze, podczas gdy strona na nią oczekuje.

Caddy automatycznie obsługuje aktualizację i przełącza połączenie w tryb dwukierunkowego tunelu bez żadnych dodatkowych dyrektyw. Ponadto natychmiast przesyła dane, gdy odpowiedź ma status text/event-stream lub nie posiada określonej długości, dzięki czemu strumieniowanie działa bez zmian. Traefik przekazuje aktualizacje i nie buforuje odpowiedzi, chyba że użytkownik samodzielnie doda middleware buffering. Jeśli usługi obejmują czat, terminal webowy, podgląd logów lub interaktywne panele, stanowi to istotną różnicę w nakładzie pracy potrzebnej na konfigurację i debugowanie.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Co zrobić w nietypowych sytuacjach?

W takich przypadkach Nginx zyskuje dzięki swoim dodatkowym opcjom konfiguracji.

• Certyfikaty klienckie, znane również jako mTLS (mutual TLS), wymagają przedstawienia certyfikatu przez klienta. Nginx wymaga dyrektyw ssl_client_certificate /etc/ssl/ca.pem; oraz ssl_verify_client on; w bloku server. Caddy wymaga bloku client_auth wewnątrz tls. Etykiety Traefik nie obsługują tego mechanizmu bezpośrednio: należy zdefiniować opcję TLS w pliku konfiguracyjnym i wskazać ją w routerze za pomocą traefik.http.routers.app.tls.options=mtls@file. Model konfiguracji oparty wyłącznie na etykietach wymaga wyjątku przy tego typu wymaganiach.
• Duże pliki przesyłane na serwer. Nginx domyślnie ogranicza rozmiar treści żądania do 1 MB. Próba przesłania większego pliku skutkuje błędem 413 Request Entity Too Large, a w dzienniku błędów pojawia się wpis client intended to send too large body. Należy zwiększyć wartość client_max_body_size. Caddy i Traefik domyślnie nie nakładają limitów na rozmiar treści, więc decyzja o limicie zależy od konfiguracji samej aplikacji.
• Buforowanie odpowiedzi. Nginx posiada dojrzały moduł proxy_cache. Caddy wymaga skompilowania odpowiedniej wtyczki. Wersja open source Traefik nie posiada wbudowanego mechanizmu buforowania HTTP, co często zaskakuje użytkowników zakładających, że każdy serwer proxy oferuje tę funkcjonalność.
• Obsługa surowego ruchu TCP lub UDP, na przykład dla portu bazy danych lub serwera gier. Nginx wykorzystuje moduł stream. Traefik posiada dedykowane routery TCP i UDP dla własnych punktów wejścia (entrypoints). Caddy wymaga wtyczki, co wiąże się z koniecznością przygotowania własnej kompilacji.
• Serwer WWW działający za proxy. Jeśli usługą jest klasyczna aplikacja PHP, to stos LAMP na Ubuntu 24.04 zawiera już Apache. Umieszczenie proxy przed nim powoduje, że nagłówki i reguły przepisywania adresów URL mogą być definiowane w dwóch miejscach. Należy zdecydować, który komponent zajmie się terminacją TLS, a drugi pozostawić w trybie zwykłego HTTP powiązanego z interfejsem loopback.

Pułapka firewalla związana z tym wyborem

Celem stosowania reverse proxy jest pozostawienie otwartych wyłącznie portów 80 oraz 443. Docker po cichu niweczy to założenie. Opublikowanie portu za pomocą -p 8080:80 powoduje zapisanie reguły DNAT w tablicy nat, a reguła ta jest przetwarzana przed regułami INPUT zarządzanymi przez ufw. W rezultacie ufw deny 8080 nie blokuje takiego ruchu, a aplikacja staje się dostępna w publicznym Internecie, obok starannie skonfigurowanego proxy. Należy wiązać publikowane porty z interfejsem loopback przy użyciu 127.0.0.1:8080:80 lub całkowicie zrezygnować z ports:, pozwalając proxy na komunikację z kontenerem poprzez Docker network, co zostało przedstawione w powyższym przykładzie Traefik. Mechanizm działania oraz sposób naprawy opisano w dlaczego publikowane porty Dockera omijają ufw.

Test należy przeprowadzić z maszyny innej niż VPS, ponieważ sprawdzenie wykonane na tym samym serwerze zawsze zakończy się powodzeniem:

curl --max-time 5 http://your.server.address:8080

Connection refused lub przekroczenie czasu oczekiwania (timeout) to pożądany wynik. Odpowiedź HTTP oznacza, że aplikacja jest dostępna z pominięciem proxy, a wszystkie powyższe konfiguracje są jedynie dekoracją.

Który serwer proxy wybrać?

Głównie statyczne strony oraz jedna lub dwie aplikacje: Caddy. Automatyczny HTTPS eliminuje największy powtarzalny obowiązek. Konfiguracja pozostaje na tyle krótka, że mieści się na jednym ekranie, a statyczna strona to jedna linia root oraz jedna linia file_server wewnątrz tego samego bloku witryny. Kosztem jest mniejsza baza gotowych rozwiązań w przypadku wystąpienia nietypowych problemów.

Homelab oparty na docker-compose, który jest stale rozbudowywany: Traefik. Powyżej trzeciej usługi etykiety (labels) wymagają mniej pracy niż edycja centralnego pliku, a usunięcie usługi automatycznie usuwa przypisaną do niej trasę. Należy zarezerwować popołudnie na pierwszą konfigurację, ponieważ entrypoints, routers, services oraz middlewares stanowią nowe pojęcia. Literówka w etykiecie zazwyczaj skutkuje błędem 404 zwracanym przez Traefik, a nie brakiem startu usługi, dlatego przed założeniem, że aplikacja jest uszkodzona, należy sprawdzić docker logs traefik pod kątem błędów parsowania.

Istniejąca konfiguracja Nginx lub jakiekolwiek wymaganie z powyższej listy: Nginx. Posiada on gotowe rozwiązania dla buforowania odpowiedzi oraz certyfikatów klienckich, a niemal każdy poradnik zewnętrzny zakłada jego użycie. Kosztem jest to, że certyfikaty oraz obsługa websocket wymagają ręcznej konfiguracji, zamiast być dostępne w standardzie.

Niezależnie od wyboru, obowiązuje jedna zasada. Dokładnie jeden proces nasłuchuje na publicznym interfejsie, a cała reszta nasłuchuje na interfejsie loopback lub w prywatnej sieci Docker.

FAQ

Który reverse proxy jest najlepszy dla kilku aplikacji Docker na jednym VPS?

Dla trzech lub czterech usług, które są okresowo dodawane, Traefik jest najbardziej opłacalny, ponieważ każda aplikacja zawiera własne etykiety routingu i nie wymaga edycji centralnego pliku konfiguracyjnego. Jeśli usługi są stabilne, a głównym celem jest automatyzacja HTTPS, Caddy jest łatwiejszy w nauce i mniej podatny na błędy. Nginx należy wybrać, gdy jest już znany lub gdy wymagana jest funkcja niedostępna w pozostałych, taka jak buforowanie odpowiedzi lub obsługa zwykłego TCP.

Czy Caddy naprawdę nie wymaga konfiguracji certyfikatów?

W typowym przypadku tak. Podanie publicznej nazwy hosta jako adresu strony jest pełną konfiguracją: Caddy żąda certyfikatu przez ACME, obsługuje przekierowanie z portu 80 i odnawia certyfikat przed wygaśnięciem. Dwa warunki muszą być spełnione. Port 80 musi być dostępny z Internetu dla wyzwania HTTP-01, a rekord DNS A lub AAAA nazwy hosta musi wskazywać na VPS, ponieważ urząd certyfikujący rozwiązuje nazwę i łączy się z nią zwrotnie.

Czy można uruchomić Nginx i Traefik na tym samym VPS?

Nie na tych samych portach. Usługa, która uruchomi się jako druga, nie powiąże się z portem; Nginx zgłosi bind() to 0.0.0.0:443 failed (98: Address already in use), a Traefik zarejestruje podobny błąd powiązania i zakończy działanie. Należy uruchomić jeden proxy na portach 80 i 443, a pozostałe usługi umieścić za nim. W przypadku migracji należy przenosić nazwy hostów pojedynczo: niech główny proxy przekazuje ruch do starego na porcie lokalnym, dopóki ostatnia witryna nie zostanie przeniesiona.

Dlaczego połączenia websockets są zrywane po 60 sekundach za Nginx?

proxy_read_timeout domyślnie wynosi 60 sekund i dotyczy tunelu po zakończeniu aktualizacji protokołu, więc połączenie bez ruchu przez minutę jest zamykane przez proxy, a nie przez aplikację. Należy zwiększyć tę wartość w danej lokalizacji za pomocą proxy_read_timeout 3600s; lub skonfigurować aplikację tak, aby wysyłała ramkę ping co 30 sekund. Caddy i Traefik nie zamykają bezczynnych połączeń po minucie, dlatego ta sama aplikacja może wydawać się stabilna za nimi, a niestabilna za Nginx.