Caddy проти Nginx на VPS: порівняння файлів конфігурації

Новий VPS, домен спрямований на нього, і одна команда відділяє вас від працюючого вебсервера. Те, що ви наберете далі, встановить або Caddy, або Nginx, і це одне рішення визначає, скільки часу ви витрачатимете на TLS протягом усього життя машини. Отже: Caddy проти Nginx на VPS, який із них ви встановлюєте?

Далі йдуть ті самі три конфігурації, налаштовані в обох інструментах, пліч-о-пліч, із повідомленими цифрами пам'яті, підводним каменем wildcard-сертифікатів і практичними нотатками щодо міграції, якщо ви вже на Nginx.

Коротко

• Висновок: Caddy для більшості нових навантажень VPS, особливо для розробників-одинаків, невеликих команд і TLS за принципом «налаштував і забув». Обирайте Nginx, коли вам потрібна його екосистема модулів, явне тонке налаштування, наявний досвід команди чи найменший можливий слід у пам'яті.
• Автоматичний HTTPS: Caddy сам отримує та поновлює сертифікати. Ні Certbot, ні cron, ні хука перезавантаження. Nginx потребує Certbot (або іншого ACME-клієнта) та автоматизації поновлення навколо нього.
• Пам'ять: Nginx стрункіший завдяки C замість Go. Ця різниця рідко щось вирішує на сучасному плані; цифри в таблиці нижче.
• Підводний камінь: Caddy не є безконфігураційним для wildcard. Ім'я на кшталт *.example.com потребує DNS-виклику, що означає плагін та API-токен.

Усе порівняння на одному екрані:

Діапазони пам'яті взято з одного стороннього тесту на VPS і їх слід розглядати як орієнтовні, а не універсальні вимоги. Фактичне використання залежить від версій програмного забезпечення, увімкнених модулів, журналювання, трафіку та методології тестування. Інформація про версії та ліцензії взята з офіційних репозиторіїв проєктів.

Автоматичний HTTPS у Caddy (і що він насправді замінює)

Caddy сам отримує та поновлює TLS-сертифікати. Спрямуйте публічний домен на машину, запустіть Caddy, і він отримає сертифікат від Let's Encrypt чи ZeroSSL, а потім поновлюватиме його у фоні. Ні Certbot, ні завдання cron, ні хука перезавантаження після поновлення. Це автоматичний HTTPS у Caddy в одному реченні, і саме через це люди переходять.

Під капотом Caddy використовує виклик HTTP-01 (port 80) або TLS-ALPN-01 (port 443) щоб підтвердити право власності на домен, а потім тримає сертифікат актуальним без залучення жодного другого інструмента.

Еквівалент у Nginx використовує окремий ACME-клієнт. За поширеного certbot --nginx робочого процесу Certbot може отримати та встановити сертифікат, а потім повторно використати той самий плагін і збережені опції під час поновлення. Більшість встановлень Certbot також містять заплановане завдання, яке виконується certbot renew автоматично.

Якщо ви використовуєте certbot certonly чи інший ACME-клієнт, який лише записує поновлені файли на диск, додайте хук розгортання який перезавантажує Nginx після успішного поновлення. Ця конфігурація працює, але вона все одно залишає більше рухомих частин, ніж Caddy: вебсервер, ACME-клієнт, планувальник поновлення й будь-який хук розгортання залишаються окремими компонентами.

Операційна перевага Caddy в тому, що видача сертифіката, розгортання, поновлення та перенаправлення з HTTP на HTTPS інтегровані в сам сервер. За замовчуванням Caddy починає спроби поновлення, коли залишається приблизно одна третина терміну дії сертифіката, 30 днів для 90-денного сертифіката, якщо центр сертифікації не вказує інше вікно поновлення.

Порада: Стандартні ACME-виклики Caddy потребують публічної доступності на port 80 чи 443: HTTP-01 використовує port 80, тоді як TLS-ALPN-01 використовує port 443. Якщо port 80 заблоковано, але 443 відкритий, TLS-ALPN усе одно може працювати; якщо машина не звернена до інтернету, використовуйте DNS-01, так само як для wildcard-сертифікатів нижче.

Файли конфігурації, пліч-о-пліч

Ось три поширені конфігурації VPS: зворотний проксі HTTPS, обслуговування статичних файлів і базова автентифікація, написані для обох інструментів. Приклади Caddy містять автоматичний HTTPS. Приклади Nginx припускають, що сертифікат уже надано, а приклади статичних файлів і базової автентифікації показують лише серверний блок HTTPS. Повторно використайте блок перенаправлення port-80 з першого прикладу, якщо хочете еквівалентну поведінку перенаправлення з HTTP на HTTPS.

Зворотний проксі до локального застосунку на port 3000:

Caddyfile

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-апстриму, як наведений вище, Caddy передає вхідний Host заголовок далі й встановлює X-Forwarded-For, X-Forwarded-Proto, і X-Forwarded-Host за замовчуванням. У Nginx ви зазвичай додаєте проксі-заголовки явно, коли апстриму потрібні оригінальний хост, схема та ланцюжок клієнтських адрес. Ось компроміс у мініатюрі: 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 не перейменувала її, як зазначено в документації basic_auth Caddy, і старі посібники досі збивають людей із пантелику через це.

Порада: Той хеш у Caddyfile — це не пароль. Це вивід bcrypt з caddy hash-password. Виконайте команду, вставте те, що вона виводить. Caddy відмовляється від паролів у відкритому тексті в конфігурації, що є правильним стандартом і невеликою несподіванкою першого разу.

Конфігурації говорять самі за себе. Caddy згортає TLS, розумні проксі-заголовки та перенаправлення в кілька рядків; Nginx явний і багатослівний і дає вам кожен важіль. Якщо ви провели роки в Nginx, багатослівність — це м'язова пам'ять, а контроль — це суть. Якщо ні, Caddyfile — це конфігурація, яку ви можете тримати в голові. Практичний висновок простий: конфігурацію Caddy легше читати з першого погляду, тоді як Nginx дає вам більше явного контролю.

Продуктивність і пам'ять: уважне читання тестів

Опубліковані тести вказують у тому самому загальному напрямку: Nginx зазвичай використовує менше пам'яті й часто лідирує за чистою пропускною здатністю, але розмір цієї переваги сильно залежить від середовища.

In одному сторонньому тесті на чотириядерній VM, Nginx досяг приблизно 48 000 запитів на секунду порівняно з приблизно 42 000 для Caddy. Той самий тест повідомив про затримку HTTPS p99 у 2,1 мс для Nginx і 2,4 мс для Caddy. Розглядайте це як результати однієї конфігурації, а не універсальний запас продуктивності.

Діапазони пам'яті в порівняльній таблиці взято з окремого тесту на VPS. Ще один синтетичний тест при 50 000 одночасних з'єднаннях повідомив про 145 MB для Nginx і 520 MB для Caddy, але цей тест використовував істотно інші умови обладнання й навантаження. Його абсолютні цифри не слід порівнювати безпосередньо з наведеними вище цифрами VPS.

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

Висновок розділу: обирайте на основі операцій, якщо тільки ваш сервер не обмежений у пам'яті або ваші власні навантажувальні тести не показують, що пропускна здатність проксі є вузьким місцем.

Підводний камінь wildcard-сертифіката (Caddy не завжди безконфігураційний)

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 і зважуєте перехід, почніть зі зниження очікувань щодо автоматизації: є адаптер конфігурації NGINX для Caddy, але він неповний і його не слід розглядати як надійний шлях міграції в один прохід. Міграція з Nginx на Caddy — це здебільшого ручне переписування, і більша його частина стає коротшою.

Що переноситься й стає простішим, згідно з посібником з конвертації від спільноти Caddy:

• Для HTTP-апстримів 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.

Часті запитання

Чи замінює Caddy Certbot?

Так. Caddy може сам отримувати та поновлювати публічні сертифікати, зокрема wildcard-сертифікати, тож Certbot не потрібен. Wildcard потребують валідації DNS-01, що означає налаштування сумісного модуля DNS-провайдера та облікових даних API.

Чи використовує Caddy менше пам'яті, ніж Nginx?

Ні. Nginx загалом має менший слід у пам'яті. Один сторонній тест на VPS повідомив про 2-8 MB у стані спокою для Nginx і 15-25 MB для Caddy, але ці цифри специфічні для навантаження, а не є фіксованими вимогами до пам'яті. Різниця важить найбільше на серверах, обмежених у пам'яті, які запускають кілька сервісів.

Чи Caddy швидший за Nginx?

Це залежить від навантаження. Обидва зазвичай достатньо швидкі для типового трафіку зворотного проксі на VPS. У наведених тестах, Nginx лідирував за чистою пропускною здатністю та ефективністю пам'яті, але розмір різниці істотно змінювався залежно від обладнання, характеру трафіку та рівня одночасності. Немає єдиного відсотка, який застосовувався б до кожного розгортання.

Чи підтримує Caddy wildcard SSL-сертифікати?

Так. Wildcard, як-от *.example.com потребує валідації DNS-01. Щойно Caddy отримає сумісний модуль DNS-провайдера та облікові дані API, він може отримувати та поновлювати wildcard-сертифікат автоматично.

Чи Nginx Proxy Manager те саме, що й Nginx?

Ні. Nginx Proxy Manager — це GUI-обгортка над Nginx, яка зберігає свою конфігурацію в базі даних застосунку, використовує веб-UI на port 81 і керує хостами зворотного проксі та сертифікатами через цей інтерфейс. Ядро Nginx налаштовується текстовими файлами й не має власного GUI.

Коли мені використовувати Nginx замість Caddy?

Обирайте Nginx, коли вам потрібен тонкий контроль, конкретний модуль з його зрілої екосистеми, кожен останній MB на сервері, обмеженому в пам'яті, обслуговування статичних файлів з високою одночасністю або коли ваша команда вже має глибокий досвід у Nginx.