TLS для своего домена коротких ссылок

Настройка своего домена с HTTPS требует одной TXT-записи, одной CNAME-записи и короткого ожидания. Вы добавляете имя хоста в Elido, копируете два DNS-значения, которые он выдаёт, а TLS-сертификат выпускается автоматически при первом открытии ссылки на этом домене. Медленная часть - распространение DNS, которым вы управляете через TTL. Эта статья проводит по пяти шагам, а затем объясняет устройство механизма, чтобы вы знали, где искать, если шаг застрял.

Всё ниже проверено по текущему коду и панели управления Elido на 2026-10-09. Там, где смежная функция ещё не построена, статья об этом говорит.

Почему TLS важен для короткой ссылки

Короткая ссылка - это редирект, и ответ с редиректом и есть вся полезная нагрузка. Ответ 301 или 302 с заголовком Location несёт ваш URL назначения. Если первый запрос идёт по обычному HTTP, любой на пути сети может прочитать этот адрес назначения до того, как браузер по нему перейдёт.

QR-коды делают это хуже. Тот, кто сканирует код на витрине магазина или на плакате, не имеет предыдущих отношений с этим URL, поэтому адресная строка - единственный сигнал доверия, который он получает. Предупреждение браузера при сканировании - худшее возможное первое впечатление, а за тираж вы уже заплатили.

На общих коротких доменах Elido сертификат принадлежит Elido, так что замок настоящий, но имя в нём не ваше. На go.acme.com имя ваше. Основы DNS и TLS, на которых это держится, разобраны в опорной статье о коротких ссылках на своём домене.

Шаг 1: выберите имя хоста

Выберите короткий поддомен, которым вы управляете и который больше ни для чего не используете: go.example.com, links.example.com или подобный. Префикс появляется в каждой отправляемой вами ссылке, поэтому чем короче, тем лучше.

Используйте поддомен, а не голый корень. RFC 1034, раздел 3.6.2 говорит, что имя с CNAME не может содержать других данных, а корень зоны всегда содержит записи SOA и NS, поэтому CNAME там недопустим. Некоторые DNS-провайдеры имитируют его записями ALIAS или flattened, но те отвечают IP-адресами вместо CNAME. Верификация Elido запрашивает сам CNAME, так что выровненный корень не пройдёт.

При регистрации имени действуют ещё два правила. Имя хоста должно быть полным доменным именем в нижнем регистре, а имена под elido.me и elido.app зарезервированы.

Шаг 2: добавьте домен в Elido

Откройте Domains в боковой панели, введите имя хоста и нажмите Add domain. Отметьте флажок wildcard, только если хотите, чтобы работал любой поддомен этого имени, например *.go.example.com. Обычно это не нужно. После этого Elido показывает две DNS-записи с кнопкой копирования рядом с каждой.

Тот же шаг через API - для скриптов онбординга или клиентских рабочих пространств:

curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"hostname": "go.example.com", "is_wildcard": false}'

Для вызова нужна роль, которая может управлять доменами. Новый домен возвращается со статусом pending, verify_token и объектом instructions с точными значениями записей:

{
  "domain": {
    "id": 42,
    "hostname": "go.example.com",
    "status": "pending",
    "is_wildcard": false
  },
  "instructions": {
    "txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
    "cname_record": "go.example.com CNAME edge.elido.me"
  }
}

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

Шаг 3: опубликуйте две DNS-записи

Добавьте обе записи у вашего DNS-провайдера точно так, как показано:

go.example.com                  CNAME  edge.elido.me.
_elido-verify.go.example.com    TXT    "verify=<your-token>"

CNAME направляет трафик в Elido. TXT-запись доказывает, что зона принадлежит вам. Нужны обе, а значение TXT должно в точности совпадать с токеном.

Для wildcard-регистрации CNAME становится *.go.example.com, а TXT-запись остаётся на _elido-verify.go.example.com, на родительском имени без звёздочки.

Если провайдер позволяет, задайте TTL 300 секунд для обеих записей. Во многих зонах по умолчанию 3600 секунд, и именно длинный TTL превращает пятиминутную работу в часовую.

Одно замечание о провайдерах важнее остальных. Если вы используете Cloudflare, оставьте CNAME в режиме только DNS (DNS-only). Документация Cloudflare говорит, что на проксируемую запись отвечают собственными IP-адресами Cloudflare вместо содержимого записи (по состоянию на 2026-10-09). Поэтому проксируемое имя никогда не вернёт CNAME, который ищет Elido, и верификация не пройдёт.

Шаг 4: дождитесь верификации

Нажимать ничего не нужно. Фоновый воркер внутри API Elido проверяет все ожидающие домены по таймеру, по умолчанию раз в 30 секунд, через публичный резолвер Google 8.8.8.8. Домен проходит, только если выполнены оба условия:

1. TXT-запись в _elido-verify.<hostname> содержит в точности verify=<token>.
2. У имени хоста есть CNAME, который разрешается в edge-цель Elido.

Когда оба условия выполнены, статус меняется на verified. Опрашивайте его сами, если автоматизируете настройку:

curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
  -H "Authorization: Bearer $ELIDO_API_TOKEN"

Чтобы не ждать следующего тика, отправьте POST .../domains/42/verify. Он возвращает 202 и ставит домен в начало очереди. Домен, остающийся в pending 24 часа, помечается failed с причиной «verification timeout», а тот же вызов verify возвращает домен из failed обратно в pending, чтобы вы могли повторить попытку после исправления DNS.

Если процесс застрял, запросите записи тем же способом, что и проверяющий:

dig @8.8.8.8 TXT _elido-verify.go.example.com +short
dig @8.8.8.8 CNAME go.example.com +short

Первая команда должна вывести "verify=<your-token>". Вторая должна вывести edge.elido.me. с завершающей точкой.

Шаг 5: первый запрос выпускает сертификат

Когда статус стал verified, делать больше ничего не нужно. Elido не выпускает сертификаты заранее. TLS-слой выпускает сертификат по требованию, когда браузер впервые открывает TLS-соединение с вашим именем хоста.

Прежде чем что-либо запрашивать у Let's Encrypt, edge вызывает проверку авторизации в API Elido. Ответ «да» даётся, только если имя хоста в состоянии verified или active либо подпадает под подтверждённую wildcard-регистрацию. Любой другой ответ, включая неизвестное имя, отклоняет рукопожатие, и сертификат не запрашивается. Именно этот барьер не даёт постороннему направить миллион имён хостов на Elido и исчерпать лимиты центра сертификации.

Когда проверка пройдена, выпуск использует проверку HTTP-01 из RFC 8555: центр сертификации запрашивает токен по адресу /.well-known/acme-challenge/ на вашем имени хоста по обычному HTTP, edge отвечает на него, и сертификат выпускается и кэшируется. Первый посетитель на мгновение ждёт этого. Последующие запросы используют кэшированный сертификат.

Полезная привычка: откройте https://go.example.com сами сразу после верификации, чтобы сертификат уже существовал до того, как первым запросом окажется запрос клиента или сканирование QR.

Передайте id домена как domain_id при создании ссылки. Ссылка сразу работает по адресу https://go.example.com/<slug>. Страница Domains также показывает клики за 30 дней по каждому имени хоста. Полный справочник, включая рекомендации по CAA, находится в руководстве по своим доменам, а обзор продукта - на странице функции своих доменов.

Что означают значения статуса

В текущей сборке исправный домен остаётся в статусе verified. Значение active есть в модели данных и в фильтре панели управления, и барьер сертификатов принимает оба, но пока ничто не переводит домен в него.

Типичные ловушки

CAA-записи, исключающие Let's Encrypt. CAA-запись ограничивает, какие центры могут выпускать сертификаты для имени, и наследуется поддоменами (по состоянию на 2026-10-09). Если в вашей зоне есть example.com CAA 0 issue "digicert.com", выпуск для go.example.com будет отклонён. Добавьте go.example.com CAA 0 issue "letsencrypt.org" или расширьте запись на вершине зоны.

Прокси или CDN перед CNAME. Обычно это оранжевое облако Cloudflare, о нём шла речь в шаге 3. Любой слой, отвечающий на DNS или HTTP от вашего имени, ломает и проверку CNAME, и проверку HTTP-01.

Wildcard-домен - не wildcard-сертификат. Согласно документации Let's Encrypt по типам проверок, HTTP-01 не может выпускать wildcard-сертификаты, а DNS-01 требует доступа на запись в вашу зону (по состоянию на 2026-10-09). Поэтому wildcard-регистрация покрывает маршрутизацию для каждого поддомена, но client1.go.example.com и client2.go.example.com получают каждый собственный сертификат при первом использовании. Let's Encrypt ограничивает число новых сертификатов на зарегистрированный домен до 50 за 7 дней (по состоянию на 2026-10-09), так что подключение сотен новых поддоменов за одну неделю требует планирования.

Позднее удаление CNAME. Сегодня DNS-проверка выполняется только пока домен в статусе pending. После подтверждения домена Elido больше его не перепроверяет, поэтому удалённый CNAME проявляется как отказывающие редиректы и неудачное обновление сертификатов, а не как смена статуса или уведомление. Следите за записью на своей стороне. Периодическая проверка состояния с деградированным статусом и льготным периодом запланирована, но не построена.

Marius Voß - DevRel и edge-инфраструктура в Elido. Он отвечает за путь редиректа и процесс подключения своих доменов.

Читайте также в блоге

• Короткие ссылки на своём домене: DNS, TLS и что работает на edge
• Настройка брендированных коротких ссылок: выберите домен и запустите за вечер
• Как уложить p95 редиректов в 15 мс
• Elido и Rebrandly
• Вредят ли сокращатели URL SEO?