Caddy против Nginx на VPS: сравнение файлов конфигурации

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    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;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Строки TLS в блоке Nginx предполагают, что Certbot уже отработал. Для HTTP-upstream вроде приведённого выше Caddy передаёт входящий Host заголовок дальше и устанавливает X-Forwarded-For, X-Forwarded-Proto, и X-Forwarded-Host по умолчанию. В Nginx вы обычно добавляете прокси-заголовки явно, когда upstream'у нужны исходный хост, схема и цепочка адресов клиента. Вот компромисс в миниатюре: Caddy поставляется с практичными настройками прокси по умолчанию, тогда как Nginx делает большую часть этого поведения явной.

Раздача статических файлов:

Caddyfile

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

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Базовая аутентификация, защищающая всё за именем пользователя и паролем:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    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;
    }
}

Оба инструмента хешируют пароль отдельно. Caddy использует caddy hash-password; Nginx использует htpasswd для создания файла .htpasswd. Директива — basic_auth в текущем Caddy, кстати. Она называлась basicauth , пока в v2.8.0 её не переименовали, как отмечено в документации Caddy по basic_auth, , и старые руководства до сих пор на этом спотыкают людей.

Совет: Этот хеш в Caddyfile — не пароль. Это результат bcrypt из caddy hash-password. Запустите команду, вставьте то, что она выведет. Caddy отказывается принимать пароли открытым текстом в конфигурации, что является правильной настройкой по умолчанию и небольшим сюрпризом в первый раз.

Конфигурации говорят сами за себя. Caddy сворачивает TLS, разумные прокси-заголовки и перенаправление в несколько строк; Nginx явен и многословен и даёт вам каждую ручку управления. Если вы годами работали в Nginx, эта многословность — мышечная память, а контроль — в этом весь смысл. Если нет, Caddyfile — это конфигурация, которую вы можете держать в голове. Практический вывод прост: конфигурацию Caddy легче читать с одного взгляда, тогда как Nginx даёт вам больше явного контроля.

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

Опубликованные тесты указывают в одном общем направлении: Nginx обычно использует меньше памяти и часто лидирует по чистой пропускной способности, но размер этого преимущества сильно зависит от среды.

In одном стороннем тесте на четырёхъядерной ВМ, Nginx достиг примерно 48,000 запросов в секунду по сравнению с около 42,000 у Caddy. Тот же тест сообщил о задержке p99 для HTTPS в 2.1 ms у Nginx и 2.4 ms у Caddy. Воспринимайте это как результаты одной конфигурации, а не универсальный запас производительности.

Диапазоны памяти в сравнительной таблице взяты из отдельного теста на VPS. Ещё один синтетический тест при 50,000 одновременных соединений сообщил о 145 MB для Nginx и 520 MB для Caddy, но в этом тесте использовались существенно иное оборудование и условия нагрузки. Его абсолютные цифры не следует напрямую сравнивать с приведёнными выше показателями VPS.

Надёжный вывод уже: Nginx, как правило, имеет меньшее потребление памяти и обычно лидирует при нагрузках с высокой пропускной способностью или высокой конкурентностью. Для обычного обратного прокси на VPS малого-среднего размера обоих обычно достаточно быстро, так что операционная простота часто оказывается более полезным решающим фактором.

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

Подвох с wildcard-сертификатом (Caddy не всегда zero-config)

Caddy может автоматизировать wildcard-сертификаты, но не своими стандартными проверками HTTP-01 или TLS-ALPN-01. Сертификат для *.example.com требует проверки DNS-01, которую Let's Encrypt требует для wildcard-сертификатов. Это означает плагин DNS-провайдера (встроенный в ваш бинарник Caddy через xcaddy) плюс API-токен для вашего DNS-хостинга, настроенные в блоке tls. Это не та история «набери одну строчку и уходи», которую рекламирует Caddy.

Это бьёт по пользователям домашних лабораторий, которые размещают множество сервисов под реальным доменом, которым владеют, например *.home.example.com, и полагают, что выпуск wildcard-сертификата так же автоматичен, как app.example.com. Для чисто внутренних имён вроде *.homelab.internal, относитесь к этому как к территории локального/внутреннего PKI, а не публичного wildcard-сертификата Let's Encrypt. Если точнее: Caddy прекрасно справляется с wildcard-сертификатами, просто не делает этого стандартными проверками, и настройка на ступень сложнее случая с одним доменом. Nginx здесь в той же лодке, поскольку требование DNS-01 исходит от Let's Encrypt, а не от сервера.

Если вам нужен GUI: Nginx Proxy Manager (короткое отступление)

Nginx Proxy Manager — это совсем другое животное, чем два инструмента выше, и он заслуживает одного абзаца, потому что название сбивает людей с толку. NPM — это GUI-обёртка над Nginx: он управляет правилами обратного прокси и сертификатами Let's Encrypt через веб-интерфейс на port 81. Это не ядро Nginx, и настраивается он не так, как ядро Nginx.

Компромисс здесь обычный — «клик против конфигурации». NPM — это простая кнопка, пока вы не сойдёте с проторённой дорожки. Его конфигурация управляется через базу данных приложения, а не через единственный редактируемый вручную файл конфигурации. Стандартная установка через Docker использует SQLite, тогда как MySQL/MariaDB и PostgreSQL поддерживаются как варианты внешних баз данных. Эта разница также влияет на переносимость: конфигурацию Caddy часто можно перенести, скопировав единственный Caddyfile, тогда как развёртывание Nginx Proxy Manager требует, чтобы его данные приложения и база данных были сохранены. NPM — хороший выбор, если вы искренне предпочитаете клики редактированию и ваша конфигурация остаётся простой. Это неправильный выбор для рабочего процесса «инфраструктура как код».

Миграция с Nginx на Caddy (что переносится, а что нет)

Если вы уже на Nginx и взвешиваете переход, начните с того, что снизьте свои ожидания по части автоматизации: у Caddy есть адаптер конфигурации NGINX, но он неполный, и его не следует рассматривать как надёжный путь миграции в один заход. Миграция с Nginx на Caddy — это в основном ручное переписывание, и большая её часть становится короче.

Что переносится и упрощается, согласно руководству по конвертации от сообщества Caddy:

• Для HTTP-upstream'ов reverse_proxy передаёт входящий Host заголовок дальше и устанавливает стандартные заголовки X-Forwarded-* по умолчанию, так что большая часть этих proxy_set_header строк исчезает.
• PHP сворачивается из блока location с try_files плюс fastcgi_pass плюс кучей параметров в единственную php_fastcgi директиву.
• Обработка WebSocket в Caddy v2 автоматическая. Если руководство советует вам добавить отдельную websocket директиву, это пережиток Caddy v1. Игнорируйте его.

Что не переносится автоматически: всё, что завязано на конкретный модуль Nginx, которого у Caddy нет, сложная логика rewrite и location, которую придётся переосмыслить, а не перенести, и настройки wildcard-сертификатов, которые возвращают вас к настройке DNS-проверки из раздела выше. Заложите время на модули и переписывания; остальное обычно даёт чистое сокращение числа строк.

Какой из них устанавливать? (Решение)

Вы видели конфигурации, цифры, подвох с wildcard-сертификатами и стоимость миграции, так что вот к чему всё сводится. Устанавливайте Caddy, если вы разработчик-одиночка или небольшая команда, это свежее развёртывание на VPS, вам нужен TLS по принципу «настроил и забыл», вы запускаете Docker с простой маршрутизацией или вам просто нужна конфигурация, которая укладывается в мышечную память. Это большинство читающих это.

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

На чём бы вы ни остановились, следующий шаг — установить его на машину. Оба Caddy и Nginx доступны как развёртывания в один клик в нашем маркетплейсе, так что вы можете пропустить работу по установке и перейти сразу к Caddyfile или блоку сервера. VPS на 1 GB — разумная отправная точка для развёртывания одного сайта с невысоким трафиком, но подбирайте размер сервера под приложение и трафик за прокси, а не под один лишь прокси. Если вы используете Caddy как парадную дверь для самостоятельно размещаемых сервисов, он может стоять перед стеком мониторинга Prometheus и Grafana или развёртыванием Uptime Kuma без необходимости в отдельном инструментарии TLS.

Вывод раздела: выбирайте Caddy, если только у вас нет конкретной причины, указывающей на Nginx.

Часто задаваемые вопросы