Як додати субдомен до вашого домену

A субдомен — це префікс, що додається до кореневого домену та створює окремий, незалежно адресований простір імен під тим самим доменним іменем. Наприклад, для кореневого домену example.com ім’я хоста blog.example.com є повністю кваліфікованим субдоменом, де blog є міткою третього рівня. Субдомени розпізнаються через DNS-записи — зазвичай запис A, що вказує на IPv4-адресу, запис AAAA для IPv6 або запис CNAME, що є псевдонімом іншого імені хоста — і вони не потребують додаткової плати за реєстрацію домену.

З практичної точки зору, субдомени дозволяють запускати окремі веб-застосунки, тестові середовища, регіональні сайти або мікросервіси під одним зареєстрованим доменом із незалежними кореневими директоріями документів, SSL-сертифікатами та конфігураціями сервера. Цей посібник охоплює повний технічний процес: створення DNS-записів, налаштування хостингу, отримання SSL, перевірку поширення та поширені помилки, які більшість інструкцій не згадує.

Що таке субдомен і чим він відрізняється від підкаталогу

Перш ніж торкатися DNS, варто зрозуміти архітектурну різницю між субдоменом і підкаталогом, оскільки цей вибір впливає на SEO, конфігурацію сервера та область дії SSL.

Джон Мюллер з Google підтвердив, що Google зазвичай розглядає субдомени як частину того самого сайту, коли вміст явно пов’язаний, однак поведінка щодо бюджету сканування, індексування та передачі ваги посилань може відрізнятися. Для тісно інтегрованого вмісту, наприклад корпоративного блогу, підкаталог часто є менш складним вибором. Для окремого застосунку — клієнтського порталу, API-шлюзу або тестового середовища — субдомен є правильним архітектурним рішенням.

Поширені випадки використання субдоменів

• Тестові середовища та середовища контролю якості: staging.example.com або dev.example.com — ізольовані від виробничого середовища, часто захищені HTTP Basic Auth або списками дозволених IP-адрес.
• API-ендпоінти: api.example.com — дозволяє незалежне розгортання, обмеження частоти запитів і завершення TLS.
• Клієнтські портали або SaaS-дашборди: app.example.com — окремий контекст автентифікації та cookie сесії.
• Регіональні або мовні сайти: de.example.com, us.example.com — підтримує таргетинг hreflang та геоспецифічну маршрутизацію сервера.
• Документація та підтримка: docs.example.com, support.example.com — часто розміщується на таких платформах, як GitBook, Zendesk або власна вікі.
• CDN або доставка медіаконтенту: cdn.example.com, static.example.com — CNAME вказує на граничну мережу CDN.
• Поштова інфраструктура: mail.example.com — використовується як ім’я хоста для служб SMTP/IMAP, окремо від MX-записів.

Крок 1: Доступ до інтерфейсу керування DNS

DNS-записи домену керуються там, де розміщені авторитетні сервери імен домену. Це не завжди те саме місце, що й ваш веб-хостинг. Авторитетний сервер імен визначається NS-записами у вашого реєстратора домену.

Визначте, де керується ваш DNS:

dig NS example.com +short

Якщо у виводі відображаються сервери імен, що належать вашому реєстратору (наприклад, ns1.registrar.com), керуйте DNS у реєстратора. Якщо відображаються сервери імен хостинг-провайдера або такого сервісу, як Cloudflare, керуйте DNS там.

Після визначення правильної панелі керування:

1. Увійдіть до інтерфейсу керування DNS.
2. Знайдіть розділ DNS Zone Editor, DNS Management або Zone File.
3. Виберіть домен, для якого хочете створити субдомен.

Якщо ваш домен зареєстровано через реєстрацію доменів AlexHost, редактор DNS-зони доступний безпосередньо з панелі вашого клієнтського кабінету.

Крок 2: Створення DNS-запису для субдомену

Ви створите один із трьох типів записів залежно від вашої інфраструктури.

Запис A — вказує на IPv4-адресу

Використовуйте запис A, коли субдомен розпізнається до конкретної IP-адреси сервера. Це найпоширеніший сценарій для субдоменів, розміщених на VPS або виділеному сервері.

Важлива деталь: Введіть лише мітку субдомену в поле «Ім’я» — blog, а не blog.example.com. Більшість DNS-інтерфейсів автоматично додають кореневий домен. Введення повного FQDN створить запис для blog.example.com.example.com.

Запис AAAA — вказує на IPv6-адресу

Ідентична структура до запису A, але значенням є повна IPv6-адреса:

Запис CNAME — псевдонім іншого імені хоста

Використовуйте запис CNAME, коли субдомен має розпізнаватися до іншого імені хоста, а не до прямої IP-адреси. Поширені сценарії включають вказівку на CDN, стороннє платформу (Shopify, HubSpot, Netlify) або інше внутрішнє ім’я хоста.

Архітектурне обмеження: Запис CNAME не може співіснувати з будь-яким іншим типом запису для тієї самої мітки. Ви не можете створити CNAME для самого example.com (вершини зони) — лише для субдоменів. На вершині використовуйте запис A або, якщо ваш DNS-провайдер підтримує це, власний запис ALIAS або ANAME.

Запис wildcard-субдомену

Запис A типу wildcard розпізнає будь-який невизначений субдомен до єдиної IP-адреси:

Це корисно для мультитенантних SaaS-застосунків, де кожен клієнт отримує субдомен (наприклад, customer1.example.com). Майте на увазі, що wildcard DNS-запис не забезпечує автоматичне отримання SSL для кожного субдомену — вам потрібен wildcard SSL-сертифікат або ACME-клієнт із підтримкою DNS-01 challenge.

Крок 3: Налаштування веб-сервера або панелі хостингу

Створення DNS-запису робить субдомен розпізнаваним, але не забезпечує автоматичну роздачу вмісту. Необхідно налаштувати веб-сервер або панель хостингу для прийому та маршрутизації запитів для нового імені хоста.

Налаштування субдомену в cPanel

Якщо ваш хостинг використовує cPanel — доступний у тарифах VPS з cPanel — процес такий:

1. Увійдіть до cPanel.
2. Перейдіть до Домени > Субдомени.
3. У полі Субдомен введіть мітку (наприклад, blog).
4. Виберіть кореневий домен зі спадного списку.
5. Встановіть Кореневу директорію документів — cPanel за замовчуванням використовує public_html/blog, але ви можете вказати будь-який шлях.
6. Натисніть Створити.

cPanel автоматично створює DNS-запис A у зоні BIND у WHM, якщо DNS домену керується локально. Якщо DNS керується зовні (наприклад, через Cloudflare), ви повинні додати запис там вручну, як описано в кроці 2.

Налаштування субдомену в Nginx

Для VPS з Nginx створіть новий серверний блок:

server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;

    root /var/www/blog;
    index index.html index.php;

    access_log /var/log/nginx/blog.access.log;
    error_log  /var/log/nginx/blog.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Збережіть файл у /etc/nginx/sites-available/blog.example.com, потім увімкніть його:

sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Налаштування субдомену в Apache

Створіть новий файл віртуального хоста за адресою /etc/apache2/sites-available/blog.example.com.conf:

<VirtualHost *:80>
    ServerName blog.example.com
    DocumentRoot /var/www/blog

    <Directory /var/www/blog>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/blog.error.log
    CustomLog ${APACHE_LOG_DIR}/blog.access.log combined
</VirtualHost>

Увімкніть і перезавантажте:

sudo a2ensite blog.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Крок 4: Отримання SSL-сертифіката для субдомену

Кожен субдомен, що обслуговує веб-трафік, має бути захищений TLS. Субдомен є окремим іменем хоста і не покривається сертифікатом кореневого домену для одного домену, якщо тільки ви не використовуєте wildcard-сертифікат.

Варіант 1 — Let’s Encrypt з Certbot (один субдомен)

sudo certbot --nginx -d blog.example.com

Або для Apache:

sudo certbot --apache -d blog.example.com

Certbot автоматично змінює конфігурацію віртуального хоста та налаштовує завдання cron для поновлення.

Варіант 2 — Wildcard-сертифікат Let’s Encrypt (DNS-01 Challenge)

Wildcard-сертифікат покриває *.example.com, захищаючи всі поточні та майбутні субдомени одним сертифікатом. Для цього потрібна верифікація через DNS-01 challenge:

sudo certbot certonly 
  --manual 
  --preferred-challenges dns 
  -d "*.example.com" 
  -d "example.com"

Certbot запропонує вам створити запис TXT (_acme-challenge.example.com) у вашій DNS-зоні. Після додавання запису та перевірки поширення Certbot видасть сертифікат. Wildcard-сертифікати необхідно поновлювати кожні 90 днів; автоматизуйте поновлення за допомогою DNS-плагіна для вашого провайдера (наприклад, certbot-dns-cloudflare).

Варіант 3 — Комерційний SSL-сертифікат

Для організацій, яким потрібна розширена перевірка (EV) або довший термін дії, підходить комерційний сертифікат від довіреного CA. AlexHost пропонує SSL-сертифікати, включаючи варіанти з перевіркою домену, перевіркою організації та wildcard. Після придбання встановіть сертифікат, розмістивши файли .crt та .key на сервері та вказавши на них у конфігурації віртуального хоста.

Крок 5: Перевірка поширення DNS

Зміни DNS не набувають чинності глобально в момент збереження. Кожен резолвер кешує записи протягом часу, визначеного значенням TTL. При TTL 3600 резолвери можуть обслуговувати старий запис до однієї години після внесення змін.

Перевірте поширення з кількох глобальних точок спостереження:

# Check from a specific DNS resolver
dig A blog.example.com @8.8.8.8 +short
dig A blog.example.com @1.1.1.1 +short

# Check authoritative answer directly
dig A blog.example.com +trace

Для візуальної перевірки в кількох регіонах скористайтеся whatsmydns.net або dnschecker.org. Повне глобальне поширення зазвичай завершується протягом 15 хвилин — 2 годин для TTL 3600 або нижче. Часто згадуване «до 48 годин» стосується переважно значень TTL 86400 (24 години), встановлених для попереднього запису — поширений стандарт у багатьох реєстраторів.

Порада: Перед внесенням змін до DNS знизьте TTL наявного запису до 300 (5 хвилин) щонайменше за один цикл TTL заздалегідь. Це значно скорочує час очікування поширення під час фактичної зміни.

Крок 6: Наскрізне функціональне тестування

Після поширення виконайте повне функціональне тестування:

# Confirm DNS resolution
dig A blog.example.com +short

# Confirm HTTP response
curl -I http://blog.example.com

# Confirm HTTPS and certificate validity
curl -I https://blog.example.com

# Inspect the TLS certificate
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -dates

Перевірте, що:

• Відповідь curl -I повертає 200 OK або очікуваний код перенаправлення.
• Суб’єкт TLS-сертифіката відповідає blog.example.com або *.example.com.
• Дата закінчення терміну дії сертифіката правильна.
• У консолі розробника браузера відсутні попередження про змішаний вміст.

Поширені помилки та способи їх уникнення

CNAME на вершині зони: Спроба створити запис CNAME для самого example.com порушить доставку пошти та інші DNS-записи. Використовуйте запис A або запис ALIAS/ANAME на вершині.

Субдомен не обслуговується веб-сервером: DNS розпізнається правильно, але браузер повертає 404 або відмову з’єднання. Причина: веб-сервер не має віртуального хоста, що відповідає імені хоста субдомену. Рішення: додайте серверний блок або віртуальний хост, як описано в кроці 3.

Невідповідність SSL-сертифіката: Браузер показує помилку сертифіката. Причина: наявний сертифікат покриває лише example.com, а не blog.example.com. Рішення: видайте новий сертифікат спеціально для субдомену або замініть на wildcard-сертифікат.

cPanel створює локальний DNS-запис, але DNS керується зовні: При використанні Cloudflare або іншого зовнішнього DNS-провайдера з хостингом cPanel майстер субдоменів cPanel створює запис у локальній зоні BIND у WHM, яка ніколи не використовується. Ви повинні додати запис A вручну в Cloudflare (або вашому зовнішньому DNS-провайдері). Це одне з найпоширеніших джерел плутанини для користувачів спільного хостингу.

Wildcard DNS без wildcard SSL: DNS-запис *.example.com розпізнає всі субдомени до вашого сервера, але кожен новий субдомен викликатиме попередження про сертифікат, якщо у вас не встановлено wildcard SSL-сертифікат. Не покладайтеся лише на wildcard DNS для виробничих субдоменів.

Витік області дії cookie: Якщо ваш застосунок встановлює cookie для .example.com (зверніть увагу на крапку на початку), ці cookie надсилаються до всіх субдоменів. Це може розкрити токени сесії з субдомену з високим рівнем безпеки менш захищеному. Явно обмежуйте область дії cookie до призначеного імені хоста.

Керування субдоменами в різних середовищах хостингу

Для високонавантажених застосунків, що потребують повного доступу root та нестандартних конфігурацій сервера, виділений сервер надає повний контроль над DNS, програмним забезпеченням веб-сервера та керуванням сертифікатами без обмежень спільного середовища.

Контрольний список технічних рішень

Перед створенням субдомену опрацюйте наступне:

• Де знаходяться авторитетні сервери імен? Виконайте dig NS example.com +short для підтвердження перед входом до будь-якої панелі.
• Запис A чи CNAME? Використовуйте A/AAAA для IP-адреси сервера. Використовуйте CNAME для імені хоста сторонньої платформи. Ніколи не використовуйте CNAME на вершині зони.
• Чи налаштований веб-сервер для прийому нового імені хоста? DNS-запис сам по собі не обслуговує вміст.
• Чи потрібен субдомену власний SSL-сертифікат? Так, якщо wildcard-сертифікат ще не встановлено.
• Чи знижено TTL перед змінами? Знизьте його до 300 щонайменше за один цикл TTL до внесення змін, щоб мінімізувати затримку поширення.
• Чи керує cPanel DNS локально, тоді як зовнішній провайдер є авторитетним? Якщо так, додайте запис у зовнішнього провайдера, а не в cPanel.
• Чи потрібно заблокувати індексування субдомену пошуковими системами? Якщо це тестове або внутрішнє середовище, додайте X-Robots-Tag: noindex на рівні сервера або використовуйте HTTP Basic Auth.
• Чи правильно визначено область дії cookie? Явно встановлюйте атрибут Domain для cookie, щоб запобігти ненавмисному міжсубдоменному поширенню.

Часті запитання

Чи можна створити субдомен без доступу до DNS кореневого домену?

Ні. Субдомен потребує DNS-запису (A, AAAA або CNAME) у зоні кореневого домену. Без права запису до авторитетної DNS-зони ви не можете створити публічно розпізнаваний субдомен.

Чи впливає субдомен на SEO кореневого домену?

Це залежить від зв’язку вмісту та внутрішніх посилань. Google може асоціювати субдомен із кореневим доменом, але вага посилань передається не так вільно, як між URL підкаталогів. Для вмісту, тісно інтегрованого з основним сайтом, підкаталог зазвичай є кращим вибором з точки зору SEO. Для окремих застосунків або тестових середовищ субдомен є правильним вибором і має бути закритий від noindex, якщо не призначений для публічного пошуку.

Скільки субдоменів можна створити під одним доменом?

Специфікація DNS не встановлює практичного обмеження на кількість субдоменів. Реєстратори та панелі хостингу можуть встановлювати м’які обмеження, але вони є адміністративними, а не технічними. Один домен може мати сотні субдоменів.

У чому різниця між wildcard DNS-записом і wildcard SSL-сертифікатом?

Wildcard DNS-запис (*.example.com) маршрутизує всі невизначені субдомени до єдиної IP-адреси на рівні DNS. Wildcard SSL-сертифікат (*.example.com) захищає всі субдомени першого рівня на рівні TLS. Вони є незалежними: можна мати одне без іншого, але обидва необхідні для обслуговування всіх субдоменів через HTTPS без індивідуального отримання сертифікатів.

Чому мій субдомен правильно розпізнається в dig, але повертає помилку браузера?

Розпізнавання DNS і обслуговування HTTP є окремими рівнями. Якщо dig повертає правильну IP-адресу, але браузер показує помилку, веб-сервер на цій IP-адресі не налаштований для обробки запитів для цього імені хоста (server_name в Nginx або ServerName в Apache). Додайте відповідний блок віртуального хоста та перезавантажте веб-сервер.