Доменный фронтинг
Доменный фронт — имя хоста CDN, к которому приложения пользователей подключаются вместо вашего узла. CDN принимает соединение, по переданному ей имени хоста определяет ваш сервер и открывает собственное соединение с вашим узлом. Пользователи подключаются к CDN, и адрес вашего узла может вообще не появляться в их подписке.
Фронты находятся в разделе Конфигурации ядра → Доменный фронтинг. Их может быть до восьми, а один инбаунд может нести до четырёх.
Как фронт пополняет подписку
Фронт принадлежит инбаунду, а не узлу. С каким из ваших серверов говорить, выбирает CDN, поэтому один фронт покрывает все узлы, которые обслуживают инбаунд, и добавляет в подписку пользователя одну запись на инбаунд, а не по записи на каждый узел.
Три узла обслуживают один инбаунд, у каждого по два адреса для ссылок, а на этом инбаунде два фронта:
3 nodes × 2 addresses = 6 direct entries
2 fronts = 2 front entries
───────────────
8 entriesФронты и адреса узлов складываются, но никогда не перемножаются. Страница показывает, сколько записей добавляет каждый фронт.
Какие инбаунды можно фронтировать
CDN сама завершает TLS-соединение и передаёт вашему серверу HTTP-запросы. Поэтому фронтировать можно только инбаунд, который говорит по HTTP через транспорт, который несёт CDN:
WebSocket, HTTPUpgrade, gRPC, XHTTP и HTTP/2.
Остальные панель отклоняет при сохранении — и со стороны фронта, и со стороны инбаунда — и объясняет почему:
| Отклоняется | Почему |
|---|---|
| REALITY | Он привязан к собственному ключу инбаунда, а CDN предъявляет свой сертификат. Вместе они работать не могут. |
| Hysteria, Hysteria2, TUIC | Они работают поверх QUIC (UDP), а CDN передаёт HTTP. |
| Перескок портов | Диапазон портов принадлежит собственному слушателю узла, а фронт — одно имя хоста на одном порту. |
| Чистый TCP, AnyTLS, ShadowTLS, SOCKS, SSH и подобные | CDN не может нести поток, который не является HTTP-запросом. |
| XHTTP, который отправляет выгрузку в заголовке или cookie | CDN не переносит полезную нагрузку в этих местах. |
Для любого из них вместо фронта добавьте узлу второй адрес: см. адреса для ссылок узла в Узлы. Пресеты инбаундов VLESS + WebSocket + TLS и VLESS + gRPC + TLS сделаны для фронтинга.
Настройка фронта
Сначала в вашей CDN:
- Добавьте имя хоста с проксированием через CDN (в Cloudflare — оранжевое облако).
- Укажите адрес вашего узла как его origin.
- Если у инбаунда за CDN нет собственного TLS, разрешите обычный HTTP до origin. Это частая и нормальная ситуация: зашифрованное соединение пользователя установлено с CDN.
Затем в панели, в разделе Конфигурации ядра → Доменный фронтинг, нажмите Добавить:
| Поле | |
|---|---|
| Метка | Называет фронт и добавляется к именам записей, которые он создаёт, чтобы два фронта на одном инбаунде можно было различить. |
| Адрес | Имя хоста CDN, к которому подключаются приложения. *.cdn.example.com даёт каждому подписчику своё имя (см. ниже). |
| Порт | Пусто — 443. Это порт CDN, а не инбаунда. |
| SNI, Host | Пусто — отправляется собственное имя хоста фронта, чего и ждёт CDN. Заполняйте, только если вашей CDN нужно другое имя на origin. |
| ALPN, Отпечаток, Разрешить небезопасное | TLS приложения в сторону CDN. У CDN действительный сертификат, поэтому оставьте Разрешить небезопасное выключенным. |
| Заголовок адреса клиента | См. заголовок адреса клиента. |
| Узел-источник | Необязательно. См. ниже. |
| Порядок | Где в подписке стоят записи этого фронта. |
| Входящие | Инбаунды, к которым он ведёт. Предлагаются только инбаунды, которые может нести CDN. |
Фронты можно включать и с другой стороны: собственная вкладка инбаунда Доменный фронтинг перечисляет фронты на нём. Это та же настройка, увиденная со стороны инбаунда.
Запись фронта берёт адрес, порт, SNI, Host, ALPN и отпечаток из фронта, а путь и всё остальное — из инбаунда. Закрепление сертификата и диапазон перескока портов из неё убираются, потому что CDN предъявляет свой сертификат.
Изменения фронтов доходят до пользователей при следующем получении подписки; узлам ничего не отправляется, кроме заголовка адреса клиента.
Имя хоста для каждого подписчика
Запишите адрес как *.cdn.example.com, и каждый подписчик получит под ним собственное имя хоста, например k7m2rq9xdp.cdn.example.com. Если одно имя перестанет работать, это затронет одного клиента, а не всех.
- Имя вычисляется из подписки пользователя, поэтому при каждом обновлении в его приложении оно одно и то же, а у каждого пользователя своё. По нему нельзя определить подписку.
- Нужна wildcard-запись DNS
*.cdn.example.comс проксированием через CDN. Без неё эти имена не разрешаются ни у кого. - Проверьте, что сертификат вашей CDN покрывает это имя. В Cloudflare бесплатный сертификат Universal SSL покрывает
example.comи один уровень под ним (*.example.com), но не*.cdn.example.com. Либо поставьте wildcard прямо под вашей зоной, либо используйте тариф Cloudflare, который выпускает сертификаты для более глубоких имён. У других CDN свои правила.
Узел-источник
Узел-источник указывает, на какой узел CDN передаёт трафик. Записей он не добавляет. Панель использует его, чтобы не включать фронт в подписку пользователя, которого нет на этом узле (там запись не смогла бы войти), и чтобы предупредить вас, если этот узел не обслуживает инбаунд, на котором включён фронт. Оставьте Любой узел, если origin выбирает ваша CDN.
Только через фронт
Переключатель инбаунда Только через фронт на его вкладке Доменный фронтинг убирает прямые записи инбаунда из подписок, так что адрес узла нигде не появляется в файле пользователя.
Он действует для каждого пользователя отдельно и только там, где для этого пользователя действительно была записана запись фронта. Пользователь, у которого все фронты были исключены (например, из-за узла-источника, на котором его нет), сохраняет прямые записи, а не получает пустой файл. Если на инбаунде не включено ни одного фронта, переключатель ничего не делает.
Заголовок адреса клиента
За CDN все соединения с вашим узлом приходят с адресов CDN. Заголовок адреса клиента называет заголовок, в котором CDN передаёт настоящий адрес пользователя: CF-Connecting-IP для Cloudflare, True-Client-IP для Akamai, Fastly-Client-IP или AR-Real-IP для ArvanCloud.
Когда он задан, каждый XHTTP-инбаунд, на котором включён фронт, читает адрес пользователя из этого заголовка, поэтому лимиты устройств и адресов и журналы видят настоящего пользователя. Адресу можно доверять, только если:
- CDN записывает заголовок сама, а не передаёт тот, который отправило приложение (проверьте документацию вашей CDN);
- узел принимает соединения только от CDN, ведь приложение, которое доберётся до узла напрямую, тоже может отправить этот заголовок;
- все фронты на инбаунде указывают один и тот же заголовок.
Изменение этого заголовка — единственное изменение фронта, которое доходит до узлов: оно перезапускает там затронутые XHTTP-инбаунды, что обрывает их текущие соединения.
Инбаунды за ingress
Ingress маршрутизирует по имени в TLS-рукопожатии. CDN подключается к вашему узлу с именем хоста фронта, поэтому маршрут ingress, в котором этого имени нет, отправляет трафик в свой запасной вариант. Добавьте в маршрут имя хоста фронта или суффикс вроде .cdn.example.com, который покрывает и wildcard-фронт. Пока вы этого не сделаете, панель будет предупреждать.
Связанные страницы
- Инбаунды: инбаунды, к которым ведёт фронт.
- Подписки и страница подписки: домены подписки, в которых так же можно использовать wildcard.
- Узлы: адреса для ссылок — альтернатива для инбаундов, которые CDN нести не может.
- От шаблона до ссылки: как собирается подписка.