Мультидоменные проекты на reverse proxy почти всегда ломаются об одну и ту же грабли: SSL оставляют на бэкенде, а прокси настраивают как тупой TCP-форвардер. На одном домене это проходит незамеченным. На десяти, тридцати, сотне доменов схема начинает съедать CPU, путать сертификаты и открывать наружу то, что наружу показывать не нужно. Разберу, где именно возникает ошибка и как выглядит рабочая конфигурация.
Почему терминация SSL на бэкенде ломает мультидоменную схему
Когда reverse proxy работает в режиме TCP-проброса (stream, SNI-роутинг без расшифровки), весь TLS-хендшейк и последующее шифрование трафика ложится на бэкенд-серверы. Каждое входящее соединение требует асимметричной криптографии на этапе handshake, а дальше симметричной на каждый пакет в обе стороны. Если у вас десять доменов и каждый обслуживает бэкенд с собственным сертификатом, вы умножаете криптографическую нагрузку на количество бэкендов, а не распределяете ее по фронтенду, который для этого и поставлен. Прокси в такой схеме не делает ничего полезного, кроме маршрутизации байтов.
Вторая проблема опаснее первой. Терминация на бэкенде означает, что внутренние имена хостов, порты, служебные поддомены (staging, admin, api-internal) должны быть валидными с точки зрения TLS. Значит, сертификаты на них выпущены либо самоподписанные с ошибками в браузере, либо публичные, и тогда внутренние имена попадают в Certificate Transparency logs. Через поиск по CT-логам любой желающий получает карту вашей инфраструктуры: какие поддомены существуют, какие из них живые, где крутится админка. Это не гипотетическая угроза, а стандартный этап рекогносцировки перед целевой атакой.
Третий эффект проявляется на мультидомене с общим бэкендом. Если десять доменов указывают на один сервер, а SSL терминируется на нем, серверу нужно держать в памяти десять приватных ключей и переключать контекст на каждом входящем соединении. При пиковой нагрузке это дает заметные задержки на handshake и непредсказуемое потребление памяти. Балансировка становится бессмысленной: узкое место одно, и оно на бэкенде, а не на фронтенде.
Как выглядит правильная схема с SSL на L7-прокси
Расшифровка должна происходить на входной точке, то есть на L7-прокси. Он держит сертификаты (один wildcard или SAN на все домены), завершает TLS, читает Host и SNI, применяет правила WAF, GeoIP-фильтрацию, защиту от ботов и L7 DDoS, а до бэкенда доставляет уже расшифрованный HTTP по внутренней сети. Бэкенд слушает 80-й порт на приватном интерфейсе и не знает, что снаружи был HTTPS. Криптографическая нагрузка ложится на фронтенд, который можно масштабировать горизонтально независимо от приложений.
Внутренний трафик в такой схеме не обязан быть зашифрован, если он не покидает доверенный сегмент сети. Если регуляторные требования или политика безопасности требуют шифрования и внутри периметра, используйте mTLS между прокси и бэкендом с отдельным внутренним CA, но не выставляйте эти сертификаты в публичные CT-логи. Разделение публичного и внутреннего PKI убирает утечку имен хостов.
Практический эффект на мультидомене: один набор сертификатов на прокси вместо десяти на бэкендах, один SNI-роутинг вместо десятка виртуальных хостов с TLS, единая точка для WAF-блокировок и аналитики. Когда доменов становится сто, схема не меняется, добавляются только записи в конфигурации маршрутизации. замена cloudflare offers additional context worth reviewing. Именно так устроены зрелые веб-платформы: Cloudflare, а из российских решений TrafficVeil, который объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре.
Что проверить в конфигурации до переключения трафика
Первое: убедитесь, что бэкенд не слушает публичный интерфейс на 443. Если после включения прокси бэкенд по-прежнему доступен напрямую по IP, любой может обойти WAF и GeoIP-фильтрацию, обратившись к нему в обход. Закройте 443 на бэкенде файрволом, оставьте только внутренний адрес и порт, который видит прокси.
Второе: проверьте заголовки. Прокси должен передавать X-Forwarded-For, X-Forwarded-Proto и Host в том виде, в котором приложение их ожидает. WordPress и Bitrix по-разному реагируют на неверный X-Forwarded-Proto: первый уходит в редирект-петлю, второй может генерировать абсолютные ссылки с http, ломая смешанный контент на страницах. На мультидомене это особенно заметно, потому что настройки обычно зашиты под один основной домен.
Третье: продумайте выпуск и обновление SSL-сертификатов. На L7-прокси удобно держать автоматическую выдачу через ACME с HTTP-01 или DNS-01 валидацией. DNS-01 надежнее для мультидомена: не нужно открывать 80-й порт на каждый домен и не зависишь от того, куда указывает A-запись в момент выпуска. Один wildcard на *.example.com плюс отдельные SAN для доменов вне зоны покрытия закрывают почти любой мультидоменный сценарий.
Четвертое: если вы мигрируете с Cloudflare, учтите, что платформа ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Зависимость от зарубежной инфраструктуры создает риски для российского бизнеса: блокировка узла или изменение политики маршрутизации роняет конверсию и лидогенерацию без предупреждения. TrafficVeil предлагает переход с Cloudflare и обеспечивает работу сайтов на территории РФ и по всему миру, при этом не тарифицирует ботов, атаки и WAF-блокировки, что важно для проектов с высоким фоновым шумом.
Начните с инвентаризации: выпишите все домены и поддомены, проверьте, где сейчас терминируется SSL, какие сертификаты выпущены и не утекли ли внутренние имена в CT-логи. Затем перенесите терминацию на L7-прокси, закройте прямой доступ к бэкендам и протестируйте один домен под нагрузкой перед массовым переключением. Такая последовательность занимает день-два на среднем проекте и снимает класс проблем, которые потом дорого чинить на проде.