Обратный прокси на своём железе: Caddy, Traefik и цена умолчаний

Перед своими сервисами стоит не «самый быстрый» обратный прокси, а тот, чьи умолчания вы готовы терпеть три года. Именно умолчания, а не таблица возможностей, определяют, что произойдёт у вас в четверг вечером. Ниже разобрано, что проверяется по первоисточникам на 19 сентября 2026 года: кто владеет вашими сертификатами, что рвётся в момент перезагрузки конфигурации, чего не покажет сканер уязвимостей и сколько каждое из этих решений стоит в эксплуатации.

Сразу оговорюсь про жанр. Это не сравнение по пунктам и не рекомендация по умолчанию: в конце нет строки «берите вот это». Есть три вопроса, ответы на которые сужают выбор до одного варианта, и цена каждого ответа. Все версии, даты и номера уязвимостей здесь проверены по релизам, документации и бюллетеням проектов, ссылки в конце.

Половина таких установок решает задачу, которой нет

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

Этот слой лежит ниже и рядом с тем, что я разбирал про вход в кластер. Там контекст изменился радикально: ingress-nginx закрыт в марте 2026 года, а сам Ingress API объявлен замороженным. Показательно, что это признаёт уже и документация Traefik: начиная с версии 3.7.13 она прямо пишет о заморозке Ingress API. Но здесь речь о прокси вне кластера, на границе обычной инфраструктуры, где решения принимаются иначе.

И сразу о том, чего в обоих продуктах нет, потому что на этом строится половина разочарований. В стандартной сборке Caddy 39 директив и среди них нет ни кэша, ни ограничения частоты, ни межсетевого экрана уровня приложения, ни работы на четвёртом уровне. В открытой версии Traefik нет HTTP-кеширования, раздачи статики и того же межсетевого экрана. Если вы шли за этим, вы идёте не туда.

Выбор прокси, это выбор того, кто владеет вашими сертификатами

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

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

Traefik складывает всё в один файл acme.json и проверяет права на него: если выставлены биты для группы или для остальных, резолвер молча выпадает из списка, а процесс продолжает жить. Когда сертификат не выпустился, Traefik отдаёт самоподписанный TRAEFIK DEFAULT CERT, и для новых доменов это состояние держится до перезапуска. То есть у одного трафик идёт по недовыпущенному сертификату, а у другого сервис выглядит работающим, пишет в лог мало и отдаёт браузеру предупреждение.

Вы выбираете не прокси, а его умолчания

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

Что удивляет в Caddy:

• порядок проверок ACME случайный, а не фиксированный, поэтому воспроизвести чужой сценарий выпуска не получится;
• включение проверки через DNS отключает две остальные, и это не описка в документации, а поведение;
• резервный издатель ZeroSSL работает только если задан адрес электронной почты, иначе запасного пути просто нет;
• балансировка по умолчанию random, а не по кругу, как обычно предполагают;
• у reverse_proxy нет ни активных, ни пассивных проверок здоровья, а lb_retries равен нулю: мёртвый бэкенд будет получать запросы;
• таймаутов на чтение ответа нет вовсе, единственный заданный это dial_timeout в три секунды;
• входящие заголовки X-Forwarded-* игнорируются, и без trusted_proxies за внешней сетью доставки вы не увидите реальный адрес клиента;
• режим 0-RTT включён по умолчанию и конфликтует с сопоставлением по адресу клиента.

Что удивляет в Traefik:

• exposedByDefault равен true: провайдер публикует наружу все контейнеры, пока вы явно не скажете обратное;
• api.dashboard включается вместе с API, то есть панель приезжает как побочный эффект;
• writeTimeout выключен;
• у ограничителя частоты average равен нулю, и в этом состоянии он не ограничивает ничего, хотя в конфигурации выглядит включённым;
• все семь переключателей encodedCharacters по умолчанию разрешают проход опасных кодированных символов;
• список разрешённых адресов с параметром depth фильтрует по клиентскому X-Forwarded-For, а без ipv6Subnet обходится через IPv6.

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

Настоящий бенчмарк случается в момент перезагрузки конфигурации

Обратный прокси на периметре перезагружают часто: новый домен, новый сервис, новый сертификат. Именно в эту секунду и выясняется цена архитектуры, а не под синтетической нагрузкой. Четыре продукта дают четыре разные механики.

• Caddy поднимает новую конфигурацию целиком до остановки старой, поэтому обе какое-то время живут в памяти. Период ожидания по умолчанию бесконечный, но проксируемые потоки рвутся немедленно, потому что stream_close_delay равен нулю. Перезагрузка возможна только через административный API, SIGHUP игнорируется, а сама перезагрузка обрывает незавершённые транзакции ACME.
• Traefik дросселирует события провайдеров двумя секундами, и это дёшево. Но смена установочной конфигурации требует полного перезапуска с graceTimeOut в десять секунд.
• nginx порождает новое поколение рабочих процессов, а worker_shutdown_timeout по умолчанию не задан вовсе: старые процессы живут столько, сколько живут их соединения.
• HAProxy единственный документирует цену числом: около одного потерянного соединения на десять тысяч новых в секунду.

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

Сертификат стал расходником, и ваш прокси обязан это знать

Отраслевые часы уже тикают, и это меняет требования к автоматике. Максимальный срок жизни сертификата: 200 дней с 15 марта 2026 года, 100 дней с 15 марта 2027 года, 47 дней с 15 марта 2029 года. Let’s Encrypt идёт впереди графика и дойдёт до 45 дней к февралю 2028 года.

Вокруг этого изменилось ещё три вещи, и все они ломают привычки. Писем об истечении больше не присылают с 4 июня 2025 года: следить за сроками теперь исключительно ваша работа. Респондеры OCSP выключены 6 августа 2025 года, поэтому блоки ssl_stapling, заботливо скопированные из статей 2019 по 2023 год, сегодня мертвы. Проверка с нескольких точек стала обязательной, а с 15 марта 2026 года обязательна и проверка DNSSEC.

Дальше начинается цена конкретной реализации. Caddy продлевает по последней трети реального срока и поддерживает механизм подсказок от удостоверяющего центра начиная с версии 2.8, то есть подстраивается под расписание центра. Traefik считает по жёсткой таблице от certificatesDuration, этот механизм не поддерживает до сих пор, по умолчанию запрашивает RSA-4096 и продлевает даже те сертификаты, которые никто не использует.

Отсюда самая дорогая ловушка раздела. Включить в Traefik профиль коротких сертификатов и не тронуть certificatesDuration означает сделать условие продления истинным на каждом суточном проходе. Продление будет запускаться снова и снова, пока вы не упрётесь в лимит на повторный выпуск для одинакового набора имён. Это следствие из кода и опубликованных лимитов, а не наблюдение из эксплуатации, и проверять его на рабочем контуре я не советую.

Две реплики, это водораздел

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

Документация Traefik говорит прямым текстом: несколько экземпляров с включённым Let’s Encrypt запускать нельзя. И отправляет либо в коммерческую версию, либо к внешнему контроллеру сертификатов. Формулировка там, к слову, до сих пор говорит про Traefik 2.0, хотя актуальная ветка 3.7, и это само по себе характеристика того, как давно в этот угол не заглядывали.

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

Панель управления прокси, это дверь без замка

Административный API Caddy включён по умолчанию на localhost:2019 и не имеет аутентификации вообще. Вся защита держится на привязке к интерфейсу. Через него выгружается и подменяется вся конфигурация и останавливается процесс, а выключить его совсем нельзя без потери команды caddy reload. Уязвимость CVE-2026-27589 была ровно про то, что проверка источника запроса срабатывала не во всех случаях. Удалённое администрирование в проекте помечено экспериментальным, требует взаимной аутентификации, и обе майские дыры 2026 года пришлись именно на контроль доступа к нему.

У Traefik та же дверь выглядит иначе: api.insecure поднимает неаутентифицированные API и панель на порту 8080 по всем интерфейсам. Документация сама не рекомендует включать это в продакшне, но параметр никуда не делся. А автообнаружение контейнеров покупается монтированием сокета демона контейнеров внутрь процесса, который смотрит в интернет. Это доступ, эквивалентный правам суперпользователя на хосте, и режим «только чтение» защитой здесь не является.

Справедливости ради, класс этот не про молодые проекты: в nginx Control API из версии 1.31.5 тоже поставляется без аутентификации.

Прокси рассказывает бэкенду неправду, и это целый класс дефектов

Прокси сообщает приложению две вещи: какой путь запросили и кто этот клиент. Врать он умеет в обеих, и это не единичные ошибки, а повторяющийся класс с плотной историей исправлений.

Первое: авторизация принимается до переписывания пути. За 83 дня, с 24 апреля по 16 июля 2026 года, Traefik починил четыре разных переписывателя пути. У Caddy тот же класс в другом виде: нормализация регистра и escape-последовательностей в сопоставителях, CVE-2026-27587.

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

Практический вывод из этого не тот, который напрашивается. Чинить надо в первую очередь бэкенд: все обходы через путь работают только против приложения, которое нормализует путь самостоятельно и доверяет нормализованному. Модель угроз Traefik это формулирует честно: доверие решается один раз, на точке входа. Значит и проверять надо точку входа, а не надеяться, что следующий патч закроет тему.

HTTP/3 сегодня самое дырявое место периметра, и у Caddy он включён по умолчанию

Caddy по умолчанию открывает UDP-сокет на 443, то есть HTTP/3 вы получаете, не принимая решения. За 2026 год девять бюллетеней безопасности Traefik связаны с HTTP/3 или QUIC. Среди них единственный сентябрьский критический CVE-2026-88007 с оценкой 9.1, и здесь надо быть честным: у него три обязательных предусловия, то есть «все горим» это неверное прочтение. У nginx свежая CVE-2026-90439 закрыта 15 сентября 2026 года, за четыре дня до того, как я это пишу.

Выгода при этом не гарантирована. На быстрых каналах QUIC проигрывает связке TCP и HTTP/2 вплоть до 45,2 процента: это измерение не моё, но методика у него опубликована, в отличие от большинства цифр в обзорах. Отсюда решение, которое я считаю правильным по умолчанию: если измеренной выгоды от HTTP/3 у вас нет, выключите его и снимите с периметра целый пласт свежих дефектов.

Один проект молчит 108 дней, другой патчит каждые одиннадцать, и оба ответа плохие

Это самый сильный контраст всей подборки, и он про эксплуатацию, а не про код.

Caddy молчит. Последний релиз v2.11.4 вышел 3 июня 2026 года: на 19 сентября это 108 дней без выпуска при сотне коммитов в основной ветке и четырёх слияниях из приватного форка по безопасности. Веха v2.11.5 существует без даты. Есть опубликованное уведомление GHSA-6365-7ppr-5r92, которое ссылается на исправление в версии v2.11.5, а её не существует. Исправление гонки в forward_auth лежало невыпущенным 71 день.

Traefik не молчит совсем. Двенадцать опубликованных патчей ветки 3.7 за 122 дня, девять из них за 86 дней со средним интервалом около одиннадцати дней. Это значит, что обновление прокси превращается в регулярную операцию раз в две недели, и её надо закладывать в регламент, а не в свободное время.

К этому добавляются сроки жизни веток. У Traefik минорная ветка живёт шесть месяцев: активная поддержка 3.7 истекает около 5 ноября 2026 года, а поддержка безопасности ветки 2.11 закончилась 7 сентября 2026 года, за двенадцать дней до написания этого текста. В тот же день вышли пять бюллетеней. Отдельно стоит знать, что патчи безопасности Caddy бывают ломающими, и проект честно предупреждает об этом прямо в релизе.

Ни один из двух ответов не хороший. Молчание означает, что исправления есть, но до вас не доехали. Высокий темп означает, что у вас появилась постоянная работа. Выбирать придётся между этими двумя, а не между «спокойно» и «беспокойно».

Ваш сканер уязвимостей не покажет часть дыр этих прокси

Счёт бюллетеней врёт в обе стороны, и это стоит уметь читать. За 2026 год у Traefik 48 репозиторных бюллетеней против 17 у Caddy. Но профиль тяжести важнее числа: у Traefik 2 критических и 25 высоких, у Caddy за тот же год ни одного критического.

Теперь поправка в пользу Traefik, без которой сравнение нечестное. Двадцать шесть из сорока восьми записей относятся к провайдерам Kubernetes и к прокси на своём железе вне кластера не адресованы вовсе. Плюс Traefik публикует ещё и уязвимости зависимостей, чего Caddy не делает: часть разрыва это просто разная политика раскрытия.

А вот действительно неприятное. Семь бюллетеней Traefik и три у Caddy вообще не имеют номера CVE. Критический обход digestAuth с оценкой 9.3 отсутствует в глобальной базе и привязан только к диапазонам коммитов: ни govulncheck, ни Dependabot, ни Trivy его вам не покажут. Две оценки одного и того же дефекта при этом расходятся внутри самого GitHub. Вывод для того, кто строит процесс: зелёный отчёт сканера означает, что сканер ничего не нашёл, а не что периметр закрыт.

Спор идёт не между двумя проектами: nginx и HAProxy научились тому, ради чего их меняли

Главный довод в пользу Caddy и Traefik звучал так: они сами выпускают сертификаты. За последний год этот довод перестал быть уникальным.

У nginx с 2025 года есть родной модуль ACME, и он поддерживает и подсказки от удостоверяющего центра, и профили выпуска. То есть по этому механизму отстающий не «все против Caddy», а один Traefik из трёх. Ограничения честные: нет проверки через DNS, значит нет сертификатов с подстановочным знаком; зона на 256 килобайт вмещает примерно пятьдесят сертификатов; при выключенном state_path всё теряется при перезапуске.

HAProxy добавил ACME в версии 3.2 с одной только проверкой по HTTP, проверку через DNS в 3.3, а сохраняемый вариант и профили в 3.4, всё ещё под флагом экспериментальных директив. Зато он единственный умеет транзакционно подменить сертификат на лету с атомарным откатом и даёт длительную поддержку на пять лет для чётных веток. И ещё одна мелочь, которая тянет за собой много споров: довод про намертво закешированный адрес контейнера в nginx устарел 26 ноября 2024 года.

Бенчмарк измеряет не то, что у вас болит

Цифры запросов в секунду и потребления памяти из обзоров 2026 года расходятся между собой в двенадцать раз по одной только памяти Traefik. Там, где методика вообще описана, она сводится к показаниям docker stats без инструмента нагрузки, без версий и без конфигураций. Такие числа нельзя ни опровергнуть, ни воспроизвести, поэтому я их здесь не привожу.

Куда интереснее то, что в обзорах не появляется вовсе. Самая крупная реальная регрессия производительности последних лет, минус 56 процентов на рукопожатиях у OpenSSL 3.x, это свойство библиотеки. Caddy и Traefik к ней невосприимчивы просто потому, что линкуются с реализацией TLS из состава Go. Обратная сторона той же медали: аппаратное ускорение TLS на уровне ядра в Go принято как предложение ещё в 2021 году и на сентябрь 2026 так и не реализовано, тогда как nginx умеет отдавать файлы через ядро с 2021 года, а HAProxy получил эту возможность в версии 3.3.

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

Я выбираю тремя вопросами, а не таблицей сравнения

Вопрос первый: нужен ли сертификат с подстановочным знаком и проверка через DNS? Если да, Traefik берёт библиотеку lego с двумя с лишним сотнями провайдеров DNS прямо из коробки, а Caddy требует нестандартной сборки через xcaddy. Цена у второго варианта конкретная: плагины компилируются внутрь бинарника, поэтому обновление версии перестаёт быть операцией в одну команду, а caddy upgrade не перезапускает сервер.

Вопрос второй: будет ли вторая реплика? Если да, вариантов ровно два: Caddy с общим хранилищем на стороннем модуле, который вы сопровождаете сами, либо вынос сертификатов из прокси наружу, в отдельный контроллер или в собственный сервер ACME. Внутренний удостоверяющий центр умеет и сам Caddy через acme_server, но с важной оговоркой из следующего раздела.

Вопрос третий: кто и как быстро накатывает патчи? Если обновление у вас стоит согласования, темп Traefik в одиннадцать дней вам не по карману. Если обновление дешёвое, но вас пугает проект, который молчит три с лишним месяца, дорого обойдётся уже Caddy. Это вопрос про вашу команду, а не про код, и он решает чаще двух предыдущих.

Рекомендации по умолчанию здесь нет намеренно. Три ответа дают три разных выбора, и любой из них защитим, если названа цена.

Чего я сознательно не делаю

• Не монтирую сокет демона контейнеров в прокси ради автообнаружения. Это доступ уровня суперпользователя, отданный процессу на периметре; режим «только чтение» мерой защиты не является, а exposedByDefault по умолчанию опубликует всё.
• Не включаю панель и API на периметре. Неаутентифицированный API и панель на всех интерфейсах это не отладка, это открытая дверь.
• Не выношу административный API Caddy за пределы локального интерфейса. Аутентификации у него нет вообще, удалённый режим экспериментален и уже дважды за 2026 год получал обходы контроля доступа.
• Не держу HTTP/3 включённым без измеренной выгоды. У Caddy он открыт по умолчанию, и именно в этом пути лежит большая часть тяжёлых дефектов года.
• Не включаю выпуск сертификатов по требованию без ограничений. Caddy в этом случае не откажется стартовать, а только напишет предупреждение, и эндпоинт разрешений окажется прямо в пути рукопожатия, без кэша и с таймаутом в десять секунд.
• Не ставлю внутренний удостоверяющий центр на тот же хост, который смотрит в интернет. Корневой закрытый ключ у Caddy лежит обычным PEM-файлом рядом, а вынести ключ в аппаратный модуль умеет step-ca, а не прокси.
• Не копирую блоки ssl_stapling из старых статей. Для сертификатов Let’s Encrypt они мертвы с 6 августа 2025 года.
• Не гонюсь за свежей минорной веткой ради функций. Шесть месяцев жизни минора означают, что промах веткой стоит дороже, чем отказ от новой возможности.

Стек

Что именно проверялось и в каких версиях на 19 сентября 2026 года.

• Caddy: v2.11.4 от 3 июня 2026 года, собран на Go 1.25.1. В Debian trixie штатный пакет это 2.6.2, в backports 2.11.2.
• Traefik: v3.7.13 от 4 сентября 2026 года, Go 1.26.0, две версии lego одновременно. Пакета в Debian нет вовсе.
• nginx: 1.31.6 от 15 сентября 2026 года, с родным модулем ACME.
• HAProxy: 3.4 LTS от 3 июня 2026 года, поддержка до второго квартала 2031 года.
• Let’s Encrypt: профили classic, tlsserver и shortlived.
• step-ca: внутренний удостоверяющий центр, когда корневой ключ нужно держать в аппаратном модуле.

Почему это важно тому, кто платит

Выбор обратного прокси это обязательство по сопровождению на годы, и оно переводится в часы. Срок жизни минорной ветки, темп выхода патчей и наличие длительной поддержки прямо определяют, сколько времени в квартал уходит на обновления периметра. Разница между «раз в полгода» и «раз в две недели» это разница в статье расходов, а не в удобстве.

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

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

Частые вопросы

Что брать, если у меня один сервер и десяток сервисов?

Caddy, если вам хватает проверок по HTTP и через TLS: он сам выпустит и продлит сертификаты и продлевает по реальному сроку, а не по числу из конфигурации. Цена решения: административный API включён по умолчанию без аутентификации, в штатном юните systemd нет директивы перезапуска, а для проверки через DNS придётся собирать нестандартный бинарник. Если нужен сертификат с подстановочным знаком, выбор смещается к Traefik или к внешнему клиенту ACME.

Правда ли, что Traefik нельзя запускать в двух экземплярах с Let’s Encrypt?

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

Надо ли уже сейчас переходить на короткие сертификаты?

Переходить не надо, надо убедиться, что ваша автоматика переживёт переход. С 15 марта 2026 года максимальный срок 200 дней, с 15 марта 2027 года будет 100, а Let’s Encrypt дойдёт до 45 дней к февралю 2028 года. Отдельная ловушка: включить в Traefik профиль коротких сертификатов и не тронуть certificatesDuration означает запускать продление на каждом суточном проходе и упереться в лимит на одинаковый набор имён.

Насколько страшно, что у Traefik 48 бюллетеней безопасности за 2026 год?

Число само по себе говорит мало: 26 из 48 записей относятся к провайдерам Kubernetes и к прокси вне кластера не адресованы, а Traefik публикует ещё и уязвимости зависимостей, чего Caddy не делает. Смотреть надо на тяжесть и на темп: у Traefik 2 критических и 25 высоких, у Caddy за тот же год ни одного критического при 17 записях. И на другую чашу весов: Caddy на 19 сентября 2026 года не выпускал релизов 108 дней, а одно его исправление лежало невыпущенным 71 день.

Можно ли оставить административный API Caddy включённым?

Он и так включён по умолчанию на localhost:2019 и не имеет никакой аутентификации, а выключить его совсем означает потерять команду caddy reload. Через него выгружается и подменяется вся конфигурация и останавливается процесс, а CVE-2026-27589 был ровно про то, что проверка источника запроса срабатывала не всегда. Разумный минимум: не выносить его с локального интерфейса, включить проверку источника и не публиковать порт 2019 ни в какой сети.

Стоит ли монтировать сокет демона контейнеров ради автообнаружения?

Это доступ, эквивалентный правам суперпользователя, отданный процессу, который смотрит в интернет, и режим «только чтение» защитой не является. Добавьте к этому exposedByDefault равный true: без явного отключения провайдер публикует все контейнеры. Если автообнаружение действительно нужно, ставьте между прокси и демоном отдельный прокси сокета с фильтром запросов и выключайте exposedByDefault.

nginx же не умеет сертификаты сам, зачем он в этом сравнении?

Уже умеет: родной модуль ACME доступен с 2025 года и поддерживает и подсказки от удостоверяющего центра, и профили выпуска, то есть по этому механизму отстаёт как раз Traefik. Ограничения честные: нет проверки через DNS, значит нет сертификатов с подстановочным знаком, зона по умолчанию вмещает около пятидесяти сертификатов, а при выключенном state_path ключи теряются при перезапуске. Главный аргумент в пользу Caddy и Traefik за последний год перестал быть уникальным.

Источники

• Релизы Caddy и бюллетени безопасности Caddy.
• Автоматический HTTPS в Caddy, директива reverse_proxy и административный API.
• Релизы Traefik и бюллетени безопасности Traefik.
• Сроки поддержки версий Traefik и документация по резолверам ACME.
• CHANGES nginx и модуль ACME для nginx.
• Ветки и сроки поддержки HAProxy.
• Профили выпуска Let’s Encrypt, лимиты и выключение OCSP.
• График сокращения сроков жизни сертификатов CA/Browser Forum.
• Заявление комитетов Kubernetes об ingress-nginx.

Нужна консультация?

Если хочется разобрать конкретный периметр, а не читать про чужой, запишитесь на разговор. Посмотрим, что у вас стоит на границе, кто владеет сертификатами, какой регламент обновления и что произойдёт при следующей перезагрузке конфигурации. Смежные материалы: кластер Kubernetes на своём железе, кластер Proxmox как код, SIEM на открытом ядре.