У каждого разработчика есть своя история про сертификаты. Про то, как час ушёл на установку Certbot, ещё полчаса на правку конфига Nginx, потом выяснилось, что порт 80 закрыт файрволом, потом сертификат получился, но браузер всё равно ругается на редирект. А потом через три месяца сертификат просто тихо истёк, потому что cron-задача где-то не запустилась. Знакомо? Именно эту боль и пришёл лечить Caddy.
Caddy - это веб-сервер нового поколения, написанный на Go и выпущенный в 2015 году. Его создатели поставили перед собой нестандартную цель: сделать так, чтобы HTTPS работал из коробки, без каких-либо дополнительных действий со стороны администратора. Не "легко настроить", а именно "работает сам". Сегодня, в 2025 году, Caddy стал полноценной альтернативой Nginx и Apache для широкого круга задач и стремительно набирает популярность в Docker-средах, домашних лабораториях и небольших продакшн-проектах.
Как Caddy получает и продлевает сертификаты без единой дополнительной команды
Главная магия Caddy состоит в том, что автоматический HTTPS встроен в самое ядро сервера, а не прикручен снаружи. Достаточно указать в конфигурации доменное имя - и Caddy сам свяжется с Let's Encrypt или ZeroSSL через протокол ACME, пройдёт HTTP-01 или TLS-ALPN-01 challenge, получит сертификат, сохранит его, настроит редирект с HTTP на HTTPS и поставит напоминание о продлении. Всё это без cron, без Certbot, без дополнительных скриптов.
Для публичных доменов используются доверенные сертификаты от публичных центров сертификации. Для локальных хостов и IP-адресов Caddy поднимает собственный внутренний центр сертификации и выдаёт самоподписанные сертификаты, которые автоматически добавляются в доверенное хранилище операционной системы. Это означает, что даже разработка на localhost идёт по HTTPS без предупреждений браузера.
Caddy был первым веб-сервером, реализовавшим автоматический HTTPS по умолчанию - ещё с момента первого релиза в 2015 году. Сегодня его TLS-настройки по умолчанию соответствуют требованиям PCI, HIPAA и NIST без какой-либо дополнительной конфигурации.
Установка на Ubuntu или Debian занимает три команды и меньше минуты
Caddy распространяется через официальный репозиторий и устанавливается стандартными средствами пакетного менеджера. На Ubuntu или Debian это выглядит так:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
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 && sudo apt install caddy
После установки Caddy автоматически регистрируется как systemd-сервис и запускается при старте системы. Проверить статус можно командой systemctl status caddy. Конфигурационный файл лежит в /etc/caddy/Caddyfile, туда и нужно вносить все настройки.
Для тех, кто работает с Docker, официальный образ ещё проще. В docker-compose.yml достаточно смонтировать Caddyfile и два тома для хранения сертификатов:
services:
caddy:
image: caddy:2
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
Порт 443/udp открывает поддержку HTTP/3 через протокол QUIC - Caddy поддерживает его из коробки, что у Nginx требует дополнительной компиляции с нестандартными модулями.
Caddyfile читается как обычный текст и не требует знания специального синтаксиса
Здесь Caddy выигрывает у конкурентов особенно наглядно. Посмотрим на конкретное сравнение. Задача: поднять обратный прокси для приложения на порту 3000, с HTTPS и правильными заголовками.
Конфиг Nginx для этой задачи:
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Это около 20 строк, и это ещё до настройки самого Certbot. Эквивалентный Caddyfile:
example.com {
reverse_proxy localhost:3000
}
Три строки. HTTPS получается и продлевается автоматически. Все нужные заголовки (X-Forwarded-For, X-Forwarded-Proto и другие) Caddy проставляет сам, без явного указания.
Для статического сайта конфигурация выглядит так:
example.com {
root * /var/www/html
file_server
}
Если нужно объединить статику и прокси к API в одном блоке:
example.com {
root * /var/www/html
file_server
reverse_proxy /api/* localhost:8080
encode gzip
}
Директива encode gzip включает сжатие ответов - в Nginx это потребовало бы отдельного блока gzip on с несколькими параметрами.
Несколько сервисов за одним Caddy настраиваются добавлением блоков в один файл
Это сценарий, с которым сталкиваются практически все, кто ведёт домашний сервер или небольшую инфраструктуру. Несколько Docker-контейнеров, каждый на своём порту, и нужно раздать их по разным поддоменам с HTTPS. В Nginx это превращается в несколько файлов с повторяющимися блоками ssl_certificate. В Caddyfile это выглядит читаемо и предельно компактно:
grafana.example.com {
reverse_proxy localhost:3000
}
nextcloud.example.com {
reverse_proxy localhost:8080
}
api.example.com {
reverse_proxy localhost:5000
header {
Access-Control-Allow-Origin *
}
}
Каждый поддомен получит свой сертификат автоматически. Caddy параллельно запросит все три у Let's Encrypt при первом запуске. При добавлении нового блока достаточно выполнить caddy reload - без перезапуска сервера и без прерывания текущих соединений.
Для перезагрузки конфигурации без downtime используется:
sudo systemctl reload caddy
# или, если запущен вручную:
caddy reload --config /etc/caddy/Caddyfile
Практические ограничения Caddy и когда стоит выбрать Nginx
Честный разговор о Caddy невозможен без признания его слабых мест. Caddy не умеет автоматически обнаруживать Docker-контейнеры: маршруты нужно прописывать вручную в Caddyfile. Traefik в этом плане удобнее для динамичных сред, где контейнеры постоянно появляются и исчезают.
Тонкая настройка поведения прокси - тайм-ауты, буферизация, rate limiting на уровне отдельных IP - в Caddy возможна, но Nginx даёт здесь значительно больше контроля и лучше документированные опции. Для высоконагруженных продакшн-систем с нестандартными требованиями Nginx остаётся более предсказуемым выбором.
В отличие от первой версии, где авторы экспериментировали с коммерческими лицензиями, современный Caddy 2 полностью бесплатен (Apache 2.0). Все функции доступны из коробки без ограничений для коммерческого использования, а монетизируется проект исключительно за счёт платной техподдержки и спонсорства.
Отдельная история с wildcard-сертификатами вида *.example.com. Их получение требует DNS-01 challenge, что означает интеграцию с DNS-провайдером через API. Caddy поддерживает это через плагины для популярных провайдеров (Cloudflare, DigitalOcean и другие), но установка плагинов требует сборки кастомного бинарника через инструмент xcaddy. Это уже заметно сложнее стандартной установки.
Caddy меняет то, каким должен быть порог входа в безопасный веб-сервер
Если отступить на шаг и посмотреть на картину шире, Caddy делает с веб-серверами то же самое, что Let's Encrypt в своё время сделал с SSL-сертификатами: убирает оправдание "это слишком сложно". Раньше сертификат стоил денег - теперь нет. Теперь настройка HTTPS требовала нескольких инструментов - теперь нет.
Среднестатистический разработчик, впервые запускающий Caddy, проходит путь от нуля до работающего HTTPS-сервера примерно за две минуты. Это не преувеличение - именно столько занимает установка плюс создание трёхстрочного Caddyfile. Для сравнения: правильная настройка Nginx с Certbot, с учётом всех best practices, у того же разработчика займёт от получаса до нескольких часов.
Разумеется, Nginx никуда не уйдёт. Двадцать лет разработки, огромная экосистема и тонкая настройка любого аспекта поведения - это весомые аргументы для серьёзных нагрузок. Но для задач, где важна скорость запуска, читаемость конфигурации и отсутствие головной боли с сертификатами, Caddy стал ответом на вопрос, который многие разработчики задавали годами: почему всё это должно быть так сложно?