Що сталося

Автор на 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. Обидва сервери зрілі — змінюється не «переможець назавжди», а ціна супроводу саме вашої схеми на краю.