Domain Fronting

Domain fronting - это приём в TLS/HTTPS, при котором в одном запросе используются два разных доменных имени: одно видно сетевому наблюдателю, второе скрыто. Видимое имя - это TLS SNI, которое DPI, инспектирующий TLS прокси-сервер или обычные блокировки по SNI читают в открытом виде. Скрытое имя - это HTTP-заголовок Host: внутри зашифрованного туннеля, который видит только конечная CDN.

Техника работает, когда CDN размещает множество доменов на одном TLS-терминаторе и маршрутизирует входящие запросы по внутреннему заголовку Host:, а не по внешнему SNI. В этом случае клиент может отправить:

ClientHello: SNI = innocuous.example.com
(TLS handshake)
GET /path HTTP/1.1
Host: actual-target.example.com

Наблюдатель на маршруте видит innocuous.example.com (который разрешён) и пропускает трафик. CDN получает оба имени, игнорирует SNI при маршрутизации и отдаёт actual-target.example.com.

Почему это работает (когда работает)

Такие CDN, как Cloudflare, Fastly, Akamai и edge-инфраструктура Google, раньше по умолчанию маршрутизировали трафик по Host:, потому что это было проще: несколько клиентов используют один wildcard-сертификат и общий внешний IP, поэтому брать Host: в качестве ключа маршрутизации естественно. Любой, кто мог разместить свой ресурс на CDN, получал фронтинг даром как побочный эффект.

Исторически чаще всего в качестве прикрытия использовались *.cloudfront.net (AWS), *.appspot.com и script.google.com (Google), а также *.azureedge.net (Microsoft). Через них проходит так много легитимного трафика, что их блокировка ломает слишком большую часть интернета, чтобы быть политически приемлемой. Поэтому цензор, не способный отличить замаскированный трафик от обычного, вынужден пропускать всё.

Почему это почти перестало работать

В период с 2018 по 2020 год Google, AWS, Cloudflare и Azure объявили о проверке соответствия SNI и Host: внутренний Host: должен совпадать с внешним SNI, иначе запрос отклоняется на границе сети. Причиной стало в основном внешнее давление - Россия и другие страны начали блокировать популярные домены прикрытия, нанося сопутствующий ущерб, поэтому CDN предпочли убрать эту возможность, чтобы не оставаться точкой удара.

Реализация ограничений различается:

Google. Блокирует несовпадения на большинстве сервисов (App Engine, Firebase и др.), но некоторые конечные точки Google всё ещё принимают несовпадающие SNI/Host, если запрос завершается на инфраструктуре под управлением Google. script.google.com (Apps Script) - известный актуальный пример, поэтому такие инструменты, как masterhttprelayvpn, используют именно его.
Cloudflare. Проверяет совпадение на платных тарифах; на бесплатном тарифе исторически были лазейки, которыми пользовались сторонние сервисы. Фронтинг через Worker на собственной зоне Cloudflare всё ещё работает в том смысле, что внешний SNI и внутренний Host могут указывать на Cloudflare, просто на разные пути маршрутизации.
Fastly, CloudFront. Обе платформы ввели строгую проверку.

Так что классический domain fronting в духе "использовать сертификат Facebook для связи с заблокированным эндпоинтом Telegram" в основном мёртв. То, что осталось, работает в более узких рамках:

Фронтинг внутри одной CDN. Разместить собственный релей на той же CDN, где находится сервис с высокой репутацией, и рассчитывать на то, что цензор не сможет отличить ваш TLS-трафик от их трафика. Внешний SNI остаётся вашим доменом, но на уровне IP и JA3 он выглядит точно так же, как доверенный сервис.
Фронтинг через Google Apps Script. Особенность бессерверных сред Google, где маршрутизация для некоторых точек входа всё ещё учитывает внутренний Host. Именно эту лазейку использует masterhttprelayvpn.
Скрытие домена через ECH. Encrypted Client Hello (RFC 9746) шифрует сам SNI. Другой механизм, но похожий эффект: цензор не видит настоящее имя целевого хоста. По состоянию на 2026 год развёртывание лишь частичное - Cloudflare поддерживает его сквозным образом, а браузеры поставляют за флагами.

Этические вопросы и компромиссы

Domain fronting - технология двойного назначения: её используют активисты, журналисты и жители стран с цензурой, но также вредоносное ПО и фишинговые наборы, маскирующие C2-трафик под легитимный трафик CDN. Переход CDN к запрету фронтинга отчасти был вызван желанием упростить борьбу со злоупотреблениями: позицию "мы не поддерживаем фронтинг" защищать проще, чем "мы поддерживаем фронтинг только для хороших людей".

Практические выводы для пользователей:

Не стоит строить долгосрочную инфраструктуру на domain fronting. Такие возможности обычно закрывают после громких прецедентов. Стоит исходить из того, что конкретный трюк перестанет работать через 6-24 месяца.
Аутентификация по общему секрету важнее самого фронтинга. Если на релее нет аутентификации или она слабая, прикрытие становится просто декорацией - цензору незачем взламывать маскировку, если релей можно использовать напрямую.
Главный враг - снятие отпечатков (fingerprinting). Даже работающее прикрытие не скроет фингерпринт JA3/JA4 клиента, временные паттерны или распределение размеров пакетов. Продвинутому DPI не нужно читать заголовок Host, чтобы распознать замаскированный трафик.

Связанные страницы

masterhttprelayvpn - использует Google Apps Script как актуальное работающее прикрытие (Python)
masterhttprelayvpn-rust - тот же подход, порт на Rust с десктопным интерфейсом и поддержкой Android
serverless-relay-transport - более широкий паттерн, где бэкендом релея выступает бессерверная функция (а не просто маршрут в CDN)
xray-tutorial, vless-subscription-format - экосистема VLESS, другой подход (исходящие соединения на нестандартных портах/доменах, TLS с маскировкой под реальный сайт)
store-now-decrypt-later - косвенно связано: ещё одна техника из категории "работает сегодня, но вряд ли будет работать позже"
tls-desync-fake-clienthello - другой способ обмана DPI: запутать его поддельным ClientHello на уровне пакетов, вместо несовпадения SNI/Host на уровне HTTP