Піддомен — це частина URL перед основним доменом: blog.example.com, shop.example.com. Піддомени дозволяють розділити різні частини сайту або створити окремі проєкти без купівлі нового домену.

Для чого використовуються піддомени

Піддомен	Типове використання
www.example.com	Основний сайт (історично)
blog.example.com	Блог на окремій CMS
shop.example.com	Інтернет-магазин
api.example.com	API-ендпоінти
mail.example.com	Веб-пошта
staging.example.com	Тестове середовище
cdn.example.com	Роздача статики

Створення піддомену в cPanel

Увійдіть у cPanel → Domains → Subdomains
У полі «Subdomain» введіть: blog
Виберіть основний домен зі списку
Вкажіть папку (Document Root): public_html/blog
Натисніть Create

cPanel автоматично створює DNS A-запис для піддомену.

Ручне створення через DNS

Якщо керуєте DNS самостійно (Cloudflare тощо):

# A-запис (прямий IP)
blog    IN    A    192.168.1.100

# CNAME (псевдонім основного домену)
shop    IN    CNAME    example.com.

# Wildcard — усі піддомени
*       IN    A    192.168.1.100

💡 Коли CNAME замість A: Використовуйте CNAME, якщо IP може змінюватися (CDN, балансувальник навантаження). Для фіксованого сервера — A-запис надійніший.

Wildcard-піддомени

Wildcard (*.example.com) дозволяє створювати необмежену кількість піддоменів без додавання окремих DNS-записів. Корисно для SaaS-платформ, де кожен користувач отримує username.example.com.

⚠️ SSL для Wildcard: Звичайний SSL-сертифікат не покриває піддомени. Потрібен Wildcard SSL (*.example.com) або Let's Encrypt з DNS-challenge.

Піддомени та SEO

Google індексує піддомени як окремі сайти. Якщо блог важливий для SEO основного сайту — краще розмістити його в підпапці (example.com/blog/), а не на піддомені. Піддомени втрачають передачу авторитету від основного домену.

Створення піддомену в DNS

Додайте A-запис у панелі керування DNS:

Тип	Ім'я	Значення	TTL
A	blog	YOUR_SERVER_IP	300
A	api	YOUR_SERVER_IP	300
CNAME	www	yourdomain.com	300

Налаштування Nginx для піддомену

server {
    listen 80;
    server_name blog.yourdomain.com;
    root /var/www/blog;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

SSL для піддомену

# Окремий сертифікат
certbot --nginx -d blog.yourdomain.com

# Wildcard-сертифікат (для всіх піддоменів)
certbot certonly --dns-cloudflare   -d yourdomain.com   -d "*.yourdomain.com"

💡 Wildcard-сертифікат * .domain.com покриває всі піддомени першого рівня: blog.domain.com, api.domain.com, але не sub.blog.domain.com.

Часті помилки під час налаштування піддоменів

Три джерела майже всіх проблем із піддоменами — не та DNS-зона, не той SSL-сертифікат і конфлікт конфігів вебсервера.

NXDOMAIN

Така відповідь dig на запит піддомену майже завжди означає, що запис додано не в тій DNS-зоні: наприклад, у панелі DNS хостингу, поки домен реально керується через NS реєстратора чи Cloudflare. Перевірте, у кого зараз авторитетні NS-сервери домену: dig example.com NS +short, і додавайте запис саме там.

NET::ERR_CERT_COMMON_NAME_INVALID

Сертифікат випущений для example.com, а піддомен blog.example.com до нього не входить. Звичайний SSL від Let's Encrypt покриває лише ті імена, що вказані явно під час випуску — для нового піддомену потрібен або окремий сертифікат, або перевипуск із доданим іменем, або Wildcard-сертифікат.

nginx: [emerg] duplicate default server for 0.0.0.0:80

У новому конфігу для піддомену випадково продубльований параметр default_server, який уже вказаний у конфігу основного сайту. На одну IP-адресу і порт може бути лише один default_server — приберіть директиву з усіх блоків, крім одного.

Піддомен чи підпапка: порівняння

Параметр	Піддомен	Підпапка
Передавання SEO-ваги від основного домену	Обмежена	Повна
Окремий SSL-сертифікат	Потрібен свій або Wildcard	Не потрібен
Окрема CMS чи технології	Легко	Складніше (спільний рушій)
Налаштування CDN окремо	Можлива	Спільна для всього домену

Для блогу, який має підсилювати позиції основного сайту, зазвичай обирають підпапку. Для функціонально незалежного проєкту (особистий кабінет, магазин на іншому рушії) — піддомен, попри втрату частини SEO-ваги.

Коли піддомени не підходять

Деякі тарифи віртуального хостингу обмежують кількість піддоменів — перевірте ліміт тарифу в лімітах і ресурсах хостингу, перш ніж проєктувати архітектуру на десятках піддоменів. Wildcard-піддомени (*.example.com) для SaaS з користувацькими іменами потребують Wildcard SSL і акуратної обробки на рівні застосунку — якщо очікується лише 2–3 піддомени, Wildcard надлишковий, простіше випустити звичайні сертифікати на кожен.

Як перевірити результат

Перевіряйте DNS і вебсервер окремо — це одразу показує, де саме проблема:

# Переконатися, що піддомен резолвиться в потрібну IP-адресу
dig blog.example.com A +short

# Перевірити, що Nginx віддає правильний конфіг для цього імені
curl -I -H "Host: blog.example.com" http://YOUR_SERVER_IP/

# Перевірити сертифікат для конкретного піддомену
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject

Друга команда з явним заголовком Host перевіряє маршрутизацію Nginx напряму за IP, в обхід DNS — це відрізняє проблему з DNS від проблеми з конфігом вебсервера. Якщо через IP приходить контент не того сайту, річ у server_name, а не в DNS-записі.