Caddy с авто-SSL на сервере: частые ошибки и решения

MAATRIX

Caddy подкупает тем, что HTTPS у него работает из коробки. Но именно вокруг авто-SSL и возникают почти все проблемы: сертификат не выпускается, домен отдаёт предупреждение безопасности, а в логах непонятные сообщения ACME. Разберём частые ошибки Caddy с авто-SSL на сервере по схеме «симптом — причина — решение», чтобы вы починили за минуты, а не за вечер.

Как правильно читать логи Caddy

Прежде чем чинить, научитесь смотреть, что именно говорит сервер. Caddy подробно логирует весь процесс выпуска сертификата, и ответ на большинство вопросов уже там. Логи идут в journald:

journalctl -u caddy -f

Отдельно полезно проверить, что конфиг вообще валиден. У Caddy есть встроенная проверка и автоформатирование Caddyfile:

caddy validate --config /etc/caddy/Caddyfile
caddy fmt --overwrite /etc/caddy/Caddyfile

Если после правки конфига сервер не перечитал его, изменения не применятся — это банальная, но частая причина «ничего не поменялось». Всегда завершайте правку перезагрузкой и убеждайтесь, что она прошла без ошибки:

systemctl reload caddy && systemctl status caddy

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

Сертификат не выпускается: закрытые порты

Самый частый сбой авто-SSL. В логах — сообщения о неудачной попытке ACME-проверки, а сайт открывается только по HTTP или отдаёт ошибку сертификата. В подавляющем большинстве случаев виноват закрытый порт.

Caddy проходит проверку домена по портам 80 и 443, и оба должны быть доступны из интернета. Проверьте фаервол и при необходимости откройте порты:

ufw status
ufw allow 80/tcp
ufw allow 443/tcp

Порт 80 нужен даже если весь сайт работает по HTTPS: через него идёт HTTP-проверка ACME и редирект. Частая ловушка — облачный фаервол провайдера поверх системного: локально ufw всё разрешает, а внешний фильтр режет 80. Проверьте доступность порта снаружи, а не только с самого сервера. Ещё одна причина — другой процесс уже занял порт: если на 80 висит старый Nginx или Apache, Caddy не сможет его слушать, и это видно по ss -tlnp | grep ':80'.

Домен не указывает на сервер

Второй по частоте случай: порты открыты, но сертификат всё равно не выпускается, а в логах — ошибка проверки домена. Let's Encrypt должен убедиться, что домен принадлежит вам, обратившись к нему по имени. Если A-запись указывает на старый или чужой IP, проверка провалится.

Убедитесь, что домен резолвится именно на этот сервер:

dig +short example.com
curl -I http://example.com

Первая команда должна вернуть публичный IP вашего VPS. Если запись недавно меняли, учтите задержку распространения DNS — иногда до нескольких часов. Отдельная тонкость с CDN: если домен проксируется через Cloudflare в оранжевом облаке, ACME-проверка по HTTP может не дойти до вашего сервера. На время выпуска либо переведите запись в серый режим (только DNS), либо используйте выпуск через DNS-провайдера.

Упёрлись в лимиты Let's Encrypt

Симптом коварный: сначала всё работало, а после нескольких перезапусков или переустановок сертификат перестал выпускаться, в логах — сообщение про rate limit. Let's Encrypt ограничивает число выпусков на домен за неделю, и при отладке в этот лимит легко упереться, многократно пересоздавая сервер.

Правильный способ отлаживать авто-SSL — не бить по боевому центру сертификации, а использовать тестовый (staging). Он выдаёт недоверенные сертификаты, но с куда более щедрыми лимитами. В Caddyfile это задаётся глобально:

{
    acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

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

Редирект-цикл и ошибка за CDN

Иногда после подключения Caddy за внешним прокси или CDN страница уходит в бесконечное перенаправление, браузер пишет «слишком много редиректов». Причина та же, что у любого веб-сервера за прокси: рассогласование протокола. Внешний CDN общается с посетителем по HTTPS, а с Caddy — по HTTP, но при этом требует HTTPS, и возникает петля.

Если Caddy стоит за другим прокси, который уже терминирует TLS, отключите у Caddy собственный выпуск и работу по HTTPS для этого сайта, слушая обычный HTTP:

http://app.example.com {
    reverse_proxy 127.0.0.1:3000
}

Либо, наоборот, настройте на CDN сквозной режим (Full), чтобы шифрование шло до самого Caddy и он честно отдавал свой сертификат. Смешанный режим, где одна половина цепочки по HTTP, а другая по HTTPS, как раз и рождает циклы. Выберите одну согласованную схему и придерживайтесь её.

Ошибки прав доступа и хранилища сертификатов

Реже, но встречается: Caddy запущен, порты открыты, домен корректен, а сертификат не сохраняется, и при каждом перезапуске выпускается заново — прямой путь к лимиту. Причина в правах на каталог данных. Сервис Caddy работает под пользователем caddy, и если каталог /var/lib/caddy принадлежит другому пользователю или недоступен на запись, сертификаты некуда сложить.

Проверьте владельца и права каталога данных:

ls -la /var/lib/caddy
chown -R caddy:caddy /var/lib/caddy

Похожая проблема возникает, когда Caddy запускают то от root вручную, то через systemd от пользователя caddy — они используют разные домашние каталоги и разные хранилища, и сертификаты «теряются» между запусками. Договоритесь об одном способе запуска (правильный — через systemd) и одном хранилище. Тогда однажды выпущенный сертификат переживает перезапуски и продлевается автоматически.

Профилактика и когда дело не в Caddy

Большинство ошибок авто-SSL уходят навсегда, если соблюсти три условия с самого начала: домен заранее указывает на сервер, порты 80 и 443 открыты и снаружи, и запуск идёт только через systemd под одним пользователем. Отладку всегда ведите на тестовом центре сертификации, чтобы не жечь лимиты.

Отдельно стоит помнить, что часть проблем не имеет отношения к самому Caddy. Если сервер перегружен, отвечает с задержками или у него нестабильная сеть, ACME-проверка может срываться по таймауту, а не по вине конфигурации. Чистый IP без чужой репутации тоже важен: адрес из «грязного» пула иногда получает лишние проверки. Если сомневаетесь в качестве площадки, надёжнее взять VPS с чистым IP и стабильной сетью — у MAATRIX это доступно в локациях RU, US и UK с оплатой из России картой или криптой. На адекватном сервере авто-SSL Caddy просто работает и не напоминает о себе месяцами.

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