Caddy vs Nginx na VPS: porównanie plików konfiguracyjnych

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        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;
    }
}

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

Linie TLS w bloku Nginx zakładają, że Certbot już się uruchomił. Dla upstreamu HTTP takiego jak powyższy Caddy przekazuje przychodzący Host nagłówek dalej i domyślnie ustawia X-Forwarded-For, X-Forwarded-Proto oraz X-Forwarded-Host domyślnie. W przypadku Nginx zwykle dodajesz nagłówki proxy jawnie, gdy upstream potrzebuje oryginalnego hosta, schematu i łańcucha adresów klienta. To kompromis w miniaturze: Caddy dostarcza praktyczne domyślne ustawienia proxy, podczas gdy Nginx czyni więcej tego zachowania jawnym.

Serwowanie plików statycznych:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Basic auth, chroniące wszystko za nazwą użytkownika i hasłem:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        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;
    }
}

Oba narzędzia hashują hasło poza pasmem. Caddy używa caddy hash-password; Nginx używa htpasswd aby zbudować plik .htpasswd. Dyrektywa to basic_auth w aktualnym Caddy, swoją drogą. Było to basicauth dopóki v2.8.0 tego nie przemianowało, jak zaznaczono w dokumentacji basic_auth w Caddy, a stare poradniki nadal na tym ludzi potykają.

Wskazówka: Ten hash w Caddyfile to nie hasło. To wynik bcrypt z caddy hash-password. Uruchom polecenie, wklej to, co wypisze. Caddy odrzuca hasła w postaci jawnej w konfiguracji, co jest poprawnym domyślnym ustawieniem i małą niespodzianką za pierwszym razem.

Konfiguracje bronią się same. Caddy zamyka TLS, rozsądne nagłówki proxy i przekierowanie w kilku liniach; Nginx jest jawny i rozwlekły oraz daje Ci każdą możliwą śrubę do pokręcenia. Jeśli spędziłeś lata w Nginx, rozwlekłość to pamięć mięśniowa, a kontrola to sedno. Jeśli nie, Caddyfile to konfiguracja, którą zmieścisz w głowie. Praktyczny wniosek jest prosty: konfigurację Caddy łatwiej odczytać na pierwszy rzut oka, natomiast Nginx daje Ci bardziej jawną kontrolę.

Wydajność i pamięć: uważne czytanie benchmarków

Opublikowane testy wskazują w tym samym ogólnym kierunku: Nginx zwykle używa mniej pamięci i często prowadzi w surowej przepustowości, ale wielkość tej przewagi mocno zależy od środowiska.

In jednym teście VM z czterema rdzeniami od strony trzeciej, Nginx osiągnął około 48 000 żądań na sekundę, w porównaniu z około 42 000 dla Caddy. Ten sam test raportował opóźnienie HTTPS p99 na poziomie 2,1 ms dla Nginx i 2,4 ms dla Caddy. Traktuj to jako wyniki z jednej konfiguracji, a nie jako uniwersalny margines wydajności.

Zakresy pamięci w tabeli porównawczej pochodzą z osobnego testu VPS. Kolejny syntetyczny test przy 50 000 równoczesnych połączeń raportował 145 MB dla Nginx i 520 MB dla Caddy, ale ten test wykorzystywał znacząco inny sprzęt i warunki obciążenia. Jego bezwzględnych wartości nie należy porównywać bezpośrednio z liczbami dla VPS powyżej.

Wiarygodny wniosek jest węższy: Nginx zwykle ma mniejsze zużycie pamięci i ma tendencję do prowadzenia przy obciążeniach o wysokiej przepustowości lub wysokiej równoczesności. Dla zwykłego reverse proxy na małym lub średnim VPS oba są zwykle wystarczająco szybkie, więc prostota operacyjna jest często bardziej użytecznym czynnikiem decydującym.

Wniosek z sekcji: wybieraj na podstawie kwestii operacyjnych, chyba że Twój serwer ma ograniczoną pamięć lub Twoje własne testy obciążeniowe pokazują, że przepustowość proxy jest wąskim gardłem.

Haczyk z certyfikatem wildcard (Caddy nie zawsze jest bezkonfiguracyjny)

Caddy potrafi zautomatyzować certyfikaty wildcard, ale nie za pomocą domyślnych wyzwań HTTP-01 ani TLS-ALPN-01. Certyfikat dla *.example.com wymaga walidacji DNS-01, której Let's Encrypt wymaga dla certyfikatów wildcard. Oznacza to wtyczkę dostawcy DNS (wbudowaną w Twój plik binarny Caddy przez xcaddy) plus token API dla Twojego hosta DNS, skonfigurowany w bloku tls. To nie jest historia typu wpisz jedną linię i odejdź, którą reklamuje Caddy.

To dotyka użytkowników homelabów, którzy umieszczają wiele usług pod prawdziwą domeną, którą kontrolują, taką jak *.home.example.com, i zakładają, że wydawanie certyfikatów wildcard jest tak samo automatyczne jak app.example.com. Dla nazw czysto wewnętrznych, takich jak *.homelab.internal, traktuj to jako obszar lokalnego/wewnętrznego PKI, a nie publiczny certyfikat wildcard z Let's Encrypt. Aby być precyzyjnym: Caddy obsługuje certyfikaty wildcard bez problemu, po prostu nie robi tego za pomocą domyślnych wyzwań, a konfiguracja to krok wyżej niż w przypadku pojedynczej domeny. Nginx jest tu w tej samej sytuacji, ponieważ wymóg DNS-01 pochodzi z Let's Encrypt, a nie z serwera.

Jeśli chcesz GUI: Nginx Proxy Manager (krótka dygresja)

Nginx Proxy Manager to zupełnie inne zwierzę niż dwa powyższe narzędzia i wart jest jednego akapitu, bo nazwa myli ludzi. NPM to nakładka GUI na Nginx: zarządza regułami reverse proxy i certyfikatami Let's Encrypt przez interfejs webowy na porcie 81. To nie jest rdzeń Nginx i nie konfiguruje się go tak, jak rdzeń Nginx.

Kompromis to zwykły klikanie kontra konfiguracja. NPM to łatwy przycisk, dopóki nie zejdziesz ze ścieżki bez przeszkód. Jego konfiguracja jest zarządzana przez bazę danych aplikacji, a nie przez pojedynczy ręcznie edytowany plik konfiguracyjny. Domyślna konfiguracja Docker używa SQLite, natomiast MySQL/MariaDB i PostgreSQL to obsługiwane opcje zewnętrznych baz danych. Ta różnica wpływa też na przenośność: konfigurację Caddy często można przenieść, kopiując pojedynczy Caddyfile, podczas gdy wdrożenie Nginx Proxy Manager wymaga zachowania jego danych aplikacji i bazy danych . NPM to dobry wybór, jeśli naprawdę wolisz klikanie od edytowania, a Twoja konfiguracja pozostaje prosta. To zły wybór dla przepływu pracy typu infrastruktura jako kod.

Migracja z Nginx do Caddy (co się przekłada, a co nie)

Jeśli jesteś już na Nginx i rozważasz przejście, zacznij od obniżenia oczekiwań wobec automatyzacji: istnieje adapter konfiguracji NGINX dla Caddy, ale jest niekompletny i nie należy go traktować jako niezawodnej ścieżki migracji za jednym razem. Migracja z Nginx do Caddy to głównie ręczne przepisywanie, a większość z tego staje się krótsza.

Co się przekłada i staje się prostsze, według przewodnika konwersji od społeczności Caddy:

• Dla upstreamów HTTP, reverse_proxy przekazuje przychodzący Host nagłówek dalej i domyślnie ustawia standardowe nagłówki X-Forwarded-*, więc większość tych proxy_set_header linii znika.
• PHP zwija się z bloku location z try_files plus fastcgi_pass plus sterty parametrów do pojedynczej php_fastcgi dyrektywy.
• Obsługa WebSocket jest automatyczna w Caddy v2. Jeśli poradnik każe Ci dodać osobną websocket dyrektywę, to relikt Caddy v1. Zignoruj to.

Co nie przekłada się automatycznie: wszystko związane z konkretnym modułem Nginx, którego Caddy nie ma, złożona logika rewrite i location, którą trzeba będzie przemyśleć od nowa, a nie przenieść, oraz konfiguracje certyfikatów wildcard, które ponownie sprowadzają Cię do konfiguracji wyzwania DNS z sekcji powyżej. Zaplanuj czas na moduły i przepisania; reszta to zwykle netto zmniejszenie liczby linii.

Który zainstalować? (Decyzja)

Widziałeś konfiguracje, liczby, haczyk z wildcard i koszt migracji, więc oto do czego to prowadzi. Zainstaluj Caddy, jeśli jesteś samodzielnym programistą lub małym zespołem, to jest świeże wdrożenie VPS, chcesz TLS w stylu ustaw i zapomnij, uruchamiasz Dockera z prostym routingiem albo po prostu chcesz konfiguracji mieszczącej się w pamięci mięśniowej. To większość osób czytających ten tekst.

Zainstaluj Nginx, jeśli potrzebujesz szczegółowej kontroli lub konkretnego modułu z jego dojrzałego ekosystemu, wyciskasz wydajność z serwera o ograniczonej pamięci, prowadzisz serwowanie plików statycznych o wysokiej równoczesności albo Twój zespół ma już głęboką wiedzę o Nginx i stertę działających konfiguracji. To solidne powody, a jeśli któryś z nich jest Twój, Nginx to właściwy wybór. To nie jest przypadek, w którym starsze narzędzie jest niewłaściwym narzędziem.

Na którymkolwiek się zdecydujesz, następnym krokiem jest umieszczenie go na maszynie. Oba Caddy oraz Nginx są dostępne jako wdrożenia jednym kliknięciem w naszym marketplace, więc możesz pominąć pracę instalacyjną i przejść prosto do Caddyfile lub bloku serwera. VPS z 1 GB to rozsądny punkt startu dla wdrożenia jednej witryny o niskim ruchu, ale dobierz rozmiar serwera do aplikacji i ruchu za proxy, a nie do samego proxy. Jeśli używasz Caddy jako drzwi wejściowych dla samodzielnie hostowanych usług, może on stać przed stosem monitorującym Prometheus i Grafana lub wdrożeniem Uptime Kuma bez potrzeby stosowania osobnych narzędzi TLS.

Wniosek z sekcji: wybierz Caddy, chyba że masz konkretny powód wskazujący na Nginx.

Często zadawane pytania