Зачем вообще выбирать reverse proxy на VDS
Reverse proxy на VDS почти всегда становится «единой точкой входа» для нескольких сайтов и сервисов: принимает 80/443, терминирует TLS, маршрутизирует по доменам/путям, прокидывает WebSocket/gRPC и унифицирует заголовки (X-Forwarded-For, X-Forwarded-Proto).
Когда сервисов больше одного, выбор прокси влияет на эксплуатацию: где живёт конфигурация (файлы, labels, база), как вы откатываете изменения, как быстро находите причину 502 и что происходит при переезде на другую VDS.
Ниже — сравнение Traefik, Caddy и Nginx Proxy Manager (NPM) именно с точки зрения продовой рутины: Docker ingress, автоматический выпуск/продление сертификатов по ACME, много доменов и типовые «грабли».
Быстрый портрет: философия и «где правда» о маршрутах
Traefik
Traefik — reverse proxy и ingress-контроллер с сильной интеграцией с Docker/Swarm/Kubernetes. Маршруты описываются метаданными (labels/аннотации), а Traefik сам подхватывает изменения без ручных рестартов и правок центрального конфига.
Сильные стороны: удобный Docker ingress, богатая маршрутизация, middlewares, понятное разделение static/dynamic конфигурации. Слабые: порог входа и риск превратить docker-compose.yml в «конфиг прокси на 200 строк».
Caddy
Caddy — минималистичный веб-сервер и reverse proxy, известный Auto HTTPS: выпуск/обновление сертификатов через ACME, OCSP stapling и безопасные TLS-настройки «по умолчанию». Конфигурация (Caddyfile) обычно короткая и читаемая.
Сильные стороны: быстрый путь к продовому HTTPS без лишних компонентов. Слабые: автодискавери маршрутов из Docker «не родной», сложные ingress-политики иногда удобнее делать в Traefik.
Nginx Proxy Manager
NPM — это Nginx с веб-панелью, где прокси-хосты и сертификаты управляются кликами, а состояние хранится в базе (часто SQLite/MariaDB) и volume. Хорош для небольших установок и команд, которым важен UI.
Слабое место — операционная модель: часть правок живёт в БД/панели, часть — в шаблонах Nginx, а нестандартные кейсы упираются в «Custom Nginx Configuration», постепенно превращая NPM в ручной Nginx с дополнительным слоем абстракции.
Выбор reverse proxy — это не «кто быстрее», а «где будет жить конфигурация и как вы её будете менять и отлаживать в 3 часа ночи».
Критерий №1: automatic SSL и ACME в реальной жизни
Все трое умеют automatic SSL через ACME, но важны детали: что считается «источником правды» о сертификатах, как устроено хранилище и что будет при сбое/переезде.
Traefik: ACME как часть пайплайна маршрутизации
В Traefik вы задаёте certificate resolver, а затем привязываете его к роутерам. Плюс — выпуск сертификата становится частью деплоя: подняли контейнер с нужными labels, прокси сам получит TLS.
acme.json— критический state. Ограничьте права доступа и обязательно бэкапьте, иначе при потере можно упереться в лимиты ACME.- HTTP-01 требует владения портом 80 и доступности домена снаружи.
- DNS-01 удобен для wildcard, но требует API к DNS и аккуратной работы с секретами.
Caddy: Auto HTTPS «по умолчанию», но следите за портами
В Caddy часто достаточно указать домен — и он сам инициирует выпуск сертификата. Это удобно для небольшого числа доменов, когда хочется «меньше движущихся частей».
- Порты 80/443 должны быть свободны и проброшены до Caddy.
- DNS домена должен указывать на IP вашей VDS (частая причина «почему не выпустился сертификат»).
- Wildcard обычно означает DNS-01 (часто с провайдерскими модулями), это не «автомагия» без подготовки.
Nginx Proxy Manager: удобно через UI, но берегите состояние
NPM выдаёт и продлевает сертификаты через интерфейс. Для небольших проектов это самый быстрый путь к рабочему HTTPS.
- Бэкап должен включать и БД, и volume с данными. Потеря state почти всегда означает перевыпуск и пересоздание прокси-хостов.
- При миграции на другую VDS переносите весь state целиком, иначе получите «всё было настроено, но ничего не работает».
- Активное использование custom-конфига усложняет обновления: меняются шаблоны/дефолты, и поведение может «поплыть».
Если планируете не только Let’s Encrypt, но и сертификаты с расширенной валидацией или под требования комплаенса, заранее продумайте жизненный цикл ключей и хранение секретов; в таком случае пригодятся коммерческие SSL-сертификаты.
Критерий №2: Docker ingress и модель конфигурации
Под «Docker ingress» обычно подразумевают: (1) проксировать контейнеры на одной машине и (2) менять маршруты вместе с деплоем. Во втором случае ключевое — где живёт конфиг и кто его изменяет.
Traefik: маршруты как часть деплоя
Traefik ближе всего к идее «маршруты = декларация сервиса». В выкатывании контейнера вы сразу описываете домены/пути/мидлвари, а Traefik подхватывает изменения автоматически.
- Labels легко разрастаются; помогает вынос общих middlewares в динамический конфиг и единые шаблоны именования.
- Разделяйте зоны ответственности: static-конфиг Traefik, dynamic-маршруты, секреты (DNS API токены, пароли basic auth).
- Типовая ошибка — неверно заданный порт сервиса (Traefik проксирует не туда и даёт 502).
Caddy: дружелюбен к Docker, но без «родного» автодискавери
Caddy отлично работает в контейнере, но чаще всего «истина» остаётся в файле конфигурации. Практичный подход: хранить Caddyfile в Git, генерировать его на CI/CD и делать reload при изменениях.
Если нужно, чтобы каждый сервис сам объявлял домен через labels, придётся добавлять генераторы/обвязку. Это решаемо, но усложняет архитектуру и снижает ценность «простого Caddy».
Nginx Proxy Manager: удобен для ручного администрирования, слабее для GitOps
NPM отлично подходит для сценария «поднял сервис — добавил домен в UI — включил SSL». Но модель «накликали в панели» плохо дружит с GitOps: аудит и откат изменений превращаются в ручной процесс.
Если сопровождать будут разные люди (админы «универсалы», разработчики), NPM может быть выигрышным именно за счёт UI, но тогда особенно важны регламенты бэкапа и доступов.
Критерий №3: отладка и наблюдаемость (502/404/SSL)
На VDS в проде важнее всего не «завести один раз», а быстро локализовать проблему: это DNS/ACME, маршрутизация, сеть Docker, upstream или таймауты.
Traefik
Плюсы: структурированные логи и ясная модель «router → service → middleware». Минусы: больше сущностей, значит больше мест для логической ошибки. Dashboard полезен для диагностики, но в проде его обязательно закрывайте (не публикуйте в интернет как есть).
Типовые причины 502/404: неверное правило матчинга, неправильный порт сервиса, конфликт entrypoints, отсутствие нужной Docker-сети, включённый exposedByDefault без явного контроля.
Caddy
Чаще всего помогает простота: конфиг небольшой, проблему видно глазами. Для TLS-ошибок важно понимать, какой challenge используется и доступен ли домен снаружи (и свободны ли 80/443). Для 502 обычно виноваты upstream и привязка бэкенда только к localhost.
Nginx Proxy Manager
Когда «непонятно почему», вспоминайте: под капотом Nginx. Смотрите access/error логи, проверяйте upstream’ы, заголовки и лимиты. Нестандартные проблемы часто возникают из-за конфликта настроек, выставленных в UI, и строк в custom-конфиге.
Критерий №4: безопасность по умолчанию и контроль доступа
Reverse proxy часто становится первой линией обороны: ограничение доступа к админкам, allowlist по IP, basic auth, security headers, запрет лишних методов, лимиты запросов.
- Traefik: middlewares (allowlist, basicAuth, headers, rateLimit). Важно не раскрыть API/dashboard наружу.
- Caddy: безопасные TLS-дефолты и меньше «ручек», где можно ошибиться. Для сложных политик нужна аккуратная конфигурация матчеров.
- NPM: базовые настройки делаются быстро, но серьёзная политика упирается в детали Nginx. Плюс веб-панель — дополнительная поверхность атаки: ограничивайте доступ и обновляйтесь.
Если вы строите жёсткую модель сегментации (разные сети контейнеров, фильтрация входящих/исходящих), пригодится материал про фаервол для Docker: iptables и nftables без сюрпризов.
Для предсказуемого ACME и ingress в проде важно иметь полный контроль над портами 80/443, сетями и фаерволом; на практике это проще реализовать на отдельной VDS, где reverse proxy будет «главным» входным компонентом.
Производительность: что реально важно на VDS
В большинстве проектов узкое место не в прокси, а в приложении, базе, сети или диске. Но нюансы есть:
- Nginx традиционно силён в раздаче статики и проксировании; NPM наследует это, но не всегда даёт тонкий контроль под специфические кейсы.
- Caddy уверенно держит типовую продовую нагрузку и часто выигрывает временем внедрения.
- Traefik хорош в ingress-функциональности; на больших RPS важны метрики, таймауты и аккуратная модель сервисов, но для типичной VDS производительности хватает.
Три практических сценария выбора
1) «Один сервер, несколько контейнеров, хочу чтобы всё поднималось само»
Чаще всего выигрывает Traefik: маршруты и TLS становятся частью деплоя через labels, без ручных правок центрального конфига.
2) «Пара сайтов и API, хочу минимальный конфиг и HTTPS без боли»
Обычно лучший старт — Caddy: короткий конфиг и Auto HTTPS «из коробки», при условии что не нужна автодискавери-модель Docker ingress.
3) «Нужна панель, чтобы быстро добавлять домены и сертификаты»
Nginx Proxy Manager закрывает потребность «быстро и визуально». Сразу закладывайте бэкап state и правила доступа к панели.
Типовые ошибки и как их избежать
Конфликт портов 80/443
ACME почти всегда подразумевает владение 80/443. Если на VDS уже занят порт другим веб-сервером/панелью, выпуск/продление сертификатов будет ломаться или прокси не стартует. Сразу определите, кто «главный» на 80/443, а всё остальное прячьте за ним.
Потеря хранилища сертификатов и лимиты ACME
Traefik (acme.json), Caddy (storage), NPM (БД + volume) — это state. Потеряли state при краше или переезде — получите массовый перевыпуск и риск упереться в лимиты. Полезно заранее понимать механику лимитов и планировать миграции; см. также лимиты Let’s Encrypt и автоматизацию SAN.
«Случайный» доступ к админкам
Dashboard’ы, панели и внутренние сервисы нельзя публиковать без защиты. Минимум: allowlist по IP, basic auth, отдельный домен и отдельные правила. Если сервис не должен быть доступен из интернета — не проксируйте его наружу.
Неправильные заголовки и протоколы
WebSocket, gRPC, long polling, большие загрузки требуют корректных заголовков и таймаутов. Проверяйте, что прокси передаёт X-Forwarded-For и X-Forwarded-Proto, и что приложение их корректно интерпретирует.
Мини-чеклист перед выбором
Конфигурация должна жить в Git (GitOps) или допустимы изменения через UI?
Нужен ли настоящий Docker ingress с автодискавери маршрутов?
Сколько доменов и как часто они меняются?
Нужны ли wildcard-сертификаты (значит, вероятно DNS-01) и есть ли API у DNS-провайдера?
Кто будет сопровождать: DevOps, разработчики, админ-универсал?
Вывод: что выбрать и почему
Traefik выбирайте, когда reverse proxy — часть деплоя контейнеров и нужен полноценный Docker ingress с автоматической маршрутизацией и политиками через middlewares.
Caddy оптимален, когда важны простота, скорость внедрения и надёжный ACME/TLS «по умолчанию», а конфигурация файлом вас устраивает.
Nginx Proxy Manager подходит, когда UI — явное требование процесса (быстро добавлять домены/сертификаты), и вы готовы дисциплинировать эксплуатацию: бэкап state, контроль доступов и правила изменений.
