Установка Caddy Server на Ubuntu: настройка HTTPS и Reverse Proxy

Caddy Server — это современный веб-сервер, который часто выбирают за простую настройку HTTPS и минимальную рутину с сертификатами. На практике его удобно ставить на VPS и использовать как обратный прокси или сервер для статических сайтов.

Ubuntu остаётся одной из самых стабильных платформ для таких задач. Ниже разберём установку так, как это обычно делается на рабочих серверах: без лишних шагов, но с пониманием, зачем каждый из них нужен.

Подготовка сервера Ubuntu

Если вы только купили сервер:
Подключитесь к серверу
Выполните подготовку сервера к работе

Далее устанавливаем утилиты, которые пригодятся для добавления репозитория:

    sudo apt install -y curl debian-keyring debian-archive-keyring apt-transport-https

Эти пакеты нужны для безопасного добавления внешнего репозитория Caddy. Без них система может отказаться доверять источнику.

Добавление официального репозитория Caddy

Caddy лучше ставить из официального репозитория. Это даёт актуальные версии и корректные обновления.

Добавляем GPG ключ:

    curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

Этот шаг нужен, чтобы система могла проверять подлинность пакетов. Без проверки подписи установка возможна, но уже менее безопасна.

Далее подключаем репозиторий:

    curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

После этого обновляем индекс пакетов:

    sudo apt update

Установка Caddy

Теперь устанавливаем сам сервер:

    sudo apt install -y caddy

После завершения Caddy автоматически создаёт systemd-сервис.

Проверить статус можно сразу:

    systemctl status caddy

Если всё нормально, сервис будет в состоянии active (running).

Базовая проверка работы

После установки Caddy уже может слушать порт 80. Это полезно для быстрой диагностики.

Проверка локально:

    curl -I http://localhost

Ответ HTTP 200 или 404 означает, что сервер жив и отвечает.

Настройка Caddyfile

Caddy строится вокруг идеи: один блок = один сайт или сервис.

Вы описываете:

какой домен обслуживать
что именно отдавать
куда проксировать запросы
нужны ли дополнительные правила

Также при использовании Caddy сертификат SSL настраивается автоматически и в конфиге путь к сертификату указывать не нужно.

Основная конфигурация находится здесь:

    /etc/caddy/Caddyfile

Открываем файл:

    sudo nano /etc/caddy/Caddyfile

Простой пример конфигурации:

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

example.com — Это домен, который будет обслуживать Caddy.

Например:

    mysite.ru

или

    blog.example.com

Когда запрос приходит на этот домен Caddy применяет правила внутри блока.

Фактически это аналог server_name в Nginx.

root * /var/www/html — эта строка указывает что файлы сайта лежат в /var/www/html.

То есть Caddy будет искать HTML, CSS, JS и картинки именно там.

Например:

    /var/www/html/index.html

file_server — включает раздачу файлов.

Без этой строки Caddy знает, где лежат файлы, но не начинает их отдавать.

Как работает сайт со статикой

Допустим у вас обычный HTML сайт.

Структура может быть такой:

    /var/www/site
├── index.html
├── style.css
└── logo.png

Тогда конфиг будет:

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

После reload:

    sudo systemctl reload caddy

Caddy начнёт отдавать этот сайт.

Можно ли добавить несколько сайтов?

Да.

Для каждого сайта нужен будет отдельный блок.

Например:

    site1.ru {
    root * /var/www/site1
    file_server
}

site2.ru {
    root * /var/www/site2
    file_server
}

Caddy автоматически поймёт:

какой домен открыл пользователь
какой сайт показать
какой сертификат использовать

Без ручной настройки SSL для каждого домена.

Можно ли смешивать сайты и приложения?

Да.

Например:

    static.example.com {
    root * /var/www/static-site
    file_server
}

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

app.example.com {
    reverse_proxy 127.0.0.1:8000
}

Так часто делают на VDS:

frontend отдельно
backend отдельно
API отдельно

Что происходит после изменения Caddyfile

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

Перезапуск и применение конфигурации

После изменений конфигурации нужно перезапустить сервис:

    sudo systemctl reload caddy

Reload предпочтительнее restart, потому что он мягче применяет изменения. Это снижает риск кратковременного даунтайма.

Если что-то пошло не так, можно посмотреть логи:

    journalctl -u caddy --no-pager -e

Автоматический HTTPS: почему это важно

Одна из причин популярности Caddy — это автоматическая работа с SSL.

Если домен правильно указывает на сервер, сертификат выдаётся автоматически через Let’s Encrypt. Это убирает привычную боль с certbot и ручным обновлением.

Иногда возникает вопрос: что если сертификат не обновится? В нормальной конфигурации Caddy сам следит за сроками и обновляет их заранее.

Это особенно удобно для VDS, где много мелких проектов и нет желания вручную сопровождать каждый домен.

Использование Caddy как reverse proxy

Caddy подходит не только для статики. Очень часто его используют как reverse proxy, как промежуточный сервер перед приложением.

Это стандартная схема для:

Django
Flask
FastAPI
Node.js
Go
Laravel
Docker-контейнеров

Как работает reverse proxy

Представьте такую схему:

    Интернет
   ↓
Caddy
   ↓
Django на localhost:8000

Пользователь обращается к Caddy.

Caddy:

принимает HTTPS
обрабатывает сертификаты
проксирует запросы в Django

А Django работает локально и наружу вообще не торчит.

Это намного безопаснее и удобнее.

Пример Caddyfile для Django

Допустим Django запущен через gunicorn:

    gunicorn --bind 127.0.0.1:8000 myproject.wsgi

Тогда Caddyfile будет таким:

    example.com {
    reverse_proxy 127.0.0.1:8000
}

Этого уже достаточно для рабочего HTTPS сайта.

А как быть со статикой Django?

Обычно Django сам плохо подходит для раздачи статики в production.

Поэтому делают так:

    Django → приложение
Caddy → статика + HTTPS + прокси

Пример:

    example.com {
    handle /static/* {
        root * /var/www/static
        file_server
    }
    reverse_proxy 127.0.0.1:8000
}

/static/ отдаёт сам Caddy
остальные запросы уходят в Django

Это быстрее и снижает нагрузку на Python.

Частые проблемы и их диагностика

Иногда сервер не стартует после настройки. Обычно причина простая: ошибка в Caddyfile.

Проверка конфигурации:

    caddy validate --config /etc/caddy/Caddyfile

Эта команда быстро показывает синтаксические ошибки. На практике она экономит много времени, особенно при сложных конфигурациях.

Ещё один частый момент — занят порт 80 или 443. Проверить можно так:

    sudo lsof -i :80
sudo lsof -i :443

Если порт занят, нужно понять, какой сервис конфликтует. Это типичная ситуация на VPS с предустановленным Nginx.

Управление сервисом через systemd

Caddy работает как systemd-сервис, поэтому управление стандартное.

Остановить:

    sudo systemctl stop caddy

Запустить:

    sudo systemctl start caddy

Добавить в автозагрузку:

    sudo systemctl enable caddy

Это важно для серверов, которые должны переживать перезагрузки без ручного вмешательства.

Заключение

В реальных проектах Caddy часто выбирают там, где важна скорость настройки и предсказуемость.

Он хорошо подходит для:

небольших SaaS проектов
тестовых стендов
API сервисов
статических сайтов
reverse proxy схем

Установка Caddy на Ubuntu занимает немного времени, но закрывает сразу несколько задач: веб-сервер, HTTPS и прокси.

Главная ценность в том, что система не требует постоянного обслуживания. Это особенно важно, когда на одном VDS крутится несколько проектов и нет желания возвращаться к каждому сертификату вручную.