Jak nainstalovat webový server Caddy s automatickým HTTPS

Caddy je webový server, který ve výchozím stavu získává a obnovuje certifikáty TLS. Pro malý VPS s jednou nebo dvěma doménami to odstraňuje celou třídu timerů Certbot a úryvků Nginx. Konfigurační jazyk (Caddyfile) je krátký. Reverse proxy, gzip a HTTP/2 jsou běžné funkce, ne víkend extra modulů.

Nginx je pořád správná volba v některých týmech: už máte v boji otestované konfigy, nebo potřebujete velmi specifický modul. Tento návod je pro druhý častý případ — chcete HTTPS, které na čerstvém VPS Hiddence funguje bez biflování include. Nainstalujeme Caddy z oficiálního apt repa, vysvětlíme, jak mluví s Let's Encrypt, naservírujeme statický web, proxyneme lokální aplikaci, hostujeme několik domén, podíváme se na logy a obvyklé bitvy o port 80 s Apache nebo starým Nginx.

Kdy Caddy sedí

Automatické HTTPS je headline, ale denní výhra je méně pohyblivých částí. Caddy poslouchá na 80 a 443, přesměrovává HTTP na HTTPS a ukládá certy ve svém datovém adresáři. Pořád potřebujete doménu mířící na VPS. Pořád nesmíte rozbít ACME (firewall 80/tcp, žádný jiný proces nekrade :80). Wildcard certifikáty potřebují modul poskytovatele DNS — to je delší cesta než cert na jeden host.

• Automatické HTTP→HTTPS a obnova certifikátu
• Čitelný Caddyfile místo dlouhých bloků server
• Schopné reverse proxy pro Node, Python, PHP-FPM (s extra konfigem) nebo backendy Docker
• HTTP/2 a moderní výchozí TLS bez tabulky šifer
• Unit systemd z oficiálního balíčku

Požadavky

Doména se musí resolvovat na tento VPS, než Caddy dokáže ACME HTTP-01. Pokud se DNS ještě šíří, Caddy vydání selže a zkusí to znovu; vypadá to jako „Caddy je rozbitý“, ačkoli je to jen DNS. Apache nebo Nginx nejdřív zastavte, pokud drží 80/443.

• Ubuntu 22.04 nebo 24.04
• A záznam domény na IP VPS (a AAAA, pokud používáte IPv6)
• Porty 80 a 443 volné a povolené ve firewallu
• Root nebo sudo

Krok 1. Nainstalujte Caddy z oficiálního repozitáře

Neinstalujte náhodný starý Caddy z výchozího universe Ubuntu, pokud chcete aktuální TLS a ACME. Projekt Caddy dokumentuje zdroj apt. Po instalaci existuje uživatel caddy a služba je zapnutá.

ssh root@YOUR_VPS_IP
apt update && apt -y install debian-keyring debian-archive-keyring apt-transport-https curl gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list

apt update
apt -y install caddy

caddy version
systemctl status caddy --no-pager

Krok 2. První Caddyfile — statický web

Výchozí Caddyfile je /etc/caddy/Caddyfile. Nahraďte ho svou doménou. Caddy se pokusí získat certifikát hned po načtení konfigu, pokud hostname není localhost. Soubory webu dejte do adresáře čitelného uživatelem caddy (často práva ve stylu www-data, ale balíček používá uživatele caddy).

mkdir -p /var/www/example
echo '<h1>It works</h1>' > /var/www/example/index.html
chown -R caddy:caddy /var/www/example

cat >/etc/caddy/Caddyfile <<'EOF'
example.com {
    root * /var/www/example
    file_server
    encode gzip
}
EOF

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

# Watch issuance:
journalctl -u caddy -f

Krok 3. Reverse proxy lokální aplikace

Pokud Gunicorn, Node nebo Docker poslouchá na 127.0.0.1:8000, Caddy by měl být jediný veřejný proces. Direktiva reverse_proxy předává Host a X-Forwarded-* rozumně pro většinu aplikací. Pokud aplikace generuje absolutní HTTP URL, nastavte v aplikaci důvěru k proxy / příznaky HTTPS (Django SECURE_PROXY_SSL_HEADER, Express trust proxy a podobně).

app.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:8000
}

# Several hosts in one file are normal:
# blog.example.com {
#     root * /var/www/blog
#     file_server
# }

Krok 4. Firewall a systemd

Povolte 80 a 443. Unit Caddy je caddy.service; po úpravách Caddyfile stačí reload, pokud je proces zdravý. Pokud měníte proměnné prostředí DNS pluginu, je jasnější plný restart. Certifikáty ve výchozím stavu leží pod /var/lib/caddy/.local/share/caddy/ — tuto cestu zahrňte do záloh, pokud vám při reinstalaci záleží na limitech.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

systemctl enable --now caddy
systemctl reload caddy

# Backup cert storage (path may vary slightly by version):
ls -la /var/lib/caddy/

Krok 5. Logy, komprese a hlavičky

Access logy pomáhají, když bot mlátí cestu nebo ladíte 404. Můžete logovat per web. Přidejte bezpečnostní hlavičky, pokud hostujete prohlížečovou aplikaci; nekopírujte obří balík hlaviček bez pochopení HSTS (jakmile nastavíte dlouhý max-age, prohlížeče si ho pamatují).

example.com {
    root * /var/www/example
    file_server
    encode gzip
    log {
        output file /var/log/caddy/example.log
    }
    header {
        X-Content-Type-Options nosniff
        Referrer-Policy no-referrer-when-downgrade
        -Server
    }
}

mkdir -p /var/log/caddy
chown caddy:caddy /var/log/caddy
systemctl reload caddy

Krok 6. PHP a další doplňky

Caddy umí mluvit s PHP-FPM direktivou php_fastcgi. To stačí mnoha hostitelům WordPress nebo Laravel, ale pořád potřebujete nainstalované php-fpm a odpovídající cestu socketu. Pokud už máte dokonalý PHP konfig Nginx, migrace za jeden večer je volitelná — Caddy víc září na reverse proxy + statiku + automatický TLS.

example.com {
    root * /var/www/example
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

# Confirm FPM is running:
systemctl status php8.3-fpm

Migrace z Nginx bez překvapení o downtime

Nginx zastavte před startem Caddy, jinak se poperou o 80/443. Den předem snižte TTL DNS, pokud také stěhujete IP. Testujte curl --resolve, abyste trefili nový VPS před změnou A záznamu. Konfigy Nginx nechte v gitu týden pro případ rollbacku.

• systemctl stop nginx && systemctl disable nginx
• Nainstalujte Caddy, ověřte Caddyfile, spusťte Caddy
• curl -I --resolve example.com:443:NEW_IP https://example.com
• Teprve pak změňte DNS, pokud je IP nové
• Vydání je automatické; nespouštějte zároveň Certbot proti stejnému hostname

Řešení problémů

Selhání ACME jsou skoro vždy DNS, firewall nebo jiná služba na portu 80. Řádky logu Caddy zmiňují tls.obtain. Pokud web funguje na HTTP, ale ne na HTTPS, vydání se nikdy nedokončilo. Pokud vidíte moc certifikátů, trefili jste limity Let's Encrypt — při testech používejte staging CA, ne produkci.

• validate selže: syntaxe Caddyfile, chybějící závorka
• permission denied na root: chown caddy pro adresář webu
• bind: address already in use — ss -tulpn | grep -E ':80|:443'
• timeout certifikátu: dig +short domény z VPS, ufw allow 80
• 502 reverse_proxy: backend padl, nebo jste proxovali na localhost ze sítě kontejnerů špatně

Bezpečnostní poznámky

Výchozí TLS Caddy jsou konzervativní. Vaše práce je bezpečnost aplikace a SSH. Nezapínejte admin API Caddy na veřejném rozhraní. Výchozí admin endpoint je lokální; nechte ho tak. Pokud berete Caddyfile z internetu, čtěte každý matcher — úryvek, který reverse_proxies /* na interní IP, se může stát otevřeným proxy.

• Nevystavujte admin API
• Balíček aktualizujte
• HSTS až když jste si jistí, že HTTPS funguje na všech hostname
• Oddělte testovací a produkční jména, abyste chránili limity ACME

Tipy

• caddy fmt --overwrite /etc/caddy/Caddyfile drží soubor čitelný
• Používejte import snippetů, když máte mnoho podobných webů
• V Dockeru je běžný obraz caddy:alpine s namountovaným Caddyfile
• Wildcard certy potřebují DNS modul a API token — token chraňte
• Čtěte journalctl -u caddy, než přepíšete celý soubor

Caddy na VPS je: oficiální balíček, krátký Caddyfile, otevřené 80/443, DNS už mířící na server a reload systemd po úpravách. Používejte ho jako server statických souborů nebo reverse proxy před Gunicorn, Node nebo Docker. Automatické HTTPS funguje, když ACME umí odpovědět na portu 80; pokud vydání selže, opravte DNS a konflikty portů, než obviníte Caddy. Zálohujte /var/lib/caddy, pokud často reinstalujete.