Caddy, Nginx, Angie и Apache: что поставить перед приложением

Когда поднимаешь очередной VPS, pet-проект, API-шлюз или домашний сервис, почти всегда встаёт один и тот же вопрос: что поставить перед приложением — Caddy, Nginx, Angie или старый добрый Apache?

Раньше ответ был почти автоматическим: “Ставь Nginx, не ошибёшься”. И это до сих пор нормальный ответ. Nginx быстрый, стабильный, предсказуемый, с огромным количеством примеров, готовых конфигов и понятной эксплуатационной моделью.

Но последние годы у Nginx появился очень сильный конкурент для небольших и средних проектов — Caddy. И во многих случаях он оказывается не просто удобнее, а банально рациональнее.

А рядом есть ещё Angie — форк Nginx от бывших разработчиков Nginx, который пытается сохранить привычный nginx-подход, но развивать его дальше.

Эта заметка не про “кто быстрее в синтетическом бенчмарке”. Для большинства обычных сайтов и внутренних сервисов узкое место будет не там. Гораздо важнее другой вопрос: что проще поддерживать, безопасно обновлять и не бояться трогать через полгода.

Коротко: в чём разница между Caddy, Nginx, Angie и Apache

Если совсем упростить:

Caddy  — простой reverse proxy/web server с автоматическим HTTPS из коробки.
Nginx  — классический мощный reverse proxy/web server для продакшена любого масштаба.
Angie  — nginx-compatible альтернатива с похожим синтаксисом и более активным развитием ряда возможностей.
Apache — старый универсальный web server, особенно живучий в PHP/CMS/shared-hosting мире.

Главная разница не в том, что один “быстрый”, а другой “медленный”. Все эти серверы могут работать быстро, если их нормально настроить.

Главная разница — в эксплуатационной модели.

Nginx обычно требует больше ручной настройки:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

А для HTTPS нужно отдельно думать про сертификаты, Certbot, reload, renewal hooks и прочую инфраструктурную мелочь.

Caddy в простейшем случае выглядит так:

example.com {
    reverse_proxy 127.0.0.1:3000
}

И всё. HTTPS будет выпущен и продлён автоматически.

Вот это и есть основная причина, почему Caddy так приятно использовать на небольших VPS, внутренних сервисах и личной инфраструктуре.

Таблица выбора

Задача	Что выбрать
Быстро опубликовать Docker-сервис по HTTPS	Caddy
Поднять Uptime Kuma, Gitea, Seafile, AI Gateway	Caddy
Нужен простой reverse proxy на личном VPS	Caddy
Большой продакшен с кэшем, балансировкой и сложными правилами	Nginx или Angie
Есть готовая инфраструктура на Nginx	Nginx
Хочется nginx-синтаксис, но более современная ветка	Angie
WordPress/Bitrix/shared hosting/.htaccess	Apache или Nginx + PHP-FPM
Старый PHP-проект, который уже работает на Apache	Apache, если нет причины мигрировать

Когда лучше использовать Caddy

Caddy особенно хорош там, где нужно быстро, безопасно и без лишней возни опубликовать сервис наружу.

Например:

https://ai.example.com       -> локальный AI gateway
https://monitor.example.com  -> Uptime Kuma
https://files.example.com    -> Seafile
https://app.example.com      -> Laravel/Vue/Node-приложение

Маленький VPS и один-два сервиса

Если у вас VPS, на котором крутится один сервис в Docker, Caddy часто идеален.

Пример:

ai.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:4000
}

Минимум шума. Минимум конфигурации. Автоматический TLS. Никакого отдельного Certbot.

Для личной инфраструктуры это огромный плюс. Особенно когда серверов несколько, времени мало, а хочется не “настроить красиво”, а чтобы работало и не разваливалось через три месяца.

Когда нужен простой HTTPS из коробки

Это главный козырь Caddy.

В Nginx HTTPS тоже несложно настроить, но обычно появляется связка:

Nginx + Certbot + cron/systemd timer + отдельные SSL-конфиги

В Caddy это встроено в сам сервер. Он сам выпускает сертификат, продлевает его и обслуживает HTTPS без отдельной обвязки.

Для большинства небольших проектов это ровно то, что нужно.

Когда хочется меньше конфигов и меньше риска ошибиться

Конфиги Caddy обычно короче и читаются проще.

Например, закрыть админку Basic Auth:

admin.example.com {
    basicauth {
        user $2a$14$....
    }

    reverse_proxy 127.0.0.1:8080
}

Или разделить API и UI:

ai.example.com {
    handle /ui* {
        basicauth {
            admin $2a$14$....
        }

        reverse_proxy 127.0.0.1:4000
    }

    handle {
        reverse_proxy 127.0.0.1:4000
    }
}

Да, в Nginx это тоже делается. Но в Caddy такие вещи часто выглядят менее громоздко.

Когда проект не требует сложной Nginx-магии

Caddy отлично подходит для:

reverse proxy к Docker-сервисам;
pet-проектов;
Laravel/Node/Python-приложений;
внутренних панелей;
Uptime Kuma, Grafana, Gitea, Seafile;
AI gateway;
временных стендов;
небольших коммерческих проектов;
инфраструктуры “для себя”.

Если нет сложной схемы кэширования, нестандартного балансирования, хитрых rewrite-правил и высокой нагрузки, Caddy часто будет проще и приятнее.

Когда лучше использовать Nginx или Angie

Caddy удобен, но это не значит, что Nginx устарел. Наоборот: Nginx всё ещё остаётся одним из самых понятных и предсказуемых вариантов для серьёзной инфраструктуры.

Высокая нагрузка и сложная инфраструктура

Если у вас большой продакшен, много upstream’ов, балансировка, кэширование, отдельные location-блоки, тонкая настройка буферов, лимитов, таймаутов и логирования — Nginx всё ещё очень силён.

Типичный случай:

несколько backend-сервисов;
отдельная статика;
API;
WebSocket;
кэширование ответов;
rate limiting;
сложные rewrite rules;
кастомные headers;
интеграция с legacy-конфигами.

Nginx здесь привычнее, документированнее и предсказуемее для большинства DevOps-команд.

Пример уже не выглядит так приятно, как Caddy, зато даёт больше явного контроля:

upstream backend {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;

        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_read_timeout 60s;
        proxy_connect_timeout 10s;
    }
}

Для маленькой админки это избыточно. Для большого продакшена — нормально.

Когда уже есть готовая инфраструктура на Nginx

Если проект уже живёт на Nginx, команда его знает, конфиги отлажены, мониторинг настроен, сертификаты выпускаются автоматически — не нужно менять только потому, что Caddy выглядит приятнее.

В инфраструктуре часто работает простое правило:

не трогай то, что стабильно работает и понятно обслуживается

Переход с Nginx на Caddy имеет смысл, когда он реально уменьшает сложность. Если он просто меняет одну привычную технологию на другую — пользы мало.

Когда нужен максимальный контроль

Nginx даёт очень много низкоуровневого контроля:

proxy_buffering;
proxy_cache;
limit_req;
limit_conn;
map;
upstream;
custom log_format;
сложные location rules;
тонкая настройка TLS;
интеграция с Lua/OpenResty.

Caddy тоже умеет многое, но если вы уже на уровне “reverse proxy как отдельный продукт”, Nginx будет привычнее и гибче.

Где здесь Angie

Angie можно воспринимать как вариант для тех, кто хочет остаться в nginx-мире, но смотрит в сторону более современной ветки.

У него похожая конфигурационная модель, поэтому переход с Nginx обычно психологически проще, чем переход на Caddy. Не нужно переучиваться на другой стиль конфигов, не нужно полностью менять подход к server, location, upstream.

Я бы смотрел в сторону Angie, если:

вы уже знаете Nginx;
хочется nginx-compatible конфигурацию;
проект новый, и можно спокойно выбрать не классический Nginx;
интересны дополнительные возможности Angie;
хочется избежать резкой смены эксплуатационной модели.

Но я бы не мигрировал с Nginx на Angie “ради галочки”. Если Nginx работает и не мешает — пусть работает.

Мой практический взгляд такой:

Caddy — когда хочется проще.
Nginx — когда нужна классика и максимальная предсказуемость.
Angie — когда нужен nginx-подход, но хочется альтернативную современную ветку.

А что насчёт Apache

Apache сейчас реже выбирают как reverse proxy для новой инфраструктуры, но списывать его не стоит.

Он всё ещё часто встречается в PHP-хостинге, WordPress, Bitrix и старых проектах. Главная причина — .htaccess.

Для классического shared-хостинга это удобно:

пользователь сам меняет rewrite-правила;
можно управлять поведением сайта без доступа к глобальному конфигу;
много CMS исторически умеют работать именно так.

Но для своего VPS я бы редко выбирал Apache как первый вариант.

Если у меня Docker, Laravel, Node, API, reverse proxy и несколько сервисов, я скорее выберу:

Caddy — если хочу проще и быстрее.
Nginx или Angie — если нужна гибкость и контроль.

Apache оставил бы для случаев, где он уже есть или где проект действительно завязан на .htaccess и классический PHP-хостинг.

PHP-проекты: Laravel, WordPress, Bitrix

Для Laravel на VPS я чаще всего смотрел бы в сторону:

Nginx + PHP-FPM

или:

Caddy + PHP-FPM

Оба варианта рабочие.

Nginx в PHP-мире встречается чаще, поэтому примеров и готовых конфигов больше. Caddy приятнее, если хочется меньше возни с HTTPS и reverse proxy.

Для WordPress и Bitrix всё зависит от окружения. Если проект уже живёт на Apache и активно использует .htaccess, миграция может оказаться дороже, чем польза от неё.

Если же проект переносится на свой VPS и хочется более управляемую схему, можно спокойно смотреть в сторону Nginx + PHP-FPM или Angie + PHP-FPM.

Практическая рекомендация

Мой текущий подход такой.

Для личных VPS и небольших сервисов — Caddy

Если нужно быстро опубликовать сервис:

Uptime Kuma;
AI gateway;
Seafile;
Gitea;
админку;
Laravel-приложение;
тестовый стенд;
Docker-сервис;

я почти всегда сначала смотрю в сторону Caddy.

Причина простая: меньше конфигов, меньше ручной возни с HTTPS, меньше шансов забыть продлить сертификат или ошибиться в Certbot.

Типовой Caddyfile:

app.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:3000
}

Для многих задач этого достаточно.

Для серьёзного продакшена и сложных схем — Nginx или Angie

Если проект растёт, появляется высокая нагрузка, несколько upstream’ов, кэширование, сложные правила, отдельная команда DevOps — Nginx выглядит более естественным выбором.

Типичная схема:

Nginx
  -> frontend
  -> backend API
  -> static files
  -> media
  -> websocket
  -> cache

Здесь Nginx даёт больше контроля и лучше вписывается в привычную production-инфраструктуру.

Angie можно рассматривать рядом с Nginx, если хочется сохранить nginx-подход, но попробовать более свежую альтернативу.

Для старых PHP/CMS-проектов — по ситуации

WordPress, Bitrix, старые PHP-приложения, shared hosting — тут часто важнее не “что современнее”, а “что проще поддерживать”.

Если проект уже работает на Apache — можно оставить Apache.

Если переносите на VPS и хотите нормальную схему:

Nginx + PHP-FPM

или:

Caddy + PHP-FPM

Оба варианта рабочие. Но Nginx в PHP-мире всё ещё встречается чаще, поэтому примеров и готовых конфигов больше.

Мой короткий выбор

Если совсем коротко:

Caddy — когда нужно быстро, просто и безопасно.
Nginx — когда нужно гибко, привычно и под большую нагрузку.
Angie — когда хочется nginx-подход, но не обязательно сам Nginx.
Apache — когда проект старый, CMS-зависимый или нужен .htaccess.

Я бы не выбирал Caddy потому, что он “модный”. И не выбирал бы Nginx только потому, что “так принято”.

Выбор должен быть от задачи.

Для моего личного VPS, где нужно поднять пару сервисов за reverse proxy и не тратить вечер на сертификаты, Caddy — отличный вариант.

Для большого продакшена с тонкой настройкой, кэшами, upstream’ами и командной эксплуатацией — Nginx всё ещё один из самых надёжных вариантов.

Angie стоит держать в поле зрения, если хочется остаться в nginx-экосистеме, но попробовать более современную альтернативу.

А для старого PHP-проекта на хостинге иногда лучший web server — тот, который уже работает и который не нужно срочно переписывать ради красоты.