Оба запускаются практически на любом VPS начального уровня, оба терминируют TLS, оба легко встают перед вашим Next.js-приложением или статическим сайтом. Вопрос никогда не стоит как «какой веб-сервер лучше». Вопрос - какой из них стоит вам меньше времени и боли именно в вашем конкретном сетапе self-hosting. Вот этот трейд-офф, честно разложенный для человека, который поднимает свой первый сервер, а не для платформенной команды.

Где Caddy выигрывает безоговорочно: автоматический HTTPS

Флагманская фича Caddy - не маркетинг, и именно она экономит больше всего времени соло-оператору. Когда Caddy знает домен, который обслуживает, он выпускает TLS-сертификат у публичного ACME CA - например Let’s Encrypt или ZeroSSL, - сам продлевает его и автоматически делает редирект HTTP на HTTPS: без дополнительной конфигурации и отдельных инструментов.[1] Документация Caddy называет его первым веб-сервером, где HTTPS автоматический и включён по умолчанию.[1]

Рабочий HTTPS-сайт в Caddy выглядит так:

example.com {
    reverse_proxy 127.0.0.1:3000
}

Укажите A/AAAA-запись example.com на сервер, откройте порты 80 и 443 - и Caddy сам сделает выпуск сертификата, продление и редирект HTTP на HTTPS.[1]

Nginx не хуже в TLS - он просто не автоматический. Жизненный цикл сертификата вы управляете сами, через Certbot. Путь certbot --nginx - это рукопожатие из двух шагов: Certbot получает сертификат, а затем изменяет ваш конфиг сервера Nginx, чтобы установить его и настроить автоматическое продление по расписанию.[2] Плагин nginx работает в большинстве конфигураций, автоматизирует и получение, и установку, и поддерживает откат с помощью certbot --nginx rollback, но он правит ваш конфиг, и документация рекомендует сделать бэкап перед запуском.[2]

Практическая разница: с Nginx + Certbot HTTPS - это повторяемый процесс, за которым иногда нужно приглядывать; с Caddy - это поведение по умолчанию. Для одного VPS, где вам просто нужна иконка замка и чтобы больше никогда об этом не думать, Caddy экономит и время первой настройки, и каждое будущее «почему у меня протух сертификат» в полночь. Nginx + cron для certbot renew делает то же самое, но рутина остаётся на вас.

Конфиг: Caddyfile против nginx.conf

Здесь видно различие в философии. Caddy использует Caddyfile - компактный декларативный формат, где адрес сайта идёт первым, за ним - директивы, а встроенные фичи делают счастливый путь коротким.[3] Nginx использует блоки директив в nginx.conf и конфигах сайтов, где почти всё - включая разумные заголовки и настройки TLS - вы включаете сами.

Один и тот же reverse proxy на каждом из них:

# Caddyfile
api.example.com {
    reverse_proxy /api/* 127.0.0.1:8000
    file_server
}

# nginx.conf (site block)
server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        proxy_pass http://127.0.0.1:8000;
        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;
    }
}

Caddyfile даёт вам HTTPS бесплатно, поэтому вы пишете прокси и идёте дальше. В Nginx-блоке проброс заголовков нужно добавлять руками - привычка, которая имеет значение, потому что без X-Forwarded-Proto приложение за TLS с радостью строит http://-редиректы. Если вам уже комфортно писать server-блоки Nginx (а полный укреплённый конфиг мы отдельно разобрали в гайде Nginx reverse proxy config), ничего из этого не сложно - просто больше набора текста на каждый сайт.

У краткости Caddy есть и реальная цена: Caddyfile - это отдельная, со своей философией абстракция. Если нужно поведение, которое в неё не ложится чисто, вы опускаетесь ниже уровня Caddyfile и работаете с JSON-конфигом - переключение контекста, которого в Nginx почти не бывает, потому что конфиг и есть «тот самый конфиг».

Производительность: будем честны

Коротко: на нагруженной машине Nginx, как правило, быстрее на чистой раздаче статики и на простом reverse-proxy, и обычно использует меньше памяти при этом. Это консенсус сообщества и инженерная практика, и не просто так: Nginx - C-программа, заточенная под высокую конкурентность, за два десятилетия закалки, тогда как Caddy - Go-бинарник с другими трейд-оффами в пользу расширяемости и безопасности.

Мы сознательно не приводим тут цифры бенчмарков. Мы не замеряли Caddy против Nginx на своих арендованных аккаунтах, и по нашему стандарту источников не публикуем цифры, которые не можем подкрепить реальным замером. Относитесь с подозрением к любому конкретному числу вроде «X запросов/с у Caddy против Y у Nginx» из блог-поста, если автор не показывает методику теста. По опыту и на практике на нагруженном VPS Nginx выигрывает гонку пропускной способности; для side project, справляющегося с парой сотен запросов в секунду, это не имеет значения.

Зато Caddy даёт конкретные операционные плюсы, которые не про скорость: он поставляется как статически скомпилированный бинарник без зависимостей от runtime-библиотек - документация Caddy отмечает, что ему в целом не нужен даже libc, - а написанный на Go, он не подвержен классу C-ошибок безопасности памяти, которые исторически били Nginx и другие C-серверы.[4] Это реальный аргумент, а не маркетинг: меньше движущихся частей и безопасные по умолчанию дефолты чего-то стоят на сервере, которым вы управляете в одиночку.

Фичи, которые реально всплывают в self-hosting

Rate limiting. В Nginx он встроен через ngx_http_limit_req_module - ограничитель по схеме «leaky bucket», ключуемый по чему угодно, обычно по IP клиента, с shared-memory зонами и контролем burst/nodelay.[5]

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
    }
}

У Caddy, что важно, нет rate limiting в базовом бинарнике. Есть зарегистрированный модуль rate_limit (http.handlers.rate_limit, из комьюнити-проекта), но он явно не входит в Caddy из коробки - его нужно собрать через xcaddy или выбрать на странице загрузки.[6] Так что боль, которая в Nginx решается одной директивой, в Caddy требует пересборки. Если вам реально нужно защищаться от злоупотреблений - это веский аргумент в пользу Nginx.

Балансировка нагрузки и health checks. Оба умеют несколько апстримов. Nginx группирует серверы в блоке upstream со взвешенным round-robin по умолчанию, per-server max_fails / fail_timeout для пометки мёртвого пира и backup-серверами для фейловера.[7]

upstream backend {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

reverse_proxy в Caddy делает то же самое с несколькими апстримами, плюс явные health checks через health_uri и health-заголовки.[8]

example.com {
    reverse_proxy node1:80 node2:80 {
        health_uri /health
        fail_duration 30s
        max_fails 3
    }
}

Одно честное уточнение про Nginx здесь: настоящие активные периодические health checks (директива health_check) - это часть коммерческой подписки, а не open-source сборки.[9] Open-source Nginx даёт пассивный фейловер - пометить пир мёртвым только когда запросы к нему начали падать. Для single-VPS self-hosting редко нужно больше.

WebSockets и SSE. Оба их нормально проксируют. Nginx требует явных HTTP/1.1 + Upgrade-заголовков и настройки proxy_read_timeout, чтобы простывшие сокеты не умирали; Caddy делает апгрейд нативно и почти без церемоний. В Caddy это ощущается бесплатным; в Nginx вы один раз пишете upgrade-блок и больше к нему не возвращаетесь.

Экосистема и расширяемость

Суперсила Nginx - его плагинный мир, особенно OpenResty / Lua-скриптинг, который позволяет делать сложные манипуляции с запросами, не выходя из сервера. Если ваше хобби перерастёт во что-то с нетривиальной логикой на запрос (auth, кэширование, shaping трафика), экосистема Nginx на десятилетия вглубь и проверена боем. Цена - теперь вы держите C-сервер, возможно, с кастомной сборкой.

Расширяемость Caddy на бумаге чище - это Go, и плагины это Go-модули, которые вы компилируете на этапе сборки, поэтому всё это один статический бинарник.[4] Для большинства селф-хостеров это значит меньше зависимостей, чем полный стек Nginx + Lua, легче апгрейд («заменил бинарник») и меньше поверхность атаки. Caddy в Docker работает так же, как Nginx, оба полноценно представлены в репозиториях дистрибутивов - тут ничья.

Так когда что выбирать?

Выбирайте Caddy, когда: это side project или несколько личных сервисов на одном VPS; вам нужно, чтобы TLS просто работал; вы отдаёте что-то с одним апстримом и не нужна хитрая логика по location-ам; вы цените один бинарник и безопасные по умолчанию дефолты; или вам проще провести вечер за написанием приложения, чем за конфигом сервера.

Выбирайте Nginx, когда: вы уже встроены в Nginx-стек или знаете его наизусть; вы гонитесь за максимальной пропускной способностью статики/RPS на нагруженной машине; вам нужен встроенный rate limiting; вы планируете нетривиальную логику запросов (OpenResty / Lua); или вы тянете несколько сервисов и у вас уже есть подход с шаблонами сайтов.

Есть и прагматичный ответ посередине, к которому приходит много селф-хостеров: Nginx фронтует всё (потому что он быстрый и вы его знаете), а сертификат на автоматическом продлении через Certbot рулит - либо Caddy, если вы правда не хотите больше думать о сертификатах. Оба варианта абсолютно разумны. Неразумно делать вид, что один из них универсально лучше.

Источники

  1. Caddy - Automatic HTTPS (HTTPS по умолчанию, ACME-выпуск, автопродление, редирект HTTP на HTTPS). https://caddyserver.com/docs/automatic-https - checked 2026-10-17
  2. Certbot - User Guide, использование плагинов (плагин nginx получает и устанавливает, правит конфиг сервера, rollback). https://eff-certbot.readthedocs.io/en/stable/using.html - checked 2026-10-17
  3. Caddy - Caddyfile quick-start (декларативный формат, адрес сайта первым). https://caddyserver.com/docs/quick-starts/caddyfile - checked 2026-10-17
  4. Caddy - Features (статический бинарник, без libc, написан на Go, безопасность памяти). https://caddyserver.com/features - checked 2026-10-17
  5. nginx - Module ngx_http_limit_req_module (rate limiting через схему leaky bucket). https://nginx.org/en/docs/http/ngx_http_limit_req_module.html - checked 2026-10-17
  6. Caddy - Module http.handlers.rate_limit (не входит в Caddy по умолчанию, ставится через xcaddy). https://caddyserver.com/docs/modules/http.handlers.rate_limit - checked 2026-10-17
  7. nginx - Module ngx_http_upstream_module (взвешенный round-robin, max_fails, fail_timeout, backup). https://nginx.org/en/docs/http/ngx_http_upstream_module.html - checked 2026-10-17
  8. Caddy - директива reverse_proxy (несколько апстримов, health check через health_uri). https://caddyserver.com/docs/caddyfile/directives/reverse_proxy - checked 2026-10-17
  9. nginx - Module ngx_http_upstream_hc_module (активный health_check - часть коммерческой подписки). https://nginx.org/en/docs/http/ngx_http_upstream_hc_module.html - checked 2026-10-17