Как установить и настроить Caddy с авто-SSL на VPS

MAATRIX

Возня с сертификатами — то, что раздражает в веб-сервере больше всего: выпустить, прописать пути, не забыть про автопродление, починить, когда оно всё-таки сломалось. Caddy с авто-SSL на VPS убирает эту боль целиком: он сам получает сертификат Let's Encrypt при первом запросе, сам продлевает его и сам включает HTTPS. Вам остаётся написать несколько строк конфига.

Чем Caddy отличается от Nginx и Apache

Главная идея Caddy — безопасность по умолчанию. Там, где Nginx требует отдельно поставить certbot, выпустить сертификат и вручную дописать блок ssl, Caddy делает всё сам. Вы указываете домен — он при первом обращении проходит проверку ACME, получает сертификат и поднимает HTTPS. Никаких таймеров продления настраивать не нужно: обновление встроено в сам сервер.

Второе отличие — лаконичность конфигурации. Формат Caddyfile настолько компактный, что рабочий реверс-прокси с HTTPS умещается в две строки, тогда как эквивалент на Nginx займёт пару десятков. Это не только удобство: чем меньше конфиг, тем меньше мест, где можно ошибиться.

Есть и обратная сторона, о которой честно стоит сказать. Caddy менее распространён, у него меньше готовых рецептов в интернете, а под очень тонкую низкоуровневую настройку и экзотические сценарии Nginx всё ещё гибче. Но для типовой задачи «отдать сайт или приложение по HTTPS без головной боли» Caddy сегодня — самый быстрый путь.

Подготовка VPS перед установкой

Для роли веб-сервера и прокси Caddy нетребователен: 1 ядро и 1 ГБ RAM с запасом покрывают отдачу статики и проксирование. Ресурсы имеет смысл наращивать под то, что стоит за Caddy, — базы, приложения, транскодинг, — а не под сам сервер.

Критичное условие для авто-SSL — правильно настроенный домен и открытые порты. Caddy проходит ACME-проверку по портам 80 и 443, поэтому оба должны быть доступны снаружи, а домен — указывать A-записью на IP вашего VPS. Откройте порты в фаерволе:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Проверьте, что домен уже резолвится на нужный адрес, иначе выпуск сертификата не пройдёт:

dig +short example.com

Локация сервера здесь решает практическую задачу: для российской аудитории меньше пинг с RU-площадки, для доступа к зарубежным сервисам удобнее US, для Европы — UK. У MAATRIX доступны все три с оплатой из России картой, СБП или криптой, так что выбор диктует задача, а не платёжные ограничения.

Установка Caddy на Ubuntu и Debian

Caddy ставится из официального репозитория пакетом — это предпочтительный способ, потому что тянет свежую версию и systemd-юнит:

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
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 install caddy -y

После установки сервис уже запущен и работает под своим systemd-юнитом. Проверьте:

systemctl status caddy
caddy version

Конфигурация по умолчанию лежит в /etc/caddy/Caddyfile. Именно его мы и будем править. Все изменения применяются командой перезагрузки, которая не роняет активные соединения:

systemctl reload caddy

Минимальный Caddyfile с авто-SSL

Вот вся конфигурация, которая нужна, чтобы отдать статический сайт по HTTPS с автоматическим сертификатом. Отредактируйте /etc/caddy/Caddyfile:

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

Перезагрузите Caddy — и при первом обращении к домену он сам получит сертификат Let's Encrypt, включит HTTPS и настроит редирект с HTTP. Ничего больше делать не нужно: ни путей к сертификатам, ни таймеров, ни отдельных блоков для 80 и 443 порта. Всё это Caddy берёт на себя.

Если нужен реверс-прокси на приложение — конфиг почти такой же короткий:

app.example.com {
    reverse_proxy 127.0.0.1:3000
}

Эта пара строк даёт полноценный HTTPS-прокси с автоматическим сертификатом. Заголовки X-Forwarded-For, X-Forwarded-Proto и Host Caddy проставляет сам, в отличие от Nginx, где их нужно прописывать руками. Для WebSocket тоже ничего дополнительно настраивать не надо — Caddy определяет апгрейд соединения автоматически.

Стоит понимать логику формата. Каждый блок в Caddyfile начинается с адреса сайта, а внутри фигурных скобок перечисляются директивы: отдать статику, проксировать на бэкенд, добавить сжатие, переписать пути. Один Caddyfile спокойно держит десятки таких блоков — по одному на каждый домен или поддомен, — и каждый получает свой сертификат независимо. Именно поэтому Caddy удобен, когда на одном VPS живёт несколько небольших сайтов: добавление ещё одного проекта — это ещё три-четыре строки конфига, а не отдельная возня с сертификатами. Порядок директив внутри блока Caddy определяет сам по разумным умолчаниям, так что думать о нём, как в Nginx, почти не приходится.

Проверка сертификата и типовые нюансы

После первого запуска убедитесь, что сертификат действительно выпустился. Быстрее всего — заглянуть в логи Caddy, где виден весь процесс ACME:

journalctl -u caddy --no-pager | tail -n 40

Полученные сертификаты Caddy хранит в своём каталоге данных, обычно в /var/lib/caddy/.local/share/caddy. Трогать их руками не нужно — сервер управляет ими сам. Если выпуск не прошёл, причина почти всегда в одном из трёх: домен не указывает на этот сервер, закрыт порт 80 или 443, либо вы упёрлись в лимит Let's Encrypt на выпуск. Последнее лечится тестовым центром сертификации на время отладки.

Для внутренних и локальных сервисов, где публичный сертификат не выпустить, у Caddy есть режим локального центра сертификации — он выдаёт самоподписанный сертификат и работает по HTTPS даже на адресе без домена. Это удобно для админок и стендов, недоступных из интернета.

Ещё один практичный момент — продление. В отличие от связки Nginx с certbot, где обновление держится на systemd-таймере, который может незаметно сломаться, Caddy продлевает сертификаты сам и заблаговременно, обычно за месяц до истечения срока. Это значит, что классическая ситуация «сайт лёг ночью, потому что сертификат протух» с Caddy практически исключена. Если же вы отдаёте сразу много доменов, обратите внимание на первый запуск: сервер выпускает сертификаты по мере первых обращений, поэтому самый первый заход на каждый новый домен может занять на секунду-две дольше, пока идёт ACME-проверка. Дальше всё работает мгновенно из кеша.

Логи, автозапуск и обслуживание

Caddy уже прописан в автозагрузку через systemd, поэтому после перезагрузки VPS поднимается сам. Убедиться в этом можно командой systemctl is-enabled caddy — она должна вернуть enabled. Логи веб-сервера идут в journald, и смотреть их удобно через journalctl; при желании можно направить структурированный лог в файл прямо из Caddyfile блоком log.

Обслуживание сводится к малому. Обновляйте пакет вместе с системой через apt upgrade, держите порты закрытыми фаерволом кроме нужных, а сертификаты не трогайте — продление полностью автоматическое и происходит заблаговременно, задолго до истечения срока. По сути, после первичной настройки о Caddy можно забыть на месяцы. Если проект вырастет и за прокси появится несколько сервисов, тот же короткий Caddyfile легко масштабируется добавлением новых блоков — и всё это спокойно живёт на недорогом VPS с чистым IP.

Частые вопросы