Caddy против nginx против Traefik для небольших продуктовых команд

Почему этот выбор быстро становится сложным

Небольшие продуктовые команды не выбирают reverse proxy потому, что это интересно. Его выбирают потому, что кому-то нужно направлять трафик в нужный сервис, поддерживать TLS и не проснуться ночью из-за упавшего сертификата.

Обычно эта работа ложится на одного человека. Иногда это основатель, который всё ещё сам деплоит приложение. Иногда это инженер, который знает DNS и Linux ровно настолько, чтобы всё продолжало работать. В итоге один человек отвечает за маршрутизацию, сертификаты, редиректы, заголовки и уборку после поломки.

Когда у вас одно приложение и один домен, это ещё терпимо. Но после нескольких мелких добавлений всё начинает путаться. Появляется маркетинговый сайт. Потом API. Потом staging. Потом админка под basic auth. Каждое изменение кажется крошечным, поэтому команда копирует блок, меняет две строки и идёт дальше.

Так и начинается дрейф. В скопированном правиле остаётся старый hostname. Таймаут сохраняется, хотя новому сервису он уже не нужен. Редирект добавляют в прокси, а потом ещё раз — в приложении или CDN. Никто не планирует запутанную схему. Она растёт потому, что выпуск фич всегда важнее уборки.

Выбор между Caddy, nginx и Traefik часто подают как спор о синтаксисе. Для небольших команд это обычно вопрос ответственности. Если TLS живёт в одном месте, маршрутизация — в другом, а особые случаи спрятаны в скриптах деплоя или labels контейнеров, никто не видит полный путь запроса целиком.

Сигналы тревоги появляются быстро. Два сервиса отвечают на одном и том же host, и никто не понимает, какое правило сработало. Продление сертификата работает в staging, но ломается в production. Редирект зацикливается только за CDN. Деплой тихо возвращает правило, которое кто-то удалил на прошлой неделе.

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

Как каждый инструмент ощущается в повседневной работе

Настоящая разница между этими инструментами видна в обычных задачах. Кому-то нужно добавить поддомен, поменять маршрут или починить TLS до следующего деплоя. Вот тогда компромиссы становятся очевидными.

Caddy ближе всего к подходу «открыл один файл, перезагрузил, пошёл дальше». Большинство команд держат короткий Caddyfile, добавляют блок сайта и позволяют автоматическому HTTPS самому запрашивать и продлевать сертификаты. Это заметно сокращает рутину. Если у вас есть сайт, API и, возможно, staging-копия, Caddy обычно остаётся очень читаемым.

nginx даёт более тонкий контроль. Поэтому он и встречается почти везде. Можно разбить конфиг на несколько файлов, использовать includes, писать очень точные правила маршрутизации и задавать TLS ровно так, как нужно. Минус очевиден: два инженера могут собрать одинаковый nginx совершенно по-разному. И оба варианта будут работать. Но следующему человеку всё равно придётся сначала разобраться в этом стиле, прежде чем он сможет что-то безопасно поменять.

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

Но есть и подвох: правила прокси теперь живут рядом с настройками деплоя приложения, поэтому мелкие изменения маршрутизации могут прятаться там, где их никто не ожидает.

В повседневной работе всё сводится к простому рисунку. Caddy держит большинство изменений в одном читаемом файле. nginx даёт больше контроля, но и больше способов уйти в дрейф. Traefik встраивает логику прокси в определения сервисов.

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

Если один человек отвечает за ops лишь частично, Caddy часто оказывается самым спокойным вариантом. Если команда уже хорошо знает nginx, его контроль всё ещё может стоить дополнительных усилий. Если ваши деплои уже строятся вокруг Docker labels или объектов Kubernetes, Traefik может ощущаться чистым и быстрым — пока отладка не отправит вас по нескольким файлам вместо одного.

TLS, когда операциями занимается один человек

TLS — это та область, где небольшая команда либо экономит время, либо теряет целый день из-за проблемы с сертификатом, которая тихо сидела на заднем плане.

Caddy обычно проще всего начать использовать. Укажите домен на сервер, напишите короткий конфиг — и он сам запросит и продлит сертификаты. Для маленькой команды это значит меньше движущихся частей и меньше шансов забыть cron-задачу, hook Certbot или скрипт обновления.

Traefik тоже автоматизирует TLS, но просит больше настройки. Нужно задать certificate resolvers, storage и правила router. Это всё ещё вполне реально, но ощущается скорее как работа с диспетчером трафика, чем с обычным веб-сервером.

nginx даёт максимум контроля и максимум рутины. Сам по себе он не работает с ACME-сертификатами, поэтому команды обычно добавляют вокруг него Certbot или другой клиент. Это работает, но обновления теперь зависят от дополнительных файлов, таймеров, шагов reload и человека, который через полгода должен помнить, как всё это связано.

Что меняется после первого дня

Первый сертификат редко бывает проблемой. Проблема — продление.

В Caddy продления встроены, поэтому сбои обычно видны в логах и на проверках запуска. В Traefik обновления тоже автоматические, но нужно понимать, где он хранит данные сертификатов и где пишет ошибки ACME. В nginx слабое место — всё, что вокруг него. Сервер может выглядеть здоровым, хотя задача продления сертификата тихо провалилась в фоне.

Wildcard-сертификаты сокращают разницу, но не убирают операционную нагрузку. Все три инструмента могут их использовать, но выпуск wildcard обычно означает DNS-01 challenge. А это уже работа для того, кто управляет DNS. Если доступ к DNS находится у основателя, агентства и регистратора, чей аккаунт никто не может найти, планы с wildcard быстро начинают раздражать.

Для staging и локальной разработки Caddy особенно приятен, потому что HTTPS остаётся близким к production почти без усилий. Traefik тоже справляется, хотя настройка там менее дружелюбна. В nginx часто остаются self-signed сертификаты, ручные шаги или локальный процесс, который ведёт себя не так, как production.

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

Где начинается config drift

Дрейф конфигурации обычно начинается с разумной короткой дороги. Кто-то копирует server block из production в staging, меняет две строки и идёт дальше. Через неделю CORS, заголовки или таймауты уже не совпадают. Никто не собирался устраивать беспорядок. Просто мелкие изменения перестали сходиться друг с другом.

Небольшие команды чувствуют это особенно рано, потому что одни и те же несколько людей делают всё: выпускают фичи, чинят сбои, продлевают домены и подправляют правила прокси между встречами. Когда живой фикс решает текущую проблему, многие никогда не возвращают его обратно в Git. Сервер работает — значит, задача исчезла. А потом следующий деплой удаляет это исправление или другой сервер вообще его не получает.

У nginx дрейф обычно выглядит знакомо: скопированные фрагменты, полуобщие include-файлы и конфиги, отредактированные вручную на одном сервере, но не на другом. Caddy частично снижает этот риск, потому что у него короче конфиг и проще TLS, но дрейф всё равно появляется, если люди правят Caddyfile прямо на сервере во время инцидента. Простый синтаксис не защищает команду от неописанных изменений.

У Traefik ловушка другая. Он может прятать правила маршрутизации внутри Docker labels или манифестов приложений, и тогда конфиг прокси перестаёт выглядеть как конфиг прокси. Один разработчик меняет label в одном Compose-файле, другой сервис использует другой шаблон именования — и теперь логика маршрутизации размазана по нескольким репозиториям. Сначала это кажется аккуратно. В два часа ночи — уже разрозненно.

Исправление скучное, но эффективное: выберите один источник правды. Сложите маршрутизацию, настройки TLS, редиректы и upstream-адреса в одном месте, а потом проводите каждое изменение через него.

Несколько привычек помогают избежать большей части дрейфа:

• Храните конфиг прокси в Git, даже для hotfix.
• Используйте одну и ту же структуру в dev, staging и production.
• Не смешивайте file-based rules со скрытыми labels, если команда не договорилась о понятном шаблоне.
• Оставляйте комментарии для странных или временных правил.

Если команда не может за десять секунд ответить на вопрос «где живёт этот маршрут?», дрейф уже начался.

Отладка в 2 часа ночи

Большинство сравнений прокси фокусируются на настройке. Но большая разница проявляется тогда, когда деплой ломает логин, API начинает отдавать 502 и никто не хочет читать три слоя конфигурации в полусне.

Начните с одного реального запроса и проследите его по шагам. Выберите URL, отправьте запрос и проведите его через DNS, прокси и приложение. Если сразу уйти в код приложения, можно потратить час на проблему, которая живёт в маршрутизации или TLS.

Сначала смотрите access-логи. Они показывают, дошёл ли запрос до прокси, какой host и path совпали, и какой статус вернулся. Типичные варианты просты: если прокси вообще не записал запрос, смотрите DNS, TLS или load balancer перед ним. Если в логах 404, маршрут, скорее всего, не совпал. Если 502, прокси нашёл маршрут, но не смог достучаться до приложения. Если браузер показывает предупреждение о сертификате, сначала проверьте прокси, а не код приложения.

Caddy часто меньше всего раздражает при TLS-ошибках. Поскольку он сам управляет сертификатами, логи обычно прямо указывают на реальную проблему: сбой challenge, неверный DNS или заблокированный порт 80 или 443. Когда Caddy возвращает 404, site block или маршрут обычно просто не совпал. Это неприятно, но обычно легко сузить причину.

nginx даёт много контроля, но отладка зависит от того, насколько дисциплинирован конфиг. 404 может появиться из-за порядка location, отсутствующего root или запроса, который попал не в тот server block. 502 обычно означает, что upstream недоступен, порт указан неверно или сломан путь к socket. Хорошая новость в том, что nginx перезагружается предсказуемо, а это важно, когда вы тестируете исправление под давлением.

Traefik кажется удобным, пока источник правды не становится расплывчатым. 404 часто означает, что ни один router не совпал с правилом host или path. 502 обычно указывает на backend-сервис или сеть. TLS может оставаться простым, но как только вы добавляете несколько entrypoints, resolvers и labels, становится труднее увидеть, какая настройка на самом деле сработала. Hot reload удобен, но он же может запутать вас, если Docker labels или другой provider снова подсовывают старый конфиг.

В два часа ночи побеждает скука. Лучший прокси — тот, который позволяет одному человеку быстро ответить на четыре вопроса: запрос вообще дошёл, что совпало, куда он пошёл и что изменилось после reload?

Как выбрать без лишних раздумий

Большинству небольших команд не нужен самый мощный прокси. Им нужен тот, который можно поменять во вторник, когда всё горит, не открывая шесть документов и не гадая, почему TLS перестал продлеваться.

Начните с простого инвентаря. Запишите каждый сервис, каждый hostname и каждую среду, которой нужна отдельная маршрутизация. У небольшого продукта обычно больше поверхности, чем команда сама признаёт: сайт, API, admin-панель, staging, возможно, preview-приложения. Когда этот список становится реальным, выбор упрощается.

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

Короткий эксперимент скажет больше, чем длинная таблица фич. Создайте один реальный сертификат и проверьте, работает ли продление. Отправьте трафик на backend, который не отвечает, и посмотрите на путь ошибки. Поменяйте один hostname и замерьте полное обновление. Потом попросите коллегу объяснить схему без подсказок. Последняя проверка жёсткая, но полезная. Если только один человек может объяснить, почему запросы доходят до admin-приложения, схема уже слишком сложна для вашей команды.

Для большинства небольших команд правило простое: выбирайте инструмент, который команда может объяснить, изменить и отладить даже в полусне. Caddy подходит командам, которым нужны автоматический HTTPS и читаемый конфиг без лишней нагрузки. nginx подходит тем, кто хочет точный контроль и не боится ручной работы. Traefik подходит командам, которые уже мыслят в контейнерах, labels и service discovery.

Если всё ещё не можете решить, запустите одно и то же маленькое приложение на всех трёх на один вечер. Сайт, API, admin. Добавьте TLS, сломайте один backend, поменяйте один hostname. Правильный выбор обычно ощущается немного скучным. И это хороший знак.

Пример: маленькое приложение с сайтом, API и админкой

Представьте команду из трёх человек. У них есть публичный сайт, JSON API и админ-панель с логином. Всё работает в Docker Compose, с одним стеком для staging и одним для production.

Вот здесь выбор перестаёт быть абстрактным. Вам не нужна platform team. Вам нужен прокси, который всё ещё выглядит разумно, когда через шесть месяцев деплои по-прежнему делает уставший человек.

Обычно схема простая на бумаге: сайт отвечает на основном домене, API лежит на поддомене, а админка использует свой поддомен или path с более строгими правилами доступа. Дорогими становятся именно детали.

С Caddy один Caddyfile может описать все три маршрута обычным текстом. Автоматический TLS убирает одну повторяющуюся задачу, а staging часто выглядит почти так же, как production. Через несколько месяцев коллега всё ещё может открыть файл и понять, что куда ведёт.

nginx здесь тоже работает, но команды часто разбивают конфиг на несколько файлов, фрагментов и копий блоков. Вот тут и появляется дрейф. В staging один заголовок, в production другой, и никто ничего не замечает, пока логин не ломается или админка не начинает кэшировать то, что не должна.

Traefik в первый день ощущается удобно, потому что Docker labels идут вместе с каждым сервисом. Когда сайт, API и админка меняются вместе, это действительно может сократить настройку. Но через несколько месяцев правила маршрутизации могут спрятаться в нескольких Compose-файлах, и на простые вопросы уходит больше времени. Кто отвечает за TLS? Какой router добавляет middleware? Приходится смотреть labels вместо того, чтобы читать один конфиг.

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

Если вашей команде нужен минимум накладных расходов, Caddy обычно оказывается самым спокойным выбором. Если вам нужно очень точное поведение, nginx всё ещё оправдывает себя. Traefik имеет смысл там, где почти всё уже строится на Docker metadata.

Ошибки, которые съедают неделю

Команды часто ошибаются ещё до того, как пишут первый конфиг. Они выбирают инструмент с самым громким именем или тот, которым пользовался знакомый в более крупной компании, вместо более простого вопроса: что эта команда может читать, менять и чинить под давлением?

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

TLS — частый источник медленной боли. Кто-то включает автоматические сертификаты, потом позже добавляет ручные cert-файлы для одного домена из-за особого случая, а потом об этом забывает. Через месяц один hostname продлевается нормально, другой отдаёт старый сертификат, и команда теряет полдня, доказывая, что приложение здорово, хотя реальная проблема — в прокси.

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

Следующая ловушка — правила маршрутизации. С Traefik это случается особенно часто, но в любой системе может появиться та же проблема. Часть маршрутизации живёт в Docker labels, другая часть — в файле, а странный редирект спрятан в скрипте деплоя. Вскоре никто не может ответить на простой вопрос: «Почему /admin ведёт туда, а не сюда?»

Когда правила живут в трёх местах, люди перестают доверять конфигу. После этого они либо делают осторожные изменения слишком медленно, либо рискованные — слишком быстро. И то и другое дорого стоит.

План rollback звучит скучно ровно до тех пор, пока production-изменение не ломается. Без него команды начинают править живой конфиг, перезапускать контейнеры и гадать. С ним они могут вернуться к предыдущему состоянию за минуту и уже потом спокойно искать настоящую причину.

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

Быстрые проверки перед тем, как принять решение

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

Задайте себе несколько простых вопросов. Может ли коллега добавить новый hostname примерно за десять минут через pull request и без личных заметок? Если пользователи получают 502, сможет ли команда за несколько минут понять, проблема в прокси, приложении или сети? Можно ли восстановить всю схему ingress и TLS только из Git на чистой машине? Когда сертификат ломается, делают ли логи причину очевидной, или все начинают гадать?

Если на два и более вопроса ответ «нет», возможно, сам инструмент нормальный, а вот схема — нет.

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

Полезно сделать короткий dry run. Поднимите один сайт, один API и один admin-host на свежем сервере. Добавьте TLS, заставьте HTTPS, специально сломайте один upstream, а потом восстановите его. Замерьте каждый шаг. Если один инструмент добавляет по двадцать лишних минут каждый раз, когда вы его трогаете, эта цена быстро накапливается.

Потом запишите следующий шаг простыми словами. Возможно, это значит оставить nginx и перенести весь конфиг в Git. Возможно, заменить ручную работу с TLS на Caddy. Возможно, оставить Traefik, но ввести более строгий шаблон для labels и деплоя.

Если схема всё ещё кажется расплывчатой, второе мнение может сэкономить много уборки позже. Oleg Sotnikov at oleg.is помогает стартапам и небольшим компаниям с инфраструктурой, Fractional CTO работой и практической автоматизацией, поэтому короткий разбор ingress, TLS и схемы деплоя может поймать дрейф и проблемы отладки до того, как они превратятся в повторяющиеся сбои.