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

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.

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