Налаштування кастомного домену з HTTPS потребує двох DNS-записів і близько трьох хвилин очікування на розповсюдження (propagation). Решта часу зазвичай витрачається на розуміння того, що означають ці записи, чому потрібні обидва, і що відбувається після їх додавання. Цей пост є практичною версією: п’ять конкретних кроків, точний виклик API та пояснення механізму роботи сертифікатів, щоб ви знали, що робити, якщо щось піде не так.
Чому TLS важливий саме для коротких посилань#
Коротке посилання без HTTPS - це ризик у спосіб, у який звичайний URL без HTTPS ним не є.
Відповідь перенаправлення - 301 або 302 з заголовком Location - це і є весь корисний контент. Якщо початковий HTTP-запит передається через звичайний HTTP, будь-хто на мережевому шляху може прочитати URL призначення до того, як клієнт перейде за ним. Це означає, що посилання на вашу кампанію, партнерське посилання або внутрішній інструмент буде видимим для будь-якого мережевого спостерігача вже на першому кроці. Сучасні браузери почали показувати попередження про безпеку на коротких посиланнях HTTP саме через таку модель вразливості.
QR-коди посилюють проблему. Людина, яка сканує код у фізичному просторі, не має попередньої довіри до URL - сам код є єдиним сигналом довіри. Попередження браузера при першому завантаженні є найгіршою точкою тертя: ви вже заплатили за друк, розміщення на заході або зовнішню рекламу, і попередження про безпеку при скануванні - це те, що з найбільшою ймовірністю відштовхне зацікавлену людину. Валідний TLS-сертифікат на вашому власному домені - це найдешевший сигнал довіри, який ви можете придбати для кампанії на основі QR.
На s.elido.me або b.elido.me TLS-сертифікат належить Elido. Значок замка справжній, але домен не ваш, а це означає, що брендова довіра дістається платформі, а не вам. Кастомний домен на кшталт go.acme.com ставить ваше ім'я на сертифікат.
Більше про основи DNS та TLS у ключовому пості: Кастомні домени для коротких посилань: DNS, TLS та що працює на edge.
Крок 1: Оберіть ім'я хоста#
Найпоширенішим вибором є короткий піддомен вашого основного домену: go.example.com, links.example.com або s.example.com. Чим коротше, тим краще - префікс піддомену з'являється у кожному посиланні, яке ви надсилаєте.
Два обмеження, про які варто знати перед прийняттям рішення:
Тільки піддомен, якщо ваш DNS-провайдер не підтримує ALIAS-записи. RFC 1034 §3.6.2 забороняє записи CNAME на вершині зони (apex) (example.com). Якщо ви хочете, щоб голий apex перенаправляв запити, ваш DNS-провайдер повинен підтримувати записи ALIAS або ANAME (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS). Це нестандартні розширення, які "розплющують" (flatten) пошук перед його публікацією. Перевірте документацію вашого провайдера; назва функції варіюється, і не кожен провайдер її пропонує.
Оберіть піддомен, який ви не використовуєте ні для чого іншого. Піддомен links.example.com, що перенаправляється через Elido, не повинен мати запису A, що вказує на ваш веб-сервер, або вже існуючого CNAME. DNS-записи для одного й того самого імені мають бути узгодженими.
Для більшості команд go.example.com або links.example.com - це чудовий вибір. Оберіть його, запишіть і переходьте до кроку 2.
Крок 2: Зареєструйте домен в Elido#
Відкрийте Settings → Custom Domains → Add Domain у панелі керування, введіть ваше ім'я хоста та натисніть Add. Відповіддю будуть два значення DNS-записів: токен верифікації та ціль CNAME. Ви використаєте обидва на кроці 3.
Якщо ви автоматизуєте це за допомогою скриптів - наприклад, при підключенні нового клієнтського робочого простору, як частину конвеєра розгортання або керуючи цим через Terraform provider - виклик 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
}'
Тіло відповіді містить verification_token (випадковий шістнадцятковий рядок) та instructions, що містять точні значення DNS-записів:
{
"domain": {
"id": 42,
"hostname": "go.example.com",
"status": "pending_verification"
},
"instructions": {
"txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
"cname_record": "go.example.com CNAME edge.elido.me"
}
}
Кастомні домени доступні на платних планах. План Business є початковою точкою для кастомних доменів; агентствам, що керують багатьма доменами клієнтів в одній організації, варто звернути увагу на модель робочих просторів на сторінці рішень для агентств.
Крок 3: Додайте два DNS-записи#
Перейдіть до панелі керування вашого DNS-провайдера та додайте обидва записи з об'єкта instructions. Вам потрібні обидва - CNAME спрямовує трафік на edge-вузли Elido; запис TXT підтверджує, що ви є власником домену, перш ніж Elido погодиться його обслуговувати.
Для звичайного піддомену:
go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Для wildcard-домену (план Business, охоплює *.go.example.com):
*.go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Префікс _elido-verify є стандартною конвенцією DNS challenge - він розміщує підтвердження власності на піддомені хоста, що верифікується, тому запис TXT не може конфліктувати з CNAME.
Кілька зауважень щодо конкретних провайдерів:
- Cloudflare: Додайте обидва записи. Залиште перемикач проксі CNAME у стані off (сіра хмара, DNS-only). Режим HTTP-проксі Cloudflare видаляє оригінальне ім'я хоста до того, як воно досягне edge-вузла Elido, що ламає перевірку авторизації
CaddyAsk. Режим DNS-only передає запит без змін. - AWS Route 53: Використовуйте запис ALIAS, якщо вам потрібен apex; для піддоменів звичайний CNAME є правильним вибором. Route 53 не підтримує CNAME на вершині зони, але підтримує ALIAS для зовнішніх цілей.
- GoDaddy / Namecheap / більшість реєстраторів DNS: Стандартні CNAME та TXT - ніяких спеціальних налаштувань не потрібно.
Встановіть TTL для обох записів на 300 секунд (5 хвилин), якщо ваш провайдер це дозволяє. Стандартний TTL для багатьох керованих зон становить 3600 секунд; менший TTL означає швидше підтвердження розповсюдження та швидше відновлення, якщо вам знадобиться змінити записи пізніше.
Крок 4: Зачекайте на верифікацію#
Після того, як записи будуть додані, domain-manager автоматично перевіряє їх через публічний резолвер Google (8.8.8.8) з коротким інтервалом. Вам не потрібно натискати "Verify now".
Сервіс перевіряє дві умови перед тим, як позначити домен як активний:
_elido-verify.go.example.comповертає запис TXT, значення якого дорівнюєverify=<token>- це підтверджує, що ви керуєте зоною DNS.go.example.comрезолвиться через CNAME наedge.elido.me- це підтверджує, що трафік дійде до edge-вузлів Elido.
Коли обидві перевірки пройдено, status змінюється з pending_verification на verified. Ви можете перевірити це самостійно:
curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
-H "Authorization: Bearer $ELIDO_API_TOKEN"
Стежте за полем status. Типовий час розповсюдження для записів із TTL 300с становить менше 5 хвилин. Записи зі стандартним TTL 3600с можуть оновлюватися до години, якщо ви перебуваєте в частині світу, де резолвери агресивно кешують дані.
Якщо верифікація затримується, перевірте, чи правильно опубліковані ваші записи:
dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short
Запит TXT має повернути "verify=<your-token>". Запит CNAME має повернути edge.elido.me. (крапка в кінці - це нормально).
Крок 5: Перший запит автоматично випускає сертифікат#
Після того, як domain-manager позначить домен як верифікований та зареєструє його в Caddy, ваша частина роботи завершена. TLS налаштовується без жодних додаткових дій.
Механізм базується на Caddy on-demand TLS (ADR-0012): замість того, щоб заздалегідь випускати сертифікати для кожного верифікованого домену, Caddy випускає сертифікат під час першого TLS-з'єднання для нового імені хоста. Перед спробою випуску через ACME, Caddy звертається до ендпоінту CaddyAsk сервісу domain-manager - звичайний HTTP-запит GET ?domain=go.example.com. Якщо domain-manager повертає 200 (домен у стані verified або active), Caddy продовжує процес. Якщо повертається 404, TLS-з'єднання переривається, і запит на сертифікат не надсилається. Цей фільтр є останньою лінією захисту від помилкового випуску сертифікатів для невідомих імен хостів.
Коли Caddy продовжує процес, потік ACME (RFC 8555) виконує перевірку HTTP-01:
- Caddy запитує нове замовлення у Let's Encrypt.
- Let's Encrypt відповідає токеном виклику: розмістіть його за адресою
http://go.example.com/.well-known/acme-challenge/<token>. - Caddy розміщує токен у своєму HTTP-обробнику в пам'яті.
- Let's Encrypt отримує токен через звичайний HTTP та перевіряє його.
- Сертифікат випущено, збережено у кеші сертифікатів Caddy, а початковий HTTPS-запит обслуговується.
Кроки 1–5 додають приблизно 2–3 секунди затримки до найпершого запиту до щойно верифікованого домену. Кожен наступний запит використовує кешований сертифікат без жодних затримок. Caddy автоматично оновлює сертифікати до закінчення терміну їх дії.
Elido випускає сертифікати ECDSA P-256 для всіх кастомних доменів. Підписи P-256 менші та швидші для перевірки, ніж RSA-2048, що має значення на edge-вузлах, де TLS-з'єднання знаходяться на критичному шляху.
Поширені помилки#
Записи CAA блокують Let's Encrypt. Записи Certification Authority Authorization (CAA) визначають, яким центрам сертифікації дозволено випускати сертифікати для домену. Якщо ваша DNS-зона має запис example.com CAA 0 issue "digicert.com", Let's Encrypt відмовиться випускати сертифікат для go.example.com, оскільки він успадковує політику CAA вершини домену. Вирішення: додайте go.example.com CAA 0 issue "letsencrypt.org" або видаліть обмеження на вершині, якщо це дозволяє ваша політика безпеки. Статус-ендпоінт domain-manager повертає помилки CAA у тілі повідомлення про помилку.
Увімкнено проксі Cloudflare. Дивіться крок 3 - CNAME має бути DNS-only (сіра хмара). Режим "помаранчевої хмари" (proxied) переписує ім'я хоста у запиті, що призводить до невдачі авторизації CaddyAsk.
CNAME flattening на вершині домену. Функція CNAME flattening від Cloudflare працює для більшості випадків, але має один нюанс: DNS-відповідь від серверів імен Cloudflare - це запис A (кінцевий IP), а не CNAME. Перевірка верифікації Elido використовує LookupCNAME, яка спрацьовує, коли сервери імен провайдера надають синтезовану відповідь CNAME. Якщо flattening вашого DNS-провайдера надає лише кінцевий запис A без CNAME, перевірка CNAME не пройде. На практиці flattening у Cloudflare включає CNAME у ланцюжок відповідей для записів, що не є apex; на вершині це залежить від реалізації провайдера. Перевірте за допомогою dig CNAME go.example.com через стандартний резолвер, перш ніж робити висновок про наявність помилки.
Wildcard TLS - це HTTP-01, а не DNS-01. Elido не випускає wildcard-сертифікати (*.go.example.com) через стандартний автоматизований потік - згідно з RFC 8555 §8.4, wildcard-сертифікати потребують перевірки DNS-01, що вимагає доступу на запис до DNS-зони. Elido не керує вашою DNS-зоною. Функція wildcard-доменів у плані Business означає, що один CNAME покриває маршрутизацію для всіх піддоменів, але кожне ім'я хоста (client1.go.example.com, client2.go.example.com) отримує власний сертифікат, випущений через HTTP-01 при першому запиті, а не один спільний wildcard-сертифікат. Операційний результат той самий: піддомени працюють автоматично. Сховище сертифікатів зростає пропорційно.
Видалення CNAME після верифікації. Якщо ваша DNS-команда видалить CNAME під час міграції або очищення, періодична перевірка стану domain-manager виявить відсутність запису і змінить статус домену на degraded. Ви отримаєте сповіщення; існує пільговий період до того, як обслуговування домену буде призупинено. Відновіть CNAME, і перевірка стану автоматично поверне домен у статус active.
Чим це відрізняється від Bitly та Rebrandly#
Налаштування кастомного домену в Bitly вимагає завантаження TLS-сертифіката або використання їх керованого потоку сертифікатів, що передбачає ручний крок запиту сертифіката у старих тарифних планах. Рівень автоматизації залежить від вашого плану Bitly; корпоративні акаунти мають більш керований шлях.
Процес налаштування в Rebrandly добре відпрацьований - їхній майстер підключення надає інструкції CNAME для конкретних провайдерів і перевіряє розповсюдження прямо у браузері. В основі механізму TLS лежить CloudFront: Rebrandly використовує функцію кастомних доменів AWS CloudFront, що означає, що центр сертифікації та життєвий цикл сертифікатів керуються AWS ACM. Це працює добре, але означає, що трафік вашого кастомного домену за замовчуванням маршрутизується через інфраструктуру AWS US-East, що важливо, якщо ви оцінюєте резидентність даних у ЄС (див. Elido vs Rebrandly для повного порівняння резидентності).
Підхід Elido - Caddy on-demand TLS з фільтром авторизації domain-manager - зберігає повний життєвий цикл сертифікатів всередині системи, працює ідентично для self-hosted розгортань і не створює залежності від сторонніх CDN для керування сертифікатами. Вартістю є затримка першого запиту (2–3 секунди для виклику ACME); наступні запити не мають жодних накладних витрат.
Після завершення верифікації створіть посилання на вашому кастомному домені, передавши domain_id у виклику створення посилання - або виберіть його у випадаючому списку доменів у панелі керування чи мобільному додатку. Посилання миттєво стає доступним за адресою https://go.example.com/<slug> з валідним сертифікатом.
Додаткове читання: Кастомні домени для коротких посилань: DNS, TLS та що працює на edge охоплює повну архітектуру, включаючи механіку edge-кешу, ліміти запитів та сценарії відмов. Повний посібник із конфігурації доменів, включаючи рекомендації щодо CAA та довідник API, знаходиться за адресою /docs/guides/custom-domains.
Marius Voß - DevRel + edge infra в Elido. Він відповідає за сервіси edge-redirect та domain-manager.
Схоже у блозі#
Спробуйте Elido
Вставте URL - отримайте коротке посилання
Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.
Безкоштовно, без реєстрації · 2 на день