Caddy vs. Nginx på en VPS: Sammenligningen af konfigurationsfiler

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;
}

TLS-linjerne i Nginx-blokken antager, at Certbot allerede er kørt. For en HTTP-upstream som den ovenfor sender Caddy den indgående Host header videre og sætter X-Forwarded-For, X-Forwarded-Proto, og X-Forwarded-Host som standard. Med Nginx tilføjer du normalt proxy-headerne eksplicit, når upstream'en har brug for den oprindelige host, det oprindelige scheme og kæden af klientadresser. Det er afvejningen i miniature: Caddy leveres med praktiske proxy-standarder, mens Nginx gør mere af den adfærd eksplicit.

Servering af statiske filer:

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, der beskytter alt bag et brugernavn og en adgangskode:

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;
    }
}

Begge værktøjer hasher adgangskoden out of band. Caddy bruger caddy hash-password; Nginx bruger htpasswd til at bygge .htpasswd-filen. Direktivet hedder basic_auth i den aktuelle Caddy, i øvrigt. Det hed basicauth indtil v2.8.0 omdøbte det, som anført i Caddy basic_auth-dokumentationen, og gamle tutorials får stadig folk til at snuble over det.

Pro-tip: Den hash i Caddyfile'en er ikke adgangskoden. Det er bcrypt-output fra caddy hash-password. Kør kommandoen, og indsæt det, den udskriver. Caddy afviser klartekst-adgangskoder i konfigurationen, hvilket er den korrekte standard og en lille overraskelse første gang.

Konfigurationerne fører deres egen sag. Caddy folder TLS, fornuftige proxy-headere og en omdirigering ind i nogle få linjer; Nginx er eksplicit og omfattende og giver dig hver eneste knap. Hvis du har brugt år i Nginx, sidder omfanget i rygmarven, og kontrollen er selve pointen. Hvis du ikke har, er Caddyfile'en en konfiguration, du kan holde i hovedet. Den praktiske pointe er enkel: Caddys konfiguration er lettere at læse ved et hurtigt kig, mens Nginx giver dig mere eksplicit kontrol.

Ydelse og hukommelse: At læse benchmarks omhyggeligt

Offentliggjorte tests peger i samme generelle retning: Nginx bruger som regel mindre hukommelse og fører ofte på rå gennemstrømning, men størrelsen af den fordel afhænger i høj grad af miljøet.

In én tredjeparts test på en firekernet VM, nåede Nginx cirka 48.000 requests i sekundet mod omkring 42.000 for Caddy. Den samme test rapporterede en HTTPS p99-latens på 2,1 ms for Nginx og 2,4 ms for Caddy. Behandl dem som resultater fra én opsætning snarere end en universel ydelsesmargin.

Hukommelsesintervallerne i sammenligningstabellen kommer fra en separat VPS-test. En anden syntetisk test ved 50.000 samtidige forbindelser rapporterede 145 MB for Nginx og 520 MB for Caddy, men den test brugte væsentligt anderledes hardware- og workload-forhold. Dens absolutte tal bør ikke sammenlignes direkte med VPS-tallene ovenfor.

Den pålidelige konklusion er snævrere: Nginx har generelt det mindre hukommelsesfodaftryk og har tendens til at føre under workloads med høj gennemstrømning eller høj samtidighed. For en almindelig lille til mellemstor VPS-reverse-proxy er begge som regel hurtige nok, så driftsmæssig enkelhed er ofte den mere nyttige afgørende faktor.

Afsnitskonklusion: vælg ud fra drift, medmindre din server er hukommelsesbegrænset, eller dine egne belastningstests viser, at proxy-gennemstrømning er flaskehalsen.

Wildcard-cert-hagen (Caddy er ikke altid zero-config)

Caddy kan automatisere wildcard-certifikater, men ikke med sine standard-HTTP-01- eller TLS-ALPN-01-udfordringer. Et certifikat til *.example.com kræver DNS-01-validering, som Let's Encrypt kræver for wildcard-certifikater. Det betyder et DNS-provider-plugin (bygget ind i din Caddy-binary via xcaddy) plus et API-token til din DNS-host, konfigureret i tls-blokken. Det er ikke den skriv-én-linje-og-gå-væk-historie, som Caddy markedsfører.

Det rammer homelab-brugere, der placerer mange tjenester under et rigtigt domæne, de kontrollerer, såsom *.home.example.com, og antager, at wildcard-udstedelse er lige så automatisk som app.example.com. For rent interne navne som *.homelab.internal, så behandl det som lokalt/internt PKI-territorium, ikke en offentlig Let's Encrypt-wildcard. For at være præcis: Caddy klarer wildcards fint, den gør det bare ikke med standardudfordringerne, og opsætningen er et trin op fra tilfældet med et enkelt domæne. Nginx er i samme båd her, eftersom kravet om DNS-01 kommer fra Let's Encrypt, ikke serveren.

Hvis du vil have en GUI: Nginx Proxy Manager (en kort bemærkning)

Nginx Proxy Manager er et helt andet dyr end de to værktøjer ovenfor, og det er et afsnit værd, fordi navnet forvirrer folk. NPM er en GUI-wrapper oven på Nginx: den administrerer reverse-proxy-regler og Let's Encrypt-certifikater gennem et webinterface på port 81. Det er ikke Nginx-kernen, og det konfigureres ikke, som Nginx-kernen gør.

Afvejningen er den sædvanlige klik-mod-konfiguration. NPM er den nemme knap, indtil du træder uden for den lige vej. Dens konfiguration administreres gennem en applikationsdatabase snarere end en enkelt håndredigeret konfigurationsfil. Standard- Docker-opsætningen bruger SQLite, mens MySQL/MariaDB og PostgreSQL er understøttede eksterne databasemuligheder. Den forskel påvirker også portabiliteten: en Caddy-opsætning kan ofte flyttes ved at kopiere en enkelt Caddyfile, mens en Nginx Proxy Manager-deployment kræver, at dens applikationsdata og database bevares. NPM er et fint valg, hvis du reelt foretrækker at klikke frem for at redigere, og din opsætning forbliver enkel. Det er det forkerte valg til en infrastructure-as-code-arbejdsgang.

Migrering fra Nginx til Caddy (hvad der oversættes, og hvad der ikke gør)

Hvis du allerede er på Nginx og overvejer skiftet, så begynd med at sænke dine forventninger til automatisering: der findes en Caddy NGINX-konfigurationsadapter, men den er ufuldstændig og bør ikke behandles som en pålidelig migreringsvej i ét træk. En migrering fra Nginx til Caddy er for det meste en manuel omskrivning, og det meste af den bliver kortere.

Hvad der oversættes og bliver enklere, ifølge Caddy-communityets konverteringsguide:

• For HTTP-upstreams reverse_proxy sender den indgående Host header videre og sætter standard-X-Forwarded-*-headerne som standard, så de fleste af disse proxy_set_header linjer forsvinder.
• PHP skrumper fra en location-blok med try_files plus fastcgi_pass plus en bunke parametre til et enkelt php_fastcgi direktiv.
• WebSocket-håndtering er automatisk i Caddy v2. Hvis en tutorial beder dig tilføje et separat websocket direktiv, er det en levning fra Caddy v1. Ignorer det.

Hvad der ikke oversættes automatisk: alt, der er knyttet til et specifikt Nginx-modul, som Caddy ikke har, kompleks rewrite- og location-logik, som du bliver nødt til at gentænke snarere end at overføre, og wildcard-cert-opsætninger, som fører dig tilbage til DNS-udfordringsopsætningen fra afsnittet ovenfor. Afsæt tid til modulerne og omskrivningerne; resten er som regel en nettoreduktion i antal linjer.

Hvilken skal du installere? (Beslutningen)

Du har set konfigurationerne, tallene, wildcard-hagen og migreringsomkostningen, så her er, hvor det lander. Installer Caddy, hvis du er en soloudvikler eller et lille team, dette er en ny VPS-deployment, du vil have set-and-forget-TLS, du kører Docker med simpel routing, eller du bare vil have en konfiguration, der sidder i rygmarven. Det er de fleste, der læser dette.

Installer Nginx, hvis du har brug for finkornet kontrol eller et specifikt modul fra dets modne økosystem, du presser ydelse ud af en hukommelsesbegrænset server, du laver servering af statiske filer med høj samtidighed, eller dit team allerede har dyb Nginx-ekspertise og en bunke fungerende konfigurationer. Det er solide grunde, og hvis en af dem er din, er Nginx det rigtige valg. Dette er ikke et tilfælde, hvor det ældre værktøj er det forkerte værktøj.

Uanset hvilken du lander på, er næste skridt at få den på maskinen. Begge Caddy og Nginx er tilgængelige som one-click-deployments i vores marketplace, så du kan springe installationsarbejdet over og gå direkte til Caddyfile'en eller serverblokken. En 1 GB VPS er et fornuftigt udgangspunkt for en single-site-deployment med lav trafik, men dimensioner serveren efter applikationen og trafikken bag proxyen snarere end proxyen alene. Hvis du bruger Caddy som hoveddør for selvhostede tjenester, kan den sidde foran en overvågningsstack med Prometheus og Grafana eller en Uptime Kuma-deployment uden at kræve separat TLS-værktøj.

Afsnitskonklusion: vælg Caddy, medmindre du har en specifik grund, der peger på Nginx.

Ofte stillede spørgsmål