Как да добавите поддомейн към вашия домейн

Един поддомейн е префикс, добавен към основния домейн, който създава отделно, независимо адресируемо пространство от имена под същото домейн име. Например, при основен домейн example.com, хостнеймът blog.example.com е напълно квалифициран поддомейн, където blog е етикетът от трето ниво. Поддомейните се разрешават чрез DNS записи — обикновено A запис, сочещ към IPv4 адрес, AAAA запис за IPv6, или CNAME запис, псевдонимизиращ друг хостнейм — и не изискват допълнителна такса за регистрация на домейн.

От практическа гледна точка, поддомейните ви позволяват да стартирате отделни уеб приложения, среди за тестване, регионални сайтове или микроуслуги под един регистриран домейн, с независими document root директории, SSL сертификати и сървърни конфигурации. Това ръководство обхваща пълния технически процес: създаване на DNS записи, конфигуриране на хостинг, издаване на SSL, проверка на разпространението и често срещани грешки, които повечето ръководства пропускат.

Какво е поддомейн и как се различава от поддиректория

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

John Mueller от Google потвърди, че Google като цяло третира поддомейните като част от същия сайт, когато съдържанието е явно свързано, но поведението по отношение на crawl бюджета, индексирането и прехвърлянето на link equity може да се различава. За тясно интегрирано съдържание, като например корпоративен блог, поддиректорията е често по-лесният избор. За отделно приложение — клиентски портал, API шлюз или тестова среда — поддомейнът е правилното архитектурно решение.

Чести случаи на употреба на поддомейни

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

Стъпка 1: Достъп до интерфейса за управление на DNS

DNS записите за даден домейн се управляват там, където са хостнати авторитативните nameserver-и на домейна. Това не винаги е същото място като вашия уеб хостинг. Авторитативният nameserver се определя от NS записите при вашия регистратор на домейни.

Определете къде се управлява вашият DNS:

dig NS example.com +short

Ако изходът показва nameserver-и, принадлежащи на вашия регистратор (напр. ns1.registrar.com), управлявайте DNS при регистратора. Ако показва nameserver-и, принадлежащи на хостинг доставчик или услуга като Cloudflare, управлявайте DNS там.

След като сте идентифицирали правилния контролен панел:

1. Влезте в интерфейса за управление на DNS.
2. Намерете секцията DNS Zone Editor, DNS Management или Zone File.
3. Изберете домейна, за който искате да създадете поддомейна.

Ако вашият домейн е регистриран чрез Регистрация на домейни в AlexHost, редакторът на DNS зони е достъпен директно от таблото на вашата клиентска зона.

Стъпка 2: Създаване на DNS запис за поддомейна

Ще създадете един от три типа записи в зависимост от вашата инфраструктура.

A запис — насочване към IPv4 адрес

Използвайте A запис, когато поддомейнът се разрешава до конкретен IP адрес на сървър. Това е най-честият сценарий за поддомейни, хостнати на VPS или Dedicated Server.

Критичен детайл: Въведете само етикета на поддомейна в полето Име — 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 запис за поддомейн

Wildcard A запис разрешава всеки недефиниран поддомейн до единичен IP:

Това е полезно за multi-tenant SaaS приложения, където всеки клиент получава поддомейн (напр. customer1.example.com). Имайте предвид, че wildcard DNS записът не осигурява автоматично SSL за всеки поддомейн — необходим ви е wildcard SSL сертификат или ACME клиент, поддържащ DNS-01 предизвикателства.

Стъпка 3: Конфигуриране на уеб сървъра или хостинг панела

Създаването на DNS запис прави поддомейна разрешим, но не обслужва автоматично съдържание. Трябва да конфигурирате уеб сървъра или хостинг панела да приема и маршрутизира заявки за новия хостнейм.

Конфигуриране на поддомейн в cPanel

Ако вашият хостинг използва cPanel — наличен в плановете VPS с cPanel — процесът е:

1. Влезте в cPanel.
2. Навигирайте до Domains > Subdomains.
3. В полето Subdomain въведете етикета (напр. blog).
4. Изберете основния домейн от падащото меню.
5. Задайте Document Root — cPanel по подразбиране използва public_html/blog, но можете да посочите произволен път.
6. Кликнете Create.

cPanel автоматично създава DNS A запис в BIND зоната на WHM, ако DNS на домейна се управлява локално. Ако DNS се управлява външно (напр. Cloudflare), трябва да добавите записа там ръчно, както е описано в Стъпка 2.

Конфигуриране на поддомейн в Nginx

За VPS, работещ с Nginx, създайте нов server block:

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 — Let’s Encrypt Wildcard сертификат (DNS-01 предизвикателство)

Wildcard сертификатът покрива *.example.com, осигурявайки всички настоящи и бъдещи поддомейни с един сертификат. Това изисква верификация чрез DNS-01 предизвикателство:

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 не влизат в сила глобално в момента, в който ги запазите. Всеки resolver кешира записите за продължителността на TTL стойността. При TTL от 3600, resolver-ите могат да обслужват стария запис до един час след като направите промяна.

Проверете разпространението от множество глобални точки:

# 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 или отказана връзка. Причина: уеб сървърът няма виртуален хост, съответстващ на хостнейма на поддомейна. Решение: добавете server block или виртуален хост, както е описано в Стъпка 3.

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

cPanel създава локален DNS запис, но DNS се управлява външно: При използване на Cloudflare или друг външен DNS доставчик с cPanel хостинг, съветникът за поддомейни на cPanel създава запис в локалната BIND зона на WHM, която никога не се консултира. Трябва да добавите A записа ръчно в Cloudflare (или вашия външен DNS доставчик). Това е един от най-честите източници на объркване за потребителите на споделен хостинг.

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

Изтичане на обхвата на бисквитките: Ако вашето приложение задава бисквитки на .example.com (обърнете внимание на водещата точка), тези бисквитки се изпращат до всички поддомейни. Това може да изложи токени за сесии от поддомейн с висока сигурност на по-малко защитен. Задавайте обхвата на бисквитките изрично за предвидения хостнейм.

Управление на поддомейни в различни хостинг среди

За приложения с висок трафик, изискващи пълен root достъп и персонализирани сървърни конфигурации, Dedicated Server ви дава пълен контрол върху DNS, уеб сървърния софтуер и управлението на сертификати без ограниченията на споделена среда.

Контролен списък за технически решения

Преди да създадете поддомейн, преминете през следното:

• Къде са авторитативните nameserver-и? Изпълнете 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.
• Правилно ли са дефинирани обхватите на бисквитките? Задайте изрично атрибута Domain на бисквитките, за да предотвратите нежелано споделяне между поддомейни.

Често задавани въпроси

Мога ли да създам поддомейн без достъп до DNS на основния домейн?

Не. Поддомейнът изисква DNS запис (A, AAAA или CNAME) в зоната на основния домейн. Без право на запис в авторитативната DNS зона, не можете да създадете публично разрешим поддомейн.

Влияе ли поддомейнът на SEO на основния домейн?

Зависи от връзката между съдържанието и вътрешното свързване. Google може да асоциира поддомейн с основния домейн, но link equity не се прехвърля толкова свободно, колкото между 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). Добавете подходящия блок за виртуален хост и презаредете уеб сървъра.