Ошибки DNS при подключении домена: разбор A/AAAA/CNAME, TTL и конфликтов записей, плюс быстрая диагностика за 10 минут и причины сбоев SSL.
Собственный домен решает простую задачу: чтобы проект открывался по привычному адресу (например, mysite.ru) и работал с HTTPS. На практике сбои почти всегда связаны не с платформой, а с DNS-настройками или ожиданием, пока изменения разойдутся.
Чаще всего проблема выглядит так: сайт не открывается, открывается "не тот" сайт (старый хостинг, парковочная страница регистратора), или все работает по HTTP, но HTTPS не включается, и браузер ругается на сертификат. Еще один частый сценарий - открывается главная страница, а поддомен (например, app.mysite.ru) ведет в никуда.
Важно быстро понять, где ошибка: в DNS или в приложении. Если домен указывает на неправильный IP или на чужое имя, приложение может быть полностью исправным, но запросы до него просто не доходят. И наоборот: если DNS уже указывает верно, а вы видите 500-ю ошибку или пустую страницу, тогда стоит проверять деплой и настройки самого проекта.
Без глубоких знаний можно сделать несколько быстрых проверок:
На TakProsto это обычно проявляется так: вы подключили домен к проекту, но в браузере продолжает открываться старый сайт или сертификат не выпускается. В большинстве случаев это решается за несколько минут: достаточно проверить записи и убрать конфликтующие настройки.
Многие ошибки DNS при подключении домена начинаются с путаницы в простых вещах: что именно вы подключаете и куда должны вести записи.
Домен в корне - это адрес без префикса, например example.ru. Поддомен - любая приставка слева: www.example.ru, app.example.ru, api.example.ru. Важно: example.ru и www.example.ru - разные адреса, и DNS для них настраивается отдельно. Частая ошибка - подключить только www и удивляться, что без www сайт не открывается (или наоборот).
DNS-запись - это строка в настройках регистратора (или DNS-провайдера), которая говорит: "когда кто-то спрашивает этот адрес, отвечай вот так". Ответом может быть IP-адрес или другое имя хоста - зависит от того, что требует сервис.
Обычно сервис для подключения домена дает одно из двух: IP-адрес (тогда нужна A-запись, иногда еще AAAA для IPv6) или имя хоста вида something.service.com (тогда чаще нужен CNAME для поддомена). Часто также уточняют, что именно привязывать (корень, www или оба) и сколько ждать обновления.
Почему изменения не применяются мгновенно: DNS кэшируется. У записей есть TTL - время, на которое результат сохраняют провайдеры, устройства и сети. Если TTL был большим, вы исправили запись, а часть мира еще несколько часов видит старую версию.
Пример: вы подключаете кастомный домен к приложению в TakProsto и получаете имя хоста для CNAME. Если по ошибке внести его в корень домена (где CNAME часто нельзя использовать) или забыть настроить www, часть пользователей попадет не туда. Дальше начинаются вторичные симптомы: проблемы со страницей и выпуском сертификата.
Большая часть "магии" с доменом сводится к тому, что выбран не тот тип записи. Из-за этого возникают ошибки DNS при подключении домена: сайт открывается не там, где нужно, или сертификат так и не выпускается.
A-запись указывает IPv4-адрес сервера. Она нужна, когда сервис просит: "впишите IP" или когда вы подключаете корень домена (example.ru) к конкретному хостингу. Проверяющие системы идут по этому IP и ожидают увидеть ваш сайт.
AAAA-запись делает то же самое, но для IPv6. Если ваш сервер не настроен на IPv6, AAAA может мешать: часть пользователей пойдет по IPv6 и увидит таймаут или чужую страницу. Типичный симптом: "у одних открывается, у других нет". В таком случае либо настраивают IPv6, либо временно убирают AAAA.
CNAME говорит: "этот поддомен равен другому имени". Он удобен для www, потому что вы привязываетесь к имени сервиса, а не к IP. Но у корня домена (example.ru) CNAME часто нельзя поставить у многих регистраторов и DNS-панелей: корень должен содержать служебные записи (SOA, NS), и CNAME там конфликтует.
Практичная схема, которая подходит в большинстве случаев:
example.ru): A (и AAAA - только если IPv6 точно работает)www: CNAME на имя, которое дает сервисКак выбрать по инструкции сервиса (например, при подключении своего домена в TakProsto или похожих платформах)? Если дали IP - ставьте A. Если дали "target" в виде имени (что-то вроде app.vendor.example) - ставьте CNAME для поддомена. Если в инструкции явно не сказано про IPv6, не спешите добавлять AAAA: лишняя запись чаще ломает, чем помогает.
TTL (time to live) - это время, на которое DNS-ответ можно сохранить в кэше. Проще: вы поменяли запись, а кто-то еще видит старую, потому что она не "протухла".
У каждой записи (A, AAAA, CNAME) свой TTL. Если TTL был 3600 секунд, то до часа разные устройства и сети могут получать разные ответы. Из-за этого кажется, что "DNS не работает", хотя изменения уже разошлись частично.
Кэш бывает в нескольких местах: на вашем компьютере, на домашнем роутере, у DNS-сервера провайдера, иногда в корпоративной сети. Даже браузер может показывать старую картину из-за кэша соединений и HSTS, особенно когда вы параллельно проверяете выпуск сертификата.
Поэтому выводы по одному устройству или одной сети часто ошибочны. Типичный сценарий: домен для приложения (например, на TakProsto с подключенным собственным доменом) на телефоне по мобильной сети уже открывается, а на рабочем ноутбуке в офисе еще ведет на старый сервер.
Минимум проверьте в двух разных сетях, а при сомнениях - добавьте третью. Инкогнито помогает как быстрый способ убрать часть браузерного кэша, но DNS-кэш оно не отменяет.
Если планируется перенос домена или смена IP, TTL лучше уменьшить заранее. Делать это за 5 минут до переключения обычно бесполезно: старое значение уже разошлось и попало в кэши.
Практичный порядок:
Так вы сокращаете окно, когда часть пользователей видит старые записи, и быстрее доходите до выпуска SSL, которому нужен правильный DNS-ответ "прямо сейчас".
Большая часть "магии" с доменом на самом деле сводится к конфликтам. Из-за них один и тот же адрес то открывается, то нет, а выпуск SSL может зависать. Это классические ошибки DNS при подключении домена: записи выглядят "почти правильно", но DNS выбирает не то, что вы ожидаете.
Самый жесткий запрет: на одном и том же имени нельзя держать CNAME и любые другие записи (A, AAAA, MX, TXT). Если www сделан CNAME на ваш хост, то у www не должно быть A или AAAA.
Вторая частая причина - дубли A-записей с разными IP "на всякий случай". Тогда часть пользователей попадает на старый сервер (или на парковку), а часть - на новый.
Третья путаница - @ (корень домена) и www. Настраивают только www, а корень оставляют на старом IP. В результате по одному адресу все работает, по другому - нет.
Откройте список записей и быстро проверьте:
@ и www, и ведут ли они туда, куда нужноwww.example.com вместо www)Если подключаете домен к проекту на TakProsto (кастомный домен и SSL), конфликты часто выглядят одинаково: домен добавлен в панели, но проверка не проходит, потому что запросы реально уходят на другой IP или на имя, которое конфликтует с лишними записями.
После правки удалите лишнее, оставьте один понятный вариант для каждого имени и дождитесь обновления с учетом TTL.
Когда SSL-сертификат "не выпускается", почти всегда проблема не в сертификате, а в том, что проверка владения доменом не может пройти. Центр сертификации пытается обратиться к вашему домену и убедиться, что он ведет на правильный сервер и отвечает ожидаемым образом.
Сертификат выпускается не на тот хост. Вы настроили example.ru, а проверяете www.example.ru (или наоборот). Для SSL это разные имена. Если в настройках платформы (например, при подключении кастомного домена в TakProsto) указан один вариант, а DNS ведет на другой, проверка легко "промахнется".
Домен еще не указывает на нужный сервер из-за DNS или кэша. Вы поменяли A/AAAA/CNAME, но часть резолверов еще видит старый адрес. В итоге проверка может попадать то на новый сервер, то на старый.
Включен прокси или защита у DNS-провайдера. Некоторые режимы "оранжевого облака", антибота или принудительной фильтрации подменяют ответы и мешают проверке владения.
Сервер не отдает корректный ответ именно для этого домена. Например, хостинг принимает запросы только на технический домен, а ваш домен не добавлен в конфигурацию. Тогда вместо сайта отдается 404, заглушка или чужая страница.
Редиректы мешают выпуску. Часто включают принудительный редирект с HTTP на HTTPS еще до получения сертификата. Получается замкнутый круг: HTTPS требует сертификат, а сертификат не выпускается, потому что проверка не проходит по HTTP.
Перед повторной попыткой полезно сделать короткую самопроверку:
www и без - это разные варианты)Если домен не открывается или "сертификат не выпускается", чаще всего это обычные ошибки DNS при подключении домена. Ниже - план, который реально уложить в 10 минут.
Запишите, какие адреса должны работать: корень (example.ru), www, и только потом остальные поддомены (api, app и т.д.). Каждый хост настраивается отдельно.
Откройте DNS-зону у регистратора (или в DNS-провайдере) и посмотрите записи именно для этих имен. Сразу ищите конфликты: на одном имени не должно быть CNAME вместе с A/AAAA. Обратите внимание и на "забытые" записи от прошлого хостинга.
Сравните текущие значения с тем, что требует сервис. Например, в TakProsto в настройках домена обычно указан конкретный IP для A-записи или целевой хост для CNAME. Если отличается хотя бы символ - домен уйдет не туда.
Отдельно проверьте AAAA. Если у сервиса нет поддержки IPv6, но у вас есть AAAA, часть пользователей будет ходить по IPv6 и видеть ошибки, даже если A-запись верная.
Посмотрите TTL у измененных записей. Если TTL 3600, то ситуация "все исправил, а не работает" часто объясняется кэшем. Зафиксируйте время изменения и подождите хотя бы один TTL перед повторной проверкой.
Затем проверьте из другой сети: переключитесь на мобильный интернет или попросите коллегу посмотреть у себя. Так вы отсечете локальный кэш и поймете, проблема в DNS или в конкретном устройстве.
Для контроля удобно использовать nslookup (Windows) или dig (macOS/Linux) и сравнить ответы для A/AAAA/CNAME с тем, что вы ожидаете увидеть.
Большая часть проблем при подключении домена выглядит как "DNS уже настроил, а сайт то открывается, то нет" или "сертификат не выпускается". Обычно причина простая: запись выбрана не та, правки сделаны не там, где нужно, или изменения еще не успели разойтись.
Одна из самых дорогих по времени ошибок - пытаться поставить CNAME на корень домена (example.ru). Многие DNS-панели это запрещают или делают через "ALIAS/ANAME", а пользователь думает, что все в порядке. Для корня чаще нужен A (и иногда AAAA), а CNAME удобнее для поддоменов вроде www.
Вторая типовая ловушка - "мусор" из старых записей. Вы поменяли A-запись, но рядом остался AAAA на старый IPv6 или старый CNAME для того же имени. В итоге часть резолверов отвечает по одной записи, часть - по другой, и поведение кажется случайным.
Еще одна частая ошибка: путают регистратора и DNS-хостинг. Домен куплен у одного провайдера, а NS указывает на другой, но правки делают в панели регистратора. В реальности зона обслуживается там, куда смотрят NS.
И последнее, что ломает ожидания: сервис проверяет конкретное имя хоста. Если вы подключаете custom domain в TakProsto, проверка и выпуск SSL обычно идут для точного FQDN (например, app.example.ru), а не "для всего домена".
Если свести самые затратные ошибки к короткому списку, обычно это:
www настроены по-разному, хотя должны вести в один проектexample.ru, а сервис ожидает www.example.ru)Хорошее правило: сначала добейтесь стабильного ответа DNS для нужного хоста, и только потом переходите к SSL.
Перед тем как нажимать "выпустить SSL" (в TakProsto это обычно шаг после привязки домена), стоит потратить 2-3 минуты на короткую проверку.
@) задан правильный тип и значение. Чаще всего это A-запись на нужный IP.www выбран один понятный сценарий: обычно CNAME на целевое имя, которое выдает сервис.Список доменов в сертификате должен совпадать с тем, что реально настроено в DNS. Если вы хотите сертификат на example.ru и www.example.ru, то оба имени должны вести на ваш проект. Частый провал: настроили только @, а www забыли, но в заявке на сертификат он есть.
Мини-сценарий: домен открывается без www, а с www показывает старый сайт. Почти всегда это отдельная запись для www (или конфликт), а не "проблема SSL".
Клиент переносил сайт на новый проект и хотел подключить domen.ru и www.domen.ru. Раньше домен вел на старый VPS, а теперь проект развернули на TakProsto и включили свой домен в настройках.
Допустили типичную ошибку: для корня (@) оставили старую A-запись на прежний IP, а для www добавили CNAME на новый адрес. В итоге DNS стал вести в две разные стороны. Часть людей открывала domen.ru и видела старый сайт, а часть заходила на www.domen.ru и попадала уже на новый. Из-за этого HTTPS тоже не включался: проверка домена для сертификата то попадала на старый сервер, то на новый.
Симптомы были такие:
www работает одно, с www - другоеИсправление заняло несколько минут. Сначала удалили лишние и конфликтующие записи у DNS-провайдера: оставили один понятный вариант для @ и настроили www так, чтобы он вел туда же (обычно через CNAME на целевое имя или через одинаковую A-запись, если так требует платформа). Дополнительно проверили AAAA: если он указывает на старый IPv6, часть клиентов будет ходить именно туда.
После правок просто дождались TTL. Пока кэш не обновился, "плавающее" поведение сохранялось. Через некоторое время и domen.ru, и www.domen.ru стали открывать один и тот же проект, а выпуск SSL прошел без сюрпризов.
Когда DNS уже "починили", легко расслабиться, а потом снова наступить на те же грабли. Лучше потратить еще 10 минут и закрепить результат, чтобы ошибки DNS при подключении домена не повторялись при следующем деплое или переносе.
Сначала зафиксируйте базовые требования: какие имена подключаете (например, example.ru и www.example.ru), какая запись нужна для каждого (A/AAAA или CNAME), и где именно редактируете DNS (панель регистратора, DNS-хостинг, корпоративный провайдер). Один домен часто "живет" у регистратора, а DNS управляется в другом месте - это главный источник путаницы.
Дальше планируйте изменения с учетом TTL. Если меняете записи в рабочее время, заложите окно, когда старый кэш еще будет гулять. Для важных переключений удобно заранее уменьшить TTL (например, за сутки), затем менять A/AAAA/CNAME и после стабилизации вернуть TTL обратно.
Не торопитесь запускать SSL сразу после правок. Сертификат логично выпускать только когда DNS стабилизировался: нужные записи видны в нескольких проверках подряд, и нет конфликтов (например, A и CNAME на одном имени).
Чтобы не собирать настройки каждый раз с нуля, заведите простой шаблон: какие хосты нужны (корень, www, API-поддомен), тип записи и целевое значение для каждого, нужен ли IPv6, какой TTL и какое "окно ожидания", а также кто отвечает за DNS и кто подтверждает результат.
Если вы часто запускаете проекты, помогает единый процесс развертывания. В TakProsto домен обычно подключают уже к развернутому приложению, а дальше удобно контролировать релизы: сделали деплой, проверили, и если после смены DNS или выпуска сертификата что-то пошло не так, можно быстро откатиться через снапшоты и rollback. Для справки и внутренних заметок удобно просто держать в одном месте данные проекта и домена, например в аккаунте TakProsto на takprosto.ai.
Простой пример: вы подключили www через CNAME, но забыли, что для корня домена нужен A/AAAA. Запишите это правило в шаблон, и в следующий раз настройка займет минуты, а не вечер.
Сначала проверьте, куда реально указывает DNS сейчас: часто корень домена или www все еще ведут на старый IP или парковку регистратора. Если в TakProsto домен уже добавлен, а в браузере открывается «старый сайт», почти всегда проблема в A/CNAME-записях, а не в проекте.
Корень домена (example.ru) и www.example.ru — разные имена, у них разные DNS-записи. Надежный вариант: настроить оба так, чтобы они вели в один и тот же проект, и затем проверять именно те адреса, которые добавлены в настройках домена в TakProsto.
Если сервис выдал IP-адрес, нужна A-запись (и AAAA только если у вас точно настроен IPv6). Если сервис выдал «целевое имя» хоста, обычно нужен CNAME для поддомена (например, www). Ошибка в типе записи приводит к тому, что запросы не доходят до вашего проекта.
Частая причина — лишняя AAAA-запись на IPv6, который у хостинга не обслуживается. Тогда часть устройств выбирает IPv6 и получает таймаут, а часть идет по IPv4 и открывает сайт. Если вы не уверены в IPv6, временно уберите AAAA и проверьте стабильность.
DNS кэшируется по TTL, поэтому после правки записей часть сетей еще видит старые значения. Дайте времени хотя бы один TTL, а при проверке используйте две разные сети (например, домашний интернет и мобильный). Это быстро показывает, проблема в кэше или в самих записях.
На одном имени нельзя держать CNAME вместе с A/AAAA/TXT/MX: DNS будет работать непредсказуемо или не работать вовсе. Еще типичная ошибка — несколько A-записей на разные IP «на всякий случай», из-за чего трафик разъезжается. Оставьте один понятный вариант для каждого имени и удалите конфликтующие записи.
Почти всегда проверка владения доменом не проходит, потому что домен еще не стабильно резолвится на нужный адрес или настроено не то имя (@ вместо www или наоборот). Также мешают прокси-режимы и защиты у DNS-провайдера, которые подменяют ответы. Сначала добейтесь стабильного DNS для нужного FQDN, и только потом повторяйте выпуск SSL в TakProsto.
Часто причина не в DNS, а в деплое: если DNS уже указывает правильно, но вы видите 500-ю ошибку, пустую страницу или заглушку, значит запросы до приложения доходят. В этом случае проверяйте статус деплоя, логи и настройки домена внутри проекта, а не записи у регистратора.
Убедитесь, что редактируете DNS именно там, куда делегирован домен: смотрите NS-серверы и правьте зону у того провайдера, который их обслуживает. Если домен куплен у одного регистратора, а DNS ведется у другого, изменения в «не той» панели никак не повлияют на реальный ответ DNS.
Сначала закрепите схему: какие имена подключаете (@, www, нужные поддомены) и какие записи для них должны быть. Перед переносами заранее уменьшайте TTL, а после стабилизации возвращайте его обратно. Если после изменения домена или SSL что-то пошло не так, в TakProsto удобно откатить проект на предыдущий снимок и быстро восстановить рабочее состояние, пока DNS «догоняет».