Nginx против Caddy и Traefik: что выбрать для прокси

Nginx, Caddy и Traefik могут опубликовать веб-приложение в интернет, завершить TLS и отправить запрос в нужный контейнер. Но цена этого решения различается: Nginx требует больше ручной настройки, Caddy автоматизирует сертификаты, а Traefik лучше всего раскрывается в Docker и Kubernetes. Ошибка выбора проявится не в первом тестовом запросе, а при добавлении десятого сервиса, смене домена или аварии в продакшене.

Три разных взгляда на обратный прокси

Для сравнения возьмём актуальные основные ветки: Nginx 1.26–1.27, Caddy 2.x и Traefik 3.x. Точный минорный релиз стоит закреплять в конфигурации и проверять по документации перед установкой: синтаксис, пакет в репозитории и доступность отдельных функций могут отличаться.

Nginx — статически настроенный веб-сервер и обратный прокси. Вы описываете серверы, домены, upstream-группы и правила маршрутизации в конфигурационных файлах. Это предсказуемо, хорошо документировано и удобно для инфраструктуры, где изменения проходят через ревью и деплой конфигурации.

Caddy делает ставку на безопасные значения по умолчанию. Для публичного домена он умеет сам получить и обновлять сертификат, если DNS уже указывает на сервер, а порты 80 и 443 доступны извне. Его конфигурация короче, чем у Nginx, но экосистема модулей и привычные для Nginx инструкции не переносятся напрямую.

Traefik строит маршрутизацию вокруг источников обнаружения сервисов. Он читает метки Docker, объекты Kubernetes или другие providers и формирует динамическую конфигурацию. Это сокращает ручную работу в контейнерной среде, но добавляет ещё один слой диагностики: нужно понимать, что увидел Traefik, какие правила собрал и почему конкретный маршрут не активировался.

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

Обратный прокси* принимает запрос от клиента и передаёт его внутреннему приложению. Он может завершать TLS, выбирать upstream, добавлять заголовки, ограничивать доступ и вести журнал.

Сравнение по задачам эксплуатации

Когда выбирать Nginx

Выбирайте Nginx, если конфигурация должна быть максимально явной и редко меняется автоматически. Это хороший вариант для одного или нескольких виртуальных хостов, статического сайта, традиционного VPS, сложных правил кеширования и команды, которая уже умеет читать его конфигурацию.

Его сильная сторона — контроль. Можно отдельно описать лимиты тела запроса, таймауты, буферизацию, кеширование, заголовки и несколько upstream-групп. Такая детализация полезна, когда вы точно знаете, какие запросы проходят через систему и какие ограничения нужны каждому маршруту.

Плата за контроль — операционная рутина. При появлении нового сервиса нужно изменить конфигурацию, проверить её, применить без разрыва соединений и убедиться, что DNS, сертификат и upstream согласованы. Сам Nginx не знает, что в Docker появился новый контейнер, если вы не добавили внешний механизм обнаружения и генерации конфигурации.

Когда выбирать Caddy

Caddy подходит для небольшого и среднего проекта, где важнее быстро получить корректный HTTPS, чем вручную управлять каждым этапом выпуска сертификата. Типичный сценарий — VPS с несколькими сайтами, API за одним доменом или стенд, который должен подниматься без длинного набора шагов.

Автоматический TLS не отменяет требований к инфраструктуре. Домен должен разрешаться на нужный сервер, входящие порты должны быть доступны, а хранилище сертификатов — сохраняться между перезапусками. Если контейнер пересоздаётся вместе с данными Caddy, автоматизация перестаёт быть преимуществом и превращается в источник повторных запросов к центру сертификации.

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

Когда выбирать Traefik

Traefik логичен, когда сервисы постоянно создаются и удаляются, а их публикация должна следовать за состоянием Docker или Kubernetes. Вместо отдельного ручного файла для каждого приложения вы описываете связь приложения с прокси через labels или ресурсы оркестратора.

Это сокращает расхождение между фактическим составом кластера и конфигурацией прокси. Но labels становятся частью сетевой конфигурации, хотя лежат рядом с описанием контейнера. Ошибка в имени entrypoint, router, service или middleware может дать неочевидный результат: контейнер работает, а маршрут не появляется или отвечает не тем сервисом.

Traefik также требует дисциплины доступа к Docker API и панели управления. Сокет Docker нельзя бездумно публиковать наружу, а административный интерфейс нельзя оставлять доступным без аутентификации и сетевого ограничения. В Kubernetes отдельно проверяйте права ServiceAccount и область видимости ресурсов.

Что выбрать в четырёх типовых сценариях

• Один VPS и несколько сайтов. Caddy даст самый короткий путь к HTTPS. Nginx подойдёт, если у вас уже есть готовые шаблоны и процессы выпуска сертификатов.
• Статический сайт с тонкой настройкой кеша. Nginx обычно удобнее: его конфигурация хорошо приспособлена к явному управлению заголовками, буферами и отдачей файлов.
• Docker Compose с часто меняющимися сервисами. Traefik уменьшит количество ручных операций, но потребует стандарта labels, проверки доступа к Docker API и понятной схемы диагностики.
• Kubernetes. Сравнивайте не только сами прокси, но и конкретный способ интеграции: Ingress Controller, Gateway API, CRD, TLS-хранилище и мониторинг. Название продукта само по себе не гарантирует совместимость с вашим кластером.

Что ломается первым

Сертификат выпущен, но сайт недоступен

Проверьте DNS-записи, доступность 80 и 443 портов, внешний балансировщик и сохранность каталога с данными ACME. Для Caddy и Traefik автоматизация не работает в изолированной сети без подходящего challenge; для Nginx сертификат вообще может обновляться внешним процессом.

Прокси отправляет запрос не туда

Сначала проверьте Host, путь, выбранный entrypoint и фактический адрес upstream. В Traefik отдельно смотрите, какие labels прочитаны provider-ом. В Nginx проверяйте порядок и область действия блоков, а в Caddy — соответствие адреса сайта и маршрута.

После перезапуска исчезли сертификаты или маршруты

Проверьте volume для состояния прокси и способ генерации конфигурации. Динамическая модель Traefik не заменяет резервное копирование, а автоматический TLS Caddy не означает, что его рабочие данные можно хранить только в эфемерном контейнере.

Как сравнить производительность без выдуманных цифр

Не переносите чужие бенчмарки на свой проект. Зафиксируйте одинаковые версии, TLS-настройки, размер ответа, число upstream, лимиты CPU и памяти, затем измерьте задержку p50, p95 и p99, количество ошибок и потребление ресурсов при заданной параллельности. Отдельно повторите тест после включения access log, компрессии и кеширования: эти функции влияют на результат сильнее, чем само название прокси.

Практический критерий выбора

Если изменения проходят через Git и ревью, а инфраструктура стабильна, начинайте с Nginx. Если главная боль — ручной HTTPS на небольшом сервере, смотрите на Caddy. Если сервисы живут в Docker или Kubernetes и должны автоматически появляться в маршрутизации, рассматривайте Traefik.

Не смешивайте инструменты без причины. Связка Nginx перед Traefik может быть оправдана отдельными требованиями к внешнему периметру, но добавляет два набора логов, таймаутов, заголовков и правил TLS. Каждый дополнительный слой увеличивает время поиска причины ошибки.

Что сделать дальше

Составьте небольшой стенд с одним публичным доменом, двумя upstream-сервисами и намеренно сломанным маршрутом. Для каждого кандидата проверьте выпуск и обновление сертификата, поведение после перезапуска, журнал 4xx и 5xx, сохранность состояния и время добавления нового сервиса. После выбора закрепите версии образов, опишите health check и вынесите в мониторинг срок действия сертификата, долю ошибок и задержку p95.

Сноска. Upstream — внутренний сервер или группа серверов, куда обратный прокси передаёт запросы. В конфигурации это может быть адрес приложения, имя контейнера или набор backend-узлов.