Что произошло

Автор на Dev.to сравнивает две философии края сети. Caddy сам запрашивает сертификаты у Let's Encrypt или ZeroSSL, проходит проверки HTTP-01 / TLS-ALPN-01, ставит прошивку ответа OCSP и продлевает сертификаты без перезапуска и обрыва соединений. Достаточно публичной A-записи DNS и имени домена в конфиге. У Nginx встроенного клиента ACME нет: нужны Certbot или acme.sh, каталог для проверки, cron/systemd и хук на перезагрузку. Если таймер молча сломался — сервисы уходят с просроченным шифрованием на входе.

Конфигурация тоже разная. Три строки в Caddyfile для api.example.com с reverse_proxy localhost:8080 дают перенаправление на HTTPS, актуальные шифры TLS 1.3, HTTP/2 и HTTP/3 и проксирование. В Nginx тот же базовый уровень безопасности обычно требует два server-блока (80 и 443), пути к сертификатам, списки протоколов и шифров, заголовки Host / X-Real-IP / X-Forwarded-Proto и настройку буферов. Гибкость выше, но и цена ошибки — тоже.

По архитектуре Nginx написан на C с epoll/kqueue: при десятках тысяч долгих соединений след в памяти часто около 10–25 МБ в простое, пик одновременных соединений при тонкой настройке может превышать 100 тысяч. Caddy на Go выигрывает в безопасности памяти (меньше классических переполнений буфера), но в простое обычно занимает порядка 35–65 МБ; пропускную способность гигабитных каналов на обычных облачных машинах он всё равно закрывает. HTTP/3 (QUIC) и сжатие Zstandard у Caddy включены нативно; у Nginx HTTP/3 и zstd/brotli часто требуют особой сборки или модулей.

Почему это важно

Для разработчиков полного стека и инженеров сопровождения выбор прокси — это выбор операционной модели, а не только сравнительного теста. Команды с частыми доменами, контейнерами и «домашними» сервисами платят не процессором, а инцидентами: просроченный сертификат в выходные обходится дороже лишних двадцати мегабайт оперативной памяти. На гипермасштабе края и на устройствах с жёстким лимитом памяти картина обратная: каждый мегабайт и каждый цикл epoll уже посчитаны, а стек модулей OpenResty/Lua уже вписан в регламенты.

Сравнение 2026 года полезно ещё и как фильтр маркетинга. «Современный» сервер не отменяет Nginx в унаследованных системах и в плотных кластерах. «Проверенный» Nginx не обязан оставаться единственным ответом, если команда тонет в ручных сценариях ACME и раздутых конфигах. Решение стоит привязывать к риску простоя из‑за сертификатов, к наличию собственных модулей и к тому, кто ночью чинит рабочую среду.

На практике

1. Берите Caddy, если нужен HTTPS без внешнего Certbot: один Caddyfile, автоматическое продление и меньше «забытых» таймеров.
2. Берите Caddy, если важны HTTP/3 и zstd без пересборки ядра и если удобно менять маршруты через JSON API на localhost:2019.
3. Оставляйте Nginx, когда жмёте максимум одновременных соединений на малой памяти или когда уже живёте на OpenResty/Lua и закрытых модулях.
4. В Nginx заранее спланируйте цепочку ACME: проверка, таймер, хук nginx -s reload и оповещение о сроке сертификата — иначе «тихий» сбой обновления становится внешним инцидентом.
5. Для одного и того же обратного прокси сравните не только число запросов в секунду, но и время до рабочего HTTPS, объём конфига и число ручных шагов при добавлении домена.
6. В смешанной схеме допустим Caddy на разработческих и мелких сервисах, Nginx — на горячем краю с плотной нагрузкой; смешивать философии в одном файле без причины не стоит.

Итог

В 2026 Caddy выглядит естественным выбором для облачных сервисов и команд, которые хотят убрать головную боль с сертификатами и держать короткий конфиг. Nginx остаётся сильным там, где считаются мегабайты и уже вложены годы в модули на C. Оба сервера зрелые — меняется не «победитель навсегда», а цена сопровождения именно вашей схемы на краю.