Caddy в проде: авто‑TLS, reverse proxy и JSON‑логи

Если вы привыкли к связке «Nginx + Certbot + logrotate», Caddy может показаться чем-то «слишком удобным, чтобы быть правдой». Автоматический TLS без кронов и хендмейд‑скриптов, нативный reverse proxy, HTTP/2/3 из коробки, структурированные JSON‑логи — и всё это в одном бинарнике. В этом обзоре я покажу, как использовать Caddy в проде: от базовой схемы до тонкостей логирования, безопасности и перформанса.

Архитектура и ключевые преимущества

Caddy — это модульный веб‑сервер на Go с декларативной конфигурацией. Он может работать как самостоятельный сервер статических файлов, как обратный прокси перед приложениями (PHP‑FPM, Node.js, Python, Go), и как TLS‑терминатор перед любым backend, говорящим по HTTP/1.1, h2c и gRPC.

• Auto‑TLS: автоматическая выдача и продление сертификатов через ACME, с вшитой логикой валидации и хранения.
• Zero‑downtime reload: конфиг можно изменять и применять без разрывов соединений.
• HTTP/2 и HTTP/3/QUIC: современный стек транспорта без дополнительной сборки.
• JSON‑логи: структурированное логирование, готовое к парсингу.
• Единый конфиг: меньше скриптов вокруг, меньше точек отказа.

Главная ценность Caddy — минимизация операционной рутины вокруг TLS и проксирования при сохранении предсказуемости и безопасных дефолтов.

Auto‑TLS: как это работает в реальности

Автоматический HTTPS включается по умолчанию, если вы указываете доменное имя в серверном блоке. Caddy сам пройдёт ACME‑валидацию (обычно по HTTP‑01 или TLS‑ALPN‑01), получит сертификат, поставит OCSP stapling и будет продлять сертификат заранее. Для вас это означает — никакого ручного Certbot и cron. Убедитесь, что ваш домен корректно настроен через регистрацию доменов и указывает на сервер.

Практические моменты:

• Откройте порт 80 для HTTP‑01 (если не используете альтернативы) и порт 443 для TLS‑ALPN‑01 и HTTPS‑трафика.
• Сертификаты и метаданные Caddy хранит на диске; имеет смысл бэкапить это хранилище для быстрого восстановления.
• Контактный email задайте глобально — так вы получите уведомления эмитента.

{
  email admin@example.com
}

example.com {
  encode zstd gzip
  reverse_proxy 127.0.0.1:8080
}

Этого достаточно, чтобы поднять HTTPS с автоматическим продлением. При необходимости можно использовать собственные сертификаты, включая корпоративные, оформив их как обычные SSL‑сертификаты и подключив в блоке tls.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Reverse proxy: от минимума к продакшен‑профилю

Базовый reverse proxy выглядит предельно просто и уже включает корректные заголовки X-Forwarded-* по умолчанию:

example.com {
  reverse_proxy 127.0.0.1:8080
}

В проде понадобятся таймауты, балансировка, health‑checks и доверенные прокси (если у вас есть CDN/балансировщики перед Caddy):

example.com {
  encode zstd gzip

  @static {
    path *.css *.js *.png *.jpg *.svg *.webp
  }
  header @static Cache-Control "public, max-age=31536000, immutable"

  reverse_proxy {
    to 10.0.0.10:8080 10.0.0.11:8080
    lb_policy least_conn
    lb_try_duration 10s
    lb_try_interval 250ms
    health_checks {
      active {
        path /healthz
        interval 10s
        timeout 2s
      }
    }
    transport http {
      versions h2c 1.1
      read_timeout 30s
      write_timeout 30s
      keepalive 30s
    }
    trusted_proxies private_ranges
  }
}

• WebSocket и HTTP/2 к бэкенду поддерживаются «из коробки».
• Старайтесь отдавать статику напрямую из Caddy, ставьте долговечные кеш‑заголовки через header.
• Если используете внешние балансировщики/CDN, настройте trusted_proxies, чтобы корректно извлекать реальный IP.

JSON‑логи: структурировано и готово к парсингу

Одна из сильных сторон Caddy — логирование запросов в JSON. Это позволяет без грубых парсеров класть логи в любую систему: от ротации на диск до потоковой доставки в аналитический контур. Включить просто:

example.com {
  log {
    output file /var/log/caddy/access.json {
      roll_size 50MiB
      roll_keep 14
      roll_keep_for 336h
    }
    format json
    level info
  }

  reverse_proxy 127.0.0.1:8080
}

Пример реальной строки (сокращено):

{
  "level": "info",
  "ts": 1732101800.123,
  "logger": "http.log.access.log0",
  "msg": "handled request",
  "request": {
    "remote_addr": "203.0.113.10:54321",
    "proto": "HTTP/2.0",
    "method": "GET",
    "host": "example.com",
    "uri": "/"
  },
  "status": 200,
  "size": 1234,
  "duration": 0.004,
  "resp_headers": {
    "Content-Type": ["text/html; charset=utf-8"],
    "Server": ["Caddy"]
  }
}

Ротацию можно поручить системным средствам, но встроенные параметры roll_size/roll_keep работают предсказуемо. Если вы используете systemd, удобно писать в stderr и забирать логи из journald:

example.com {
  log {
    output stderr
    format json
    level info
  }
  reverse_proxy 127.0.0.1:8080
}

Для отладки доступны команды форматирования и валидации:

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

Безопасность по умолчанию и ручные донастройки

Редирект HTTP→HTTPS включён автоматически. Но некоторые вещи лучше зафиксировать явно: HSTS (после стабилизации домена), современные версии TLS и кривые, минимизация утечек служебных данных.

example.com {
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "SAMEORIGIN"
    Referrer-Policy "no-referrer-when-downgrade"
  }
  tls {
    issuer acme {
      email admin@example.com
    }
    protocols tls1.2 tls1.3
    curves x25519 p256
  }
  respond /healthz 200
  reverse_proxy 127.0.0.1:8080
}

Если нужны wildcard‑сертификаты или нестандартные валидации, используйте DNS‑плагины Caddy и заранее продумайте CI/CD для ключевого хранилища. Для части доменов можно оставить автоматическую выдачу, а для критичных — подключить заранее купленные SSL‑сертификаты.

Производительность: что влияет и как мерить

• Сжатие и кеширование: encode zstd gzip и долгие кеш‑заголовки для статики снижают трафик и нагрузку.
• Балансировка и health‑checks: исключают деградировавшие инстансы и уменьшают латентность.
• Таймауты транспорта: отсоединяют «подвисшие» бэкенды от общей доступности.
• HTTP/3: особенно полезен на высоколатентных или нестабильных сетях.

Не забывайте про телеметрию: счётчики по коду ответа, латентности, размерам ответов и распределению статусов. С JSON‑логами несложно считать p50/p90/p99 в любой аналитике. Для серверов на ARM есть практические замеры — посмотрите сравнение в материале «ARM VDS: производительность PHP/Node» по теме производительности ARM‑VDS. Если нужен изолированный сервер для Caddy и приложений — рассмотрите VDS.

HTTP/2 и HTTP/3 без боли

HTTP/2 в Caddy включён по умолчанию на TLS. HTTP/3 также доступен из коробки — откройте UDP:443 на фаерволе. Совместимость с бэкендами обеспечивается «понижением» до HTTP/1.1 или h2c на аплинке — на уровне клиента трафик останется максимально современным.

Миграция с Nginx: основные соответствия

Большинство типовых конфигов мигрируются быстро. Ориентиры: try_files выражается через rewrite/handle, заголовки управляются через header, а reverse_proxy покрывает сценарии proxy_pass с балансировкой и health‑чеками. Для PHP‑приложений используйте php_fastcgi:

example.com {
  root * /var/www/site/public
  encode zstd gzip

  @assets path *.css *.js *.png *.jpg *.webp
  handle @assets {
    file_server
  }

  handle {
    rewrite * /index.php?{query}
    php_fastcgi 127.0.0.1:9000
  }
}

Совет: используйте caddy adapt, чтобы увидеть итоговую JSON‑конфигурацию. Это помогает убедиться, что интерпретация Caddyfile совпала с ожиданиями. Если вы держите воркеры/очереди рядом с приложением — пригодится разбор сервисов и юнитов в статье про Supervisor и systemd для воркеров.

Управление и эксплуатация

Базовые действия с systemd:

sudo systemctl enable --now caddy
sudo systemctl status caddy
sudo journalctl -u caddy -f

Быстрая проверка:

caddy version
curl -I https://example.com

Частые изменения конфигурации сопровождайте проверкой формата и валидации. В больших инсталляциях держите Caddyfile в репозитории и раскатывайте как конфиг‑ресурс через оркестрацию.

Типичные грабли и как их обходить

• Нет доступа к 80/443 снаружи: авто‑TLS выключится. Проверьте фаервол и NAT.
• Сломанные заголовки реального клиента: убедитесь, что upstream доверяет X-Forwarded-For и корректно обрабатывает Host.
• Слишком подробные логи: на высокой нагрузке балансируйте уровень логирования и ротацию, агрегируйте поля.
• Долгая цепочка промежуточных прокси: настройте trusted_proxies, если используете CDN/балансировщики, чтобы корректно определять реальный IP.

Итоги: где Caddy особенно уместен

Сценарии, где Caddy раскрывается максимально: быстрый старт и унификация TLS для многих доменов, микросервисные стенды с частыми изменениями, JSON‑логи «из коробки», modern‑web требования (HTTP/2/3) без лишних телодвижений. Для продакшена это означает меньше обвязки, меньше ручных обновлений сертификатов и больше предсказуемости при изменениях. Если нужен изолированный сервер под фронт‑прокси и приложения — удобно стартовать на VDS.