Как добавить субдомен к вашему домену

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 — отдельный контекст аутентификации и сессионные cookies.
• Региональные или языковые сайты: 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 проверки.

Шаг 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 проверка)

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) или более длительный срок действия, подходит коммерческий сертификат от доверенного центра сертификации. 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 для рабочих субдоменов.

Утечка области действия cookies: Если ваше приложение устанавливает cookies для .example.com (обратите внимание на ведущую точку), эти cookies отправляются на все субдомены. Это может раскрыть токены сессий с высокозащищённого субдомена менее защищённому. Явно ограничивайте область действия cookies конкретным именем хоста.

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

Для высоконагруженных приложений, требующих полного 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.
• Корректно ли определены области действия cookies? Явно задавайте атрибут Domain для cookies, чтобы предотвратить нежелательный обмен между субдоменами.

Часто задаваемые вопросы

Можно ли создать субдомен без доступа к 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). Добавьте соответствующий блок виртуального хоста и перезагрузите веб-сервер.