Холивар про nginx и Caddy не утихает с 2018 года, но к 2026-му ситуация изменилась: Caddy стабилизировался, у nginx появились новые модули, оба обзавелись HTTP/3. Я держу в проде и тот, и другой — поэтому могу сравнить не по официальным маркетинговым страницам, а по тому, как они себя ведут под нагрузкой и в эксплуатации.

Версии

  • nginx 1.27.3 (mainline), собран с --with-http_v3_module --with-http_v2_module --with-stream
  • Caddy 2.8.4, бинарь стандартный с caddyserver.com

Тестовая нода — AX41 от Hetzner (Ryzen 5 3600, 64 GB, NVMe), Debian 12, kernel 6.6.

TLS-конфиг: где Caddy реально красавчик

Базовый сайт на Caddy:

example.com {
    root * /var/www/example
    file_server
    encode zstd gzip
    
    @api path /api/*
    reverse_proxy @api 127.0.0.1:8080 {
        header_up X-Real-IP {remote_host}
    }
}

И тот же сайт на nginx:

server {
    listen 443 ssl http2;
    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;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_session_cache shared:SSL:10m;
    ssl_stapling on;
    ssl_stapling_verify on;
    
    root /var/www/example;
    
    location / {
        try_files $uri $uri/ =404;
    }
    
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
    }
    
    gzip on;
    gzip_types text/css text/javascript application/json;
}

Caddy выигрывает на старте: ACME из коробки, certbot не нужен, не нужно настраивать таймеры на обновление, сам перевыпускает за 30 дней до истечения. Для маленьких проектов и pet-сайтов — лучший выбор по соотношению «вложил часы / получил результат».

Но как только начинается тонкая настройка — ssl_early_data, кастомные ciphers по группам клиентов, ECC + RSA сертификаты параллельно, OCSP must-staple — у nginx гибкости больше. У Caddy всё это либо нет, либо делается через плагины, которые надо собирать через xcaddy.

Производительность

wrk на статике 16 КБ, 200 коннектов, 4 потока, HTTPS:

wrk -t 4 -c 200 -d 30s --latency https://example.com/test.html

nginx: 48,300 req/s, p99 = 12 мс
Caddy: 31,500 req/s, p99 = 28 мс

Разница примерно 35% по throughput и 2.3x по p99. Под HTTP без TLS — разница меньше, но всё равно nginx быстрее процентов на 20.

Причина — Go-runtime и GC. На статике это видно, на динамике с прокси к бэкенду на 50 мс — не очень заметно, потому что упирается в бэкенд.

Память под нагрузкой:

ps -o pid,rss,comm -p $(pgrep -f 'nginx: worker')
ps -o pid,rss,comm -p $(pgrep caddy)

nginx с 4 воркерами при пиковой нагрузке — около 90 МБ суммарно. Caddy — 280-320 МБ. Для VPS с 1 ГБ памяти разница ощутимая.

TLS-fingerprint (JA3/JA4)

Тема, которой раньше никто не интересовался, а сейчас она важна и для антибот-защиты, и для обхода блокировок.

Caddy использует Go crypto/tls, и его JA3-отпечаток статичный и хорошо известный. Это плохо для обхода фильтрации, но нормально для обычного публичного сайта.

nginx с OpenSSL 3.x даёт более «стандартный» отпечаток, похожий на десятки тысяч других серверов. Если задача — мимикрировать под «обычный сайт» в условиях DPI, nginx тут лучше.

Кастомизация cipher-suite в Caddy:

{
    servers {
        protocols h1 h2 h3
    }
}

example.com {
    tls {
        protocols tls1.2 tls1.3
        ciphers TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384
        curves x25519 secp256r1
    }
}

В nginx — через ssl_ciphers и ssl_ecdh_curve. Возможностей больше, особенно если собирать с BoringSSL или нативным OpenSSL.

Где Caddy реально проще

Wildcard-сертификаты через DNS-01:

*.example.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
    reverse_proxy localhost:8080
}

Это всё. В nginx — отдельный hook на certbot, скрипт, проверка, обновление.

Автоматический HTTP→HTTPS редирект — встроенный, не надо писать отдельный server-блок.

JSON API для конфигурации — реально полезен, если у вас динамическая инфра с генерацией конфигов на лету. У nginx такого нет (есть OpenResty с lua, но это уже совсем другая история).

Где nginx реально проще

  • Десятки тысяч примеров в гугле под любой кейс
  • Модули — gRPC, mail, stream (TCP/UDP-проксирование), которые в Caddy либо нет, либо плагинами
  • Реальные крупные сайты крутятся на nginx, и большинство best practice уже отработаны
  • Stream-модуль для проксирования произвольного TCP — у Caddy есть layer4 плагин, но он сильно сырее

Что я выбираю

Pet-проекты, мелкие сайты, dev-среды — Caddy. Прод с трафиком, нестандартными TLS-требованиями, проксированием TCP/gRPC — nginx. И не вижу причин, чтобы мигрировать в одну или другую сторону «из принципа».

Итог

Caddy в 2026-м — отличный инструмент для быстрого подъёма HTTPS, но он по-прежнему тяжелее по памяти и медленнее под нагрузкой. nginx остаётся стандартом там, где важна производительность и гибкость. Считайте не в строчках конфига, а в человекочасах поддержки + ресурсах хоста.