Nginx против Caddy и Traefik: что выбрать на практике

Nginx, Caddy и Traefik могут проксировать один и тот же веб-сервис, но ведут себя по-разному уже на первом продакшен-развёртывании. Nginx обычно требует больше ручной настройки, Caddy быстрее выдаёт HTTPS, а Traefik выигрывает там, где контейнеры постоянно появляются и исчезают. Ниже — практическое сравнение для Nginx 1.26–1.27, Caddy 2.8 и Traefik 3.x; перед установкой проверьте актуальные версии и директивы в документации.

Главное различие: кто описывает маршруты

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

Caddy тоже может работать с конфигурационным файлом, однако его сильная сторона — короткий Caddyfile и автоматическое получение сертификатов Let's Encrypt для публичных доменов. Для небольшого сайта это сокращает количество ручных операций, но автоматический TLS не отменяет требований DNS, открытых портов 80 и 443 и корректной настройки хостинга.

Traefik рассчитан на окружения, где конфигурация приходит от провайдера: Docker, Kubernetes, Consul и других источников. Маршруты можно описывать labels или Kubernetes-ресурсами. Это удобно для динамической инфраструктуры, но добавляет ещё один слой диагностики: проблема может быть в контейнере, label, provider или TLS-маршрутизаторе.

Термин. Reverse proxy — сервер-посредник, который принимает запрос клиента и передаёт его внутреннему приложению. Клиент видит домен прокси, а адрес и порт приложения остаются скрытыми во внутренней сети.

Сравнение без маркетинговых обещаний

Один reverse proxy в трёх конфигурациях

Предположим, приложение слушает порт 3000 внутри сервера или контейнерной сети, а пользователи открывают app.example.com. Ниже показана одна и та же операция — передать запрос приложению. Код не включает DNS, firewall и выпуск сертификатов.

Nginx: больше явных деталей

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1: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;
    }
}

Такой блок рассчитан на Nginx 1.26–1.27. Для HTTPS нужен отдельный server-блок или другой слой, который завершает TLS. После изменения конфигурации проверяйте её командой nginx -t и только затем выполняйте reload. Путь к файлу зависит от дистрибутива, поэтому не стоит вслепую копировать путь из чужого сервера.

Caddy: минимум обвязки

app.example.com {
    reverse_proxy 127.0.0.1:3000
}

Для Caddy 2.8 публичный домен в таком виде означает HTTPS-сценарий с автоматическим управлением сертификатом, если DNS указывает на сервер и входящие подключения доступны. Если приложение находится в Docker, имя upstream должно разрешаться внутри сети Docker; 127.0.0.1 тогда указывает на сам контейнер Caddy, а не на соседний контейнер.

Traefik: маршрут как описание контейнера

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.app.rule=Host(`app.example.com`)"
  - "traefik.http.routers.app.entrypoints=web"
  - "traefik.http.services.app.loadbalancer.server.port=3000"

Это фрагмент labels для Traefik 3.x при включённом Docker provider и entrypoint с именем web. Сам по себе он не настраивает HTTPS и не создаёт entrypoint: для TLS понадобятся отдельные router-настройки и ACME-конфигурация. Преимущество подхода в другом: при удалении контейнера его маршрут можно удалить вместе с метаданными сервиса.

Самый дешёвый reverse proxy — не тот, у которого меньше строк в конфиге, а тот, чьи ошибки ваша команда умеет быстро найти ночью.

Что выбрать по сценарию

Один сайт, VPS и два-три сервиса

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

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

Docker Compose с несколькими приложениями

Traefik удобен, когда каждый сервис должен сам объявить домен и внутренний порт через labels. Это ускоряет релизы, но требует политики: кто имеет право менять labels, как проверяются домены и где хранятся данные ACME. Без такой политики любой ошибочный label может создать неожиданный маршрут.

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

Высокая нагрузка и строгий контроль

Не выбирайте прокси только по заявленной производительности. На результат сильнее влияют TLS, размер ответов, число соединений, keep-alive, лимиты приложения, сеть и способ балансировки. Для Nginx, Caddy и Traefik сравнивайте одинаковую схему: один и тот же backend, одинаковые заголовки, TLS-режим и число параллельных запросов.

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

Что обычно ломается

• 502 Bad Gateway. Прокси не может подключиться к приложению: сервис не запущен, указан неверный порт или в Docker использован 127.0.0.1 вместо имени сервиса.
• 404 от Traefik. Запрос дошёл до Traefik, но не совпал с rule роутера. Проверьте домен, entrypoint и факт обнаружения labels.
• Сертификат не выпускается. Проверьте DNS, входящие порты 80 и 443, лимиты центра сертификации и логи ACME. Не удаляйте хранилище сертификатов без понимания последствий.
• Приложение видит IP прокси. Передайте и корректно обработайте X-Forwarded-For и X-Forwarded-Proto. Доверять этим заголовкам без ограничения источников опасно.
• WebSocket отключается. Убедитесь, что прокси и приложение поддерживают upgrade-соединение, а таймауты не короче времени жизни соединения.

Как сравнить варианты на своём стенде

Не переносите чужие бенчмарки в свою инфраструктуру. Поднимите один backend и по очереди направьте к нему Nginx, Caddy и Traefik. Зафиксируйте версию, число ядер, объём памяти, тип диска, размер ответа, наличие TLS и количество параллельных клиентов.

Снимайте не только среднее время ответа, но и p95/p99, число ошибок 4xx/5xx, потребление памяти и время применения конфигурации. Отдельно проверьте холодный старт, перезапуск прокси, недоступность backend и выпуск или обновление сертификата. Без этих сценариев тест измеряет только удачный путь.

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

Сначала опишите текущую топологию: домены, backend-порты, Docker-сети, TLS и требования к WebSocket. Затем соберите минимальный стенд на выбранной версии и добавьте проверки конфигурации в CI или процедуру деплоя. В проде следите за p95/p99, 502/504, сроком сертификата, числом открытых соединений и временем reload.

Если инфраструктура статична, начните с Nginx или Caddy и не добавляйте динамический слой без конкретной причины. Если сервисы постоянно создаются и удаляются контейнерной платформой, протестируйте Traefik на той же схеме маршрутов и заранее документируйте labels, TLS и правила доступа.

Сноска. ACME — протокол, через который reverse proxy может автоматически запросить и продлить TLS-сертификат у совместимого центра сертификации, например Let's Encrypt.