Înapoi la blog
August 19, 2026Ghiduri

Cum să instalezi serverul web Caddy cu HTTPS automat

Instalează Caddy pe Ubuntu din depozitul oficial, scrie un Caddyfile pentru site-uri statice și reverse proxy-uri, înțelege certificatele automate, systemd, jurnalele și greșelile comune la migrarea de la Nginx.

Cum să instalezi serverul web Caddy cu HTTPS automat

Caddy este un server web care obține și reînnoiește certificate TLS implicit. Pentru un VPS mic care găzduiește unul sau două domenii, asta elimină o întreagă clasă de temporizatoare Certbot și fișiere snippet Nginx. Limbajul de configurare (Caddyfile) e scurt. Reverse proxy, gzip și HTTP/2 sunt funcții normale, nu un weekend de module extra.

Nginx e încă alegerea potrivită pentru unele echipe: aveți deja configurații testate în luptă sau aveți nevoie de un modul foarte specific. Acest ghid e pentru celălalt caz comun — vrei HTTPS care funcționează pe un VPS Hiddence proaspăt fără să memorezi snippet-uri include. Vom instala Caddy din depozitul apt oficial, vom explica cum vorbește cu Let's Encrypt, vom servi un site static, vom proxy o aplicație locală, vom găzdui mai multe domenii, vom privi jurnalele și vom acoperi luptele obișnuite pe portul 80 cu Apache sau un Nginx vechi.

Când Caddy se potrivește bine

HTTPS automat e titlul, dar câștigul zilnic e mai puține piese în mișcare. Caddy ascultă pe 80 și 443, redirecționează HTTP către HTTPS și stochează certificatele în directorul său de date. Tot ai nevoie de un domeniu care pointează către VPS. Tot ai nevoie să nu strici ACME (firewall 80/tcp, niciun alt proces care fură :80). Certificatele wildcard au nevoie de un modul de furnizor DNS — e o cale mai lungă decât un certificat pentru o singură gazdă.

  • HTTP→HTTPS automat și reînnoirea certificatului
  • Caddyfile lizibil în loc de blocuri lungi de server
  • Reverse proxy capabil pentru Node, Python, PHP-FPM prin configurație extra sau backend-uri Docker
  • HTTP/2 și implicite TLS moderne fără un tabel de cifruri
  • Unitate systemd din pachetul oficial

Cerințe

Un domeniu trebuie să se rezolve către acest VPS înainte ca Caddy să poată dovedi ACME HTTP-01. Dacă DNS încă se propagă, Caddy va eșua la emitere și va reîncerca; arată ca «Caddy e stricat» când e doar DNS. Oprește Apache sau Nginx mai întâi dacă ei dețin 80/443.

  • Ubuntu 22.04 sau 24.04
  • O înregistrare A de domeniu către IP-ul VPS (și AAAA dacă folosești IPv6)
  • Porturile 80 și 443 libere și permise în firewall
  • Root sau sudo

Pasul 1: Instalează Caddy din depozitul oficial

Nu instala un Caddy vechi aleatoriu din universe-ul implicit Ubuntu dacă vrei comportament TLS și ACME actual. Proiectul Caddy documentează o sursă apt. După instalare, utilizatorul caddy există și serviciul e activat.

bash
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

Pasul 2: Primul Caddyfile — site static

Caddyfile-ul implicit e /etc/caddy/Caddyfile. Înlocuiește-l cu domeniul tău. Caddy va încerca să obțină un certificat imediat ce se încarcă configurația dacă numele de gazdă nu e localhost. Pune fișierele site-ului într-un director citibil de utilizatorul caddy (adesea permisiuni în stil www-data, dar pachetul folosește utilizatorul caddy).

bash
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

Pasul 3: Reverse proxy pentru o aplicație locală

Dacă Gunicorn, Node sau Docker ascultă pe 127.0.0.1:8000, Caddy ar trebui să fie singurul proces public. Directiva reverse_proxy înaintează headerele Host și X-Forwarded-* într-un mod rezonabil pentru majoritatea aplicațiilor. Dacă aplicația generează URL-uri HTTP absolute, setează flagurile trusted proxy / HTTPS în aplicație (Django SECURE_PROXY_SSL_HEADER, Express trust proxy și așa mai departe).

bash
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
# }

Pasul 4: Firewall și systemd

Permite 80 și 443. Unitatea Caddy e caddy.service; reload e suficient după editări Caddyfile dacă procesul e sănătos. Dacă schimbi variabile de mediu pentru un plugin DNS, o repornire completă e mai clară. Certificatele trăiesc implicit sub /var/lib/caddy/.local/share/caddy/ — include acea cale în backup-uri dacă îți pasă de limitele de rată la reinstalare.

bash
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/

Pasul 5: Jurnale, comprimare și headere

Jurnalele de acces ajută când un bot lovește o cale sau când depanezi 404-uri. Poți jurnaliza per site. Adaugă headere de securitate dacă găzduiești o aplicație de browser; nu copia un pachet uriaș de headere fără să înțelegi HSTS (odată ce setezi un max-age lung, browserele îl țin minte).

bash
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

Pasul 6: PHP și alte extra

Caddy poate vorbi cu PHP-FPM cu directiva php_fastcgi. Asta e suficient pentru multe gazde WordPress sau Laravel, dar tot ai nevoie de php-fpm instalat și o cale de socket care se potrivește. Dacă ai deja o configurație Nginx PHP perfectă, migrarea într-o seară e opțională — Caddy strălucește mai mult pe reverse proxy + static + TLS automat.

bash
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

Migrarea de la Nginx fără surprize de downtime

Oprește Nginx înainte să pornești Caddy, altfel se vor lupta pentru 80/443. Scade TTL-ul DNS cu o zi înainte dacă muți și IP-uri. Testează cu curl --resolve ca să poți lovi noul VPS înainte să schimbi înregistrarea A. Ține configurațiile Nginx în git o săptămână în caz că trebuie să revii.

  • systemctl stop nginx && systemctl disable nginx
  • Instalează Caddy, validează Caddyfile, pornește Caddy
  • curl -I --resolve example.com:443:NEW_IP https://example.com
  • Abia apoi schimbă DNS dacă IP-ul e nou
  • Reemiterea e automată; nu rula și Certbot împotriva aceluiași nume de gazdă

Depanare

Eșecurile ACME sunt aproape întotdeauna DNS, firewall sau alt serviciu pe portul 80. Liniile de jurnal Caddy menționează tls.obtain. Dacă site-ul merge pe HTTP dar nu pe HTTPS, emiterea nu s-a finalizat niciodată. Dacă vezi prea multe certificate, ai lovit limitele de rată Let's Encrypt — folosește CA de staging cât testezi, nu producția.

  • validate eșuează: sintaxă Caddyfile, acolada lipsă
  • permission denied on root: chown caddy pentru directorul site-ului
  • bind: address already in use — ss -tulpn | grep -E ':80|:443'
  • certificate timeout: dig +short domeniul de pe VPS, ufw allow 80
  • 502 reverse_proxy: backend oprit sau ai făcut proxy către localhost dintr-o rețea de containere greșit

Note de securitate

Implicitele TLS ale Caddy sunt conservatoare. Treaba ta e securitatea aplicației și SSH. Nu activa API-ul de administrare Caddy pe o interfață publică. Endpoint-ul de administrare implicit e local; lasă-l așa. Dacă folosești un Caddyfile de pe internet, citește fiecare matcher — un snippet care reverse_proxies /* către un IP intern poate deveni un proxy deschis.

  • Nu expune API-ul de administrare
  • Ține pachetul actualizat
  • HSTS doar după ce ești sigur că HTTPS funcționează pentru toate numele de gazdă
  • Separă numele de gazdă de test și producție pentru a proteja limitele de rată ACME

Sfaturi

  • caddy fmt --overwrite /etc/caddy/Caddyfile ține fișierul lizibil
  • Folosește snippet-uri import când ai multe site-uri similare
  • Pentru Docker, imaginea caddy:alpine cu un Caddyfile montat e comună
  • Certificatele wildcard au nevoie de un modul DNS și un token API — protejează acel token
  • Citește journalctl -u caddy înainte să rescrii tot fișierul

Caddy pe un VPS e: pachet oficial, un Caddyfile scurt, porturile 80/443 deschise, DNS care pointează deja către server și systemd reload după editări. Folosește-l ca server de fișiere statice sau ca reverse proxy în fața Gunicorn, Node sau Docker. HTTPS automat funcționează când ACME poate răspunde pe portul 80; dacă emiterea eșuează, repară DNS și conflictele de port înainte să dai vina pe Caddy. Fă backup la /var/lib/caddy dacă reinstalezi des.