DADA Cloud
Все руководства

Свой домен и HTTPS

Зачем это нужно

Отдавать приложение на вашем домене вместо технического адреса платформы, с TLS-сертификатом, который выпускается и продлевается автоматически.

Модель из двух шагов:

  1. Подтвердить апекс-домен, которым вы владеете, — на уровне проекта, страница Domains.
  2. Привязать конкретный хост под этим апексом к приложению — в самом приложении, Settings → Domains.

Шаг 1 — подтвердите апекс-домен

  1. Откройте Domains в навигации проекта → Add Domain.
  2. Введите апекс (корневой) домен, например acme.com — без http://, без поддомена и без пути.
  3. Вы получите TXT-запись для подтверждения: тип, имя и значение. Рядом с каждым полем есть кнопка копирования.
  4. Добавьте запись у своего DNS-провайдера и вернитесь нажать Verify.
  5. Проверка ручная, автоматического опроса нет. Если DNS ещё не разъехался, нажмите Verify ещё раз через несколько минут.
  6. После подтверждения апекс и все его поддомены становятся доступны этому проекту.

Шаг 2 — привяжите хост к приложению

  1. Откройте нужное приложение → Settings → вкладка Domains.
  2. Введите хост, например shop.acme.com. Это должен быть сам апекс или поддомен уже подтверждённого в этом проекте апекса.
  3. Нажмите Attach. Консоль подскажет DNS-запись (тип, имя, цель), которую нужно направить на ingress платформы, если вы этого ещё не сделали.
  4. TLS-сертификат выпустится автоматически, как только DNS начнёт резолвиться на платформу.
  5. Хост появится в таблице со столбцами Status и Certificate — по ним видно, когда всё поднялось.

Подводные камни

  • Привязка делается в приложении, а не на странице Domains. Страница Domains отвечает только за подтверждение владения апексом — кнопки «привязать поддомен» там нет.
  • Verify нажимается руками, автоопроса нет: обычно это одно нажатие, пауза на распространение DNS и ещё одно нажатие.
  • Чтобы убрать подтверждение домена, сперва отвяжите все хосты под ним — диалог подтверждения так и говорит. Отвязывайте хосты в Settings → Domains каждого приложения.
  • Отвязка хоста немедленно убирает его TLS-сертификат и ingress. Само приложение продолжает работать на техническом адресе платформы.

Сеть: IP посетителей и исходящие адреса

Что приходит в ваше приложение и что уходит из него наружу — важно, если вы ставите приложение как обратный прокси перед своим origin-сервером или строите защиту по адресам.

Входящие запросы. Ingress платформы добавляет стандартные заголовки X-Forwarded-For, X-Real-IP, X-Forwarded-Proto и X-Forwarded-Host. Но реальный IP посетителя в них сегодня не приходит: публичный балансировщик перед кластером работает на уровне L4 и подменяет адрес источника, поэтому в X-Forwarded-For и X-Real-IP окажется адрес самого балансировщика (155.212.223.198), а не посетителя. Не стройте на этих заголовках лимиты, гео-логику или антифрод — они увидят один и тот же адрес у всех.

Исходящие запросы (ваше приложение → ваш origin или любой внешний сервис) уходят с публичных адресов узлов кластера. Набор узлов меняется при масштабировании и обслуживании, фиксированного списка диапазонов нет — allowlist по IP на origin-сервере сломается при первой же замене узла. Надёжнее защитить origin тем, что подменить нельзя:

  • секретный заголовок (например, X-Origin-Token), который ваше приложение добавляет к каждому запросу, а origin проверяет; значение держите в переменных окружения приложения;
  • mTLS: клиентский сертификат на стороне приложения, проверка на origin;
  • origin, закрытый от интернета целиком, и туннель/VPN до него из приложения.

Чего пока нет

  • Реального IP посетителя в X-Forwarded-For / X-Real-IP — нужен PROXY protocol между балансировщиком и ingress на стороне хостинг-провайдера.
  • Фиксированных исходящих адресов (static egress IP).
  • Автоматической проверки TXT-записи — Verify нажимается вручную.
  • Управления хостами со страницы Domains: сегодня это только настройки приложения.

Куда дальше

Все руководства