Як усталяваць вэб-сервер Caddy з аўтаматычным HTTPS

Caddy — вэб-сервер, які па змаўчанні сам атрымлівае і працягвае сертыфікаты TLS. Для невялікага VPS з адным-двума даменамі гэта прыбірае цэлы слой таймераў Certbot і фрагментаў Nginx. Мова канфігурацыі (Caddyfile) кароткая. Зваротны проксі, gzip і HTTP/2 — звычайныя магчымасці, а не выхадныя з модулямі.

Nginx і далей дарэчны, калі канфігі ўжо абкатаныя або патрэбны рэдкі модуль. Гэты гайд — пра іншы часты выпадак: HTTPS на свежым VPS Hiddence без завучвання include. Паставім Caddy з афіцыйнага apt, разбяром, як ён гаворыць з Let's Encrypt, аддадзім статыку, проксуем лакальную праграму, павесім некалькі даменаў, паглядзім логі і тыповую бойку за порт 80 з Apache або старым Nginx.

Калі Caddy добра заходзіць

Аўтаматычны HTTPS — загаловак, а ў побыце выйгрыш у меншай колькасці рухомых частак. Caddy слухае 80 і 443, пераводзіць HTTP на HTTPS і захоўвае сертыфікаты ў сваім каталогу даных. Дамен на VPS усё роўна патрэбны. ACME ўсё роўна можна зламаць (закрыты 80/tcp, чужы працэс на :80). Wildcard-сертыфікат патрабуе модуля DNS-правайдара — гэта даўжэй, чым сертыфікат на адзін хост.

• Самі HTTP→HTTPS і працяг сертыфіката
• Чытабельны Caddyfile замест доўгіх блокаў server
• Зваротны проксі для Node, Python, PHP-FPM (з дадатковай наладкай) або кантэйнераў Docker
• HTTP/2 і нармальныя налады TLS без табліцы шыфраў
• Гатовы unit systemd з афіцыйнага пакета

Што патрэбна

Дамен павінен рэзолвіцца на гэты VPS да таго, як Caddy дакажа ACME HTTP-01. Пакуль DNS раз’язджаецца, выпуск падае і паўтараецца — здаецца, што «Caddy зламаны», хоць вінаваты толькі DNS. Apache або Nginx спыніце, калі яны трымаюць 80/443.

• Ubuntu 22.04 або 24.04
• A-запіс дамена на IP VPS (і AAAA, калі выкарыстоўваеце IPv6)
• Парты 80 і 443 вольныя і дазволеныя ў фаерволе
• Root або sudo

Крок 1. Усталёўка з афіцыйнага рэпазіторыя

Не бярыце выпадкова стары Caddy з universe Ubuntu, калі патрэбныя актуальныя TLS і ACME. У праекта Caddy ёсць apt-крыніца. Пасля ўсталёўкі з’яўляецца карыстальнік caddy, служба ўключаецца.

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

Крок 2. Першы Caddyfile — статычны сайт

Файл па змаўчанні — /etc/caddy/Caddyfile. Падстаўце свой дамен. Caddy паспрабуе ўзяць сертыфікат адразу пасля загрузкі канфіга, калі імя не localhost. Файлы сайта пакладзіце ў каталог, які можа чытаць карыстальнік 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

Крок 3. Зваротны проксі да лакальнай праграмы

Калі Gunicorn, Node або Docker слухаюць 127.0.0.1:8000, Caddy павінен быць адзіным публічным працэсам. Дырэктыва reverse_proxy нармальна перадае Host і X-Forwarded-* для большасці праграм. Калі праграма генеруе абсалютныя HTTP-спасылкі, уключыце давер да проксі ў самой праграме (SECURE_PROXY_SSL_HEADER у Django, trust proxy у Express і г.д.).

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

Крок 4. Фаервол і systemd

Дазвольце 80 і 443. Служба — caddy.service; пасля правак Caddyfile дастаткова reload, калі працэс жывы. Калі мяняеце зменныя для DNS-плагіна, зразумелейшы поўны restart. Сертыфікаты па змаўчанні ляжаць пад /var/lib/caddy/.local/share/caddy/ — гэты шлях варта капіяваць, калі часта пераўсталёўваеце сістэму і не хочаце ўпірацца ў ліміты Let's Encrypt.

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/

Крок 5. Логі, сціск і загалоўкі

Часопіс доступу дапамагае, калі бот долбіць шлях або вы ловіце 404. Логі можна ўключыць на сайт. Загалоўкі бяспекі для браўзернай праграмы дадавайце асэнсавана: доўгі HSTS браўзеры запамінаюць.

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

Крок 6. PHP і іншыя дапаўненні

Caddy умее php_fastcgi да PHP-FPM. Для часткі WordPress і Laravel гэтага хапае, але FPM усё роўна трэба паставіць і ўказаць правільны сокет. Калі ў вас ужо ідэальны PHP-канфіг Nginx, пераязджаць за адзін вечар не абавязкова — Caddy мацнейшы на звязцы «статыка + проксі + аўтаматычны 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

Пераезд з Nginx без сюрпрызаў

Спыніце Nginx да запуску Caddy, інакш яны б’юцца за 80/443. За дзень да змены IP зменшыце TTL DNS. Правярайце curl --resolve, каб біць у новы VPS да змены A-запісу. Канфігі Nginx патрымайце ў git тыдзень на выпадак адкату.

• systemctl stop nginx && systemctl disable nginx
• Пастаўце Caddy, праверце Caddyfile, запусціце службу
• curl -I --resolve example.com:443:NEW_IP https://example.com
• Толькі потым мяняйце DNS, калі IP новы
• Выпуск сертыфіката аўтаматычны; Certbot на той самы хост паралельна не ганяйце

Калі нешта не працуе

Збоі ACME амаль заўсёды DNS, фаервол або чужая служба на 80. У логах Caddy гэта tls.obtain. Сайт адкрываецца па HTTP, але не па HTTPS — выпуск не завяршыўся. Занадта шмат сертыфікатаў — ліміт Let's Encrypt; на тэстах выкарыстоўвайце staging CA, не баявы.

• validate не праходзіць: сінтаксіс Caddyfile, прапушчаная дужка
• permission denied на root: chown caddy для каталога сайта
• bind: address already in use — ss -tulpn | grep -E ':80|:443'
• Таймаўт сертыфіката: dig +short дамена з VPS, ufw allow 80
• 502 у reverse_proxy: бэкенд мёртвы або localhost указаны не з той сеткі (кантэйнеры)

Заўвагі па абароне

Налады TLS у Caddy умераныя. Ваша зона — праграма і SSH. Адмін-API Caddy на публічны інтэрфейс не выстаўляйце: па змаўчанні ён лакальны, так і пакіньце. Caddyfile з інтэрнэту чытайце цалкам: фрагмент, які проксуе /* на ўнутраны IP, можа стаць адкрытым проксі.

• Адмін-API звонку не адкрываць
• Пакет абнаўляць
• HSTS — толькі калі HTTPS дакладна працуе на ўсіх імёнах
• Тэставыя і баявыя імёны развядзіце, каб не спаліць ліміт ACME

Парады

• caddy fmt --overwrite /etc/caddy/Caddyfile робіць файл чытабельным
• import-фрагменты, калі сайтаў шмат і яны падобныя
• У Docker часта вобраз caddy:alpine і прымантаваны Caddyfile
• Wildcard патрэбны DNS-модуль і токен API — токен беражыце
• Спачатку journalctl -u caddy, потым перапісванне ўсяго файла

Caddy на VPS — афіцыйны пакет, кароткі Caddyfile, адкрытыя 80/443, DNS ужо глядзіць на сервер, reload systemd пасля правак. Статыка або зваротны проксі перад Gunicorn, Node ці Docker. Аўтаматычны HTTPS працуе, калі ACME адказвае на порце 80; калі выпуск падае, ладзьце DNS і канфлікт партоў, а не «сам Caddy». Каталог /var/lib/caddy капіюйце, калі часта пераўсталёўваеце сістэму.