Контрольный список устранения неполадок пользовательского домена для DNS и SSL

Что обычно скрывается за «пользовательский домен не работает»

«Пользовательский домен не работает» — это собирательная фраза для нескольких разных сбоев. Браузер показывает симптом, а не причину. Прежде чем что‑то менять, опишите, что вы фактически видите.

Типичные симптомы включают:

• Страницу «домен не найден»
• Домен загружает не тот сайт
• Предупреждение о небезопасном соединении, хотя HTTPS включён
• Петли перенаправлений (перескакивание между http и https или между корнем и www)

Чаще всего проблема в одном из пунктов:

• DNS указывает не туда или нужной записи нет
• Цель хостинга не настроена на это имя хоста (сервер не распознаёт ваш домен)
• SSL ещё не выпущен, выпущен не для этого имени или не может быть выпущен из‑за несоответствия DNS
• Кеширование скрывает ваши изменения (кеш браузера, кеш резолвера DNS или старые значения TTL)

Перед началом устранения неполадок убедитесь, что у вас есть доступ к двум местам: где вы редактируете DNS‑записи (регистратор или провайдер DNS) и где вы привязываете домен на стороне хостинга. Например, если вы подключаете задеплоенное приложение на Koder.ai к кастомному домену, вам нужен доступ к DNS домена и к настройкам домена в панели приложения.

Некоторые исправления мгновенные (например, исправление опечатки). Другие требуют времени. Изменения DNS могут долго распространяться, и SSL обычно не завершится, пока DNS не начнёт корректно резолвиться и домен не станет доступен. Цель — перестать гадать и поочерёдно подтвердить каждый уровень.

Простые концепции DNS, которые имеют значение (без жаргона)

Большинство проблем с доменами сводится к несоответствию между (1) именем хоста, которое вы проверяете, (2) где управляется DNS, и (3) куда фактически указывает запись. Когда эти три вещи совпадают, SSL обычно остаётся последним шагом.

Домены обычно бывают в двух формах: корневой домен (example.com, также называемый apex) и поддомены (www.example.com, app.example.com). Это связанные, но отдельные DNS‑записи. Поэтому нормально, когда www работает, а апекс нет, или наоборот.

Nameserver‑ы решают, кто отвечает за вашу DNS‑зону. Если вы купили домен у одной компании, но nameserver‑ы указывают на другую, нужно редактировать DNS там, куда указывают nameserver‑ы. Многие ситуации «я обновил, но ничего не поменялось» возникают потому, что записи правили в неправильной панели.

Типы DNS‑записей простыми словами

Вот что делают основные типы записей:

• A: указывает имя на IPv4‑адрес (например, 203.0.113.10)
• AAAA: указывает имя на IPv6‑адрес
• CNAME: перенаправляет имя на другое доменное имя (часто для www)
• TXT: хранит текст для верификации и безопасности (проверки владельца, SPF и т.п.)

TTL — это «как долго кешировать ответ». Низкий TTL означает, что кешы обновляются быстрее. Высокий TTL значит, что придётся ждать дольше, даже после исправления записи. Наблюдать старое значение некоторое время — нормально.

Пошагово: простое дерево решений для изоляции причины

Когда пользовательский домен не работает, обычно проблему можно отнести к одной из четырёх категорий: DNS не резолвится, DNS указывает не туда, SSL не готов, или проблема возникает у некоторых пользователей из‑за кеширования.

Используйте это дерево решений:

1. Домен вообще резолвится? Если вы видите NXDOMAIN (или «домен не найден»), запись отсутствует, вы правите не ту DNS‑зону или nameserver‑ы не те, что вы думаете.
2. Если резолвится, указывает ли он на правильную цель? Если страница загружается, но это не ваш сайт, страница парковки или старый сервер, значит A/AAAA/CNAME‑цель неверна или какая‑то старая запись имеет приоритет.
3. Если указывает правильно, проблема только в HTTPS? Если по HTTP всё работает, а по HTTPS — предупреждение сертификата, SSL может ещё выдаваться, имя хоста в сертификате может не совпадать, или платформа ждёт, пока DNS устаканится.
4. Работает на одном устройстве или сети, но не на другом? Считайте это кешированием или распространением.
5. Перенаправления ломаются (www против апекса)? Если www работает, а корень нет (или наоборот), вероятно настроено только одно имя хоста или есть конфликтующие правила редиректа.

Двигайтесь быстрее, записав точное имя хоста, которое падает (apex vs www) и точное сообщение об ошибке. На платформах, которые автоматизируют домены и сертификаты, различие между «не найден хост» и «сертификат ожидается» подскажет, нужно ли править DNS‑записи или просто ждать SSL после того, как DNS станет видимым.

Шаг 1: подтвердите имя хоста и ожидаемую цель

Множество ошибок начинаются с простой рассинхронизации: вы настроили DNS для одного имени хоста, а тестируете другое.

Сначала запишите точное имя хоста, которое хотите сделать рабочим. Корневой домен выглядит как example.com. Поддомен — как www.example.com или app.example.com. Это отдельные DNS‑записи, так что «www работает» не означает, что корень тоже будет.

Далее найдите ожидаемую цель в панели вашего хоста. Некоторые платформы дают IP‑адрес (для A или AAAA). Другие дают имя хоста (для CNAME). Если хост предоставляет значение в экране настройки домена, считайте его источником истины.

Прежде чем что‑то менять, зафиксируйте текущие настройки. Делайте просто:

• Скопируйте текущие DNS‑записи для имени хоста, которое меняете
• Запишите все существующие A, AAAA, CNAME и TXT записи
• Зафиксируйте TTL

Также подтвердите, что вы редактируете нужную DNS‑зону. Легко обновить неверный домен, неправильную среду или чужой аккаунт провайдера.

Шаг 2: выберите правильный тип записи (A, AAAA, CNAME, TXT)

Многие проблемы — просто неправильный тип записи для того имени хоста, которое вы пытаетесь подключить. Начните с разделения на два случая: корневой домен (example.com) и поддомен (www.example.com). Они ведут себя по‑разному у многих DNS‑провайдеров.

A‑запись указывает имя на IPv4‑адрес. Многие настройки используют A для корня, потому что некоторые провайдеры не позволяют CNAME на апексе. Если хост дал IP, A обычно корректен.

AAAA — версия для IPv6. Лишняя AAAA‑запись, указывающая на старую цель, может создавать запутанное поведение «у меня работает», потому что некоторые посетители пойдут по IPv6, а другие по IPv4. Если хост не дал IPv6‑цель, удаление неверной AAAA часто решает непоследовательные ошибки.

CNAME указывает поддомен на другое имя хоста (часто используется для www). Это удобно, когда хост просит целиться в именованный endpoint, который может меняться.

TXT — для верификации и challenge‑записей (включая некоторые SSL‑проверки). Частые ошибки: запись на неправильном имени (корень вместо _acme-challenge или поддомена), лишние пробелы или вставленное неверное значение.

Прежде чем двигаться дальше, ищите конфликты. Они чаще всего создают проблемы:

• CNAME на имени, где есть другие типы записей
• Несколько A или AAAA для одного имени, когда нужен только один
• Старые записи, оставшиеся для www или корня
• TXT‑записи, созданные на неправильном имени

Шаг 3: проверьте nameserver‑ы, чтобы убедиться, что вы правите в нужном месте

Множество случаев «пользовательский домен не работает» вовсе не про значение записи. Они происходят потому, что запись была добавлена у неправильного провайдера. Если домен использует nameserver‑ы Провайдера A, изменение записей в панели Провайдера B ни на что не повлияет, даже если записи там выглядят правильно.

Подтвердите авторитетные nameserver‑ы

Проверьте, какими nameserver‑ами действительно пользуется ваш домен. Обычно это видно в настройках домена у регистратора в разделе «Nameservers». Для дополнительной проверки можно спросить DNS напрямую с вашего компьютера:

 dig NS example.com

Nameserver‑ы, которые вернёт эта команда, и есть авторитетные.

Короткая проверка здравого смысла:

• Если ваш DNS‑хост дал nameserver‑ы вида ns1... и ns2..., эти точные значения должны быть указаны у регистратора.
• Если вы недавно поменяли провайдера DNS, подтвердите, что переключение завершено, прежде чем править записи.
• Если платформа показывает «рекомендуемые записи DNS», это обычно подсказка. Вам всё равно нужно добавить записи у авторитетного провайдера.

Почему бывает «я обновил, но ничего не изменилось»

Если вы обновляете записи у неправильного провайдера, у вас часто будет две панели с разными данными. Важны только авторитетные nameserver‑ы.

Также следите за задержками после смены nameserver‑ов у регистратора. В период перехода результаты могут выглядеть непоследовательно в зависимости от места тестирования. Если nameserver‑ы всё ещё меняются, приостановите правки записей, пока набор nameserver‑ов не стабилизируется.

Шаг 4: проверки распространения и кешей, которые действительно помогают

«Пропагация» — это не один переключатель. Это цепочка кешей DNS (ISP, сотовые операторы, публичные резолверы и ваши собственные устройства), которые обновляются с разной скоростью. Поэтому ваш домен может работать у коллеги, но не у вас.

TTL подсказывает, как долго кешы могут хранить ответ. Если старый TTL был 1 час, некоторые люди будут видеть старое значение около часа. Понижение TTL помогает только если вы сделали это до изменения.

Чтобы отделить задержки кеширования от реальных ошибок, выполните несколько быстрых проверок:

• Проверьте на домашнем или офисном Wi‑Fi, затем на мобильных данных
• Попросите кого‑то на другой сети попробовать
• Используйте приватное окно (чтобы исключить кешированные редиректы)
• Перезагрузите устройство или очистите локальный кеш DNS, если знаете как
• Ещё раз проверьте точное имя хоста (корень vs www)

Если запись везде неправильная (неверный IP, отсутствует www, старый CNAME), исправляйте её. Если в большинстве мест записи верные, а в одной сети всё ещё видно старое значение, скорее всего это задержка кеширования.

Шаг 5: тайминг SSL и почему «подождите немного» иногда верный совет

SSL‑сертификаты обычно не выдаются по одной простой причине: центр сертификации не может подтвердить домен, пока DNS не укажет на правильную цель стабильно.

Обычная последовательность проста:

1. Установите корректные DNS‑записи.
2. Подождите, пока они начнут правильно резолвиться из нескольких мест.
3. Выполните требуемую верификацию (часто TXT‑запись).
4. Дайте времени на выпуск сертификата.

Типичные блокеры легко упустить. Неверная A или CNAME‑цель отправит проверки в неправильное место. Старая AAAA‑запись может переопределять рабочую A‑запись для части посетителей, поэтому HTTPS у них падает. Отсутствующая TXT‑запись может помешать выпуску сертификата.

Используйте симптомы, чтобы отличить «ещё выдаётся» от «неправильной конфигурации»:

• Ещё выдаётся: HTTP может работать, а HTTPS показывает временный сертификат по умолчанию или сообщение «не ещё действительно».
• Неправильная конфигурация: вы видите другой сайт, страницу парковки провайдера или DNS‑lookup падает (NXDOMAIN).

Пока ждёте, не переключайте записи туда‑сюда. Каждое изменение сбрасывает счётчик и может создать «раздвоенный» мир, где разные сети видят разные ответы. Установите правильные записи один раз, затем периодически проверяйте резольв и верификацию, пока сертификат не будет выпущен.

Если вы используете платформу вроде Koder.ai, безопасный порядок тот же: подтвердите, что DNS указывает на ожидаемую цель, удалите неверные AAAA‑записи, если они есть, и дайте SSL‑у время после стабилизации DNS.

Как проверять каждый шаг (без догадок)

Хорошая отладка — это, в основном, сравнение: что вы видите и что ожидаете. Не доверяйте только «на телефоне загружается». Используйте повторяемые проверки.

Сопоставьте ответы DNS с ожидаемой целью

Воспользуйтесь инструментом запроса DNS (например, nslookup или dig) и подтвердите, что возвращаемое значение соответствует тому, что вы планировали (IP для A/AAAA, имя хоста для CNAME, токен для TXT).

# Apex (root) domain
dig example.com A

dig example.com AAAA

# www subdomain
dig www.example.com CNAME

# TXT (often used for verification)
dig example.com TXT

Проверьте оба имени, которые вы могли бы использовать: апекс (example.com) и www (www.example.com). Часто одно имя корректно, а другое всё ещё указывает на старое место.

Проверьте поведение в браузере (HTTP, HTTPS и редиректы)

Откройте http:// и https:// для апекса и www. Вам нужно одно ясное «домашнее» имя и один аккуратный редирект.

• Выберите одно каноническое имя (апекс или www) и перенаправляйте другое на него.
• Избегайте «пинг‑понг» редиректов (A редиректит на B, а B возвращает на A).
• Если HTTP работает, а HTTPS падает, SSL либо ещё выдаётся, либо DNS указывает не туда.

Если результаты различаются по сетям, вероятно это кеширование или распространение. Ведите небольшой лог: что вы изменили, где, время и наблюдения.

Распространённые ошибки, которые отнимают часы

Большинство проблем с DNS и SSL — не тайна. Это мелкие ошибки, которые заставляют вас проверять не то или менять настройки слишком часто, чтобы получить точную картину.

Самая частая потеря времени — редактирование DNS в двух местах. Это часто случается после смены nameserver‑ов: вы обновляете записи у регистратора, но DNS действительно хостится в другом месте (или наоборот). Всё выглядит корректно в одной панели, но публичный DNS не меняется.

Другая классика — попытка поставить CNAME на корневой домен у провайдера, который этого не поддерживает. Возможно, вам нужен A‑запись или ALIAS/ANAME‑тип записи, если провайдер поддерживает.

IPv6 тоже приносит сюрпризы. Оставленная старая AAAA‑запись может отправлять некоторых посетителей на неверный сервер, в то время как другие попадают на правильный IPv4.

Осторожно с «на всякий случай» записями. Несколько A‑записей могут работать как случайный балансировщик, если одна из целей неверна, особенно при указании кастомного домена на хостинг.

Правило финальное: прекратите сбрасывать часы.

• Не меняйте записи каждые несколько минут.
• Не смешивайте старые и новые цели одновременно.
• Подождите, пока кеши стабилизируются, прежде чем оценивать результат.

Маленькие, спокойные изменения лучше постоянной суеты.

Реалистичный пример: www работает, а корень — нет

Вы запускаете приложение и настраиваете example.com и www.example.com. Через несколько минут www.example.com загружается, а корневой домен показывает ошибку DNS, грузит старый сайт или HTTPS остаётся в ожидании. Этот сценарий обычен и обычно имеет тривиальную причину.

Начните с банального вопроса: вы редактируете DNS в правильном месте? Если домен зарегистрирован у одной компании, а DNS хостится у другой, вы можете править записи бесконечно — ничего не изменится. Проверьте nameserver‑ы, затем откройте панель DNS того провайдера, на которого они указывают.

Дальше сравните два имени. www обычно является CNAME. Корень сложнее: многие провайдеры не разрешают CNAME на апексе, поэтому обычно нужен A‑запись на IP или ALIAS/ANAME, если провайдер поддерживает.

Практический путь:

• Nameserver‑ы неверны или неожиданные? Сначала исправьте это.
• Nameserver‑ы верны, но у example.com нет записи (или она указывает не туда)? Исправьте апекс.
• Записи выглядят верными, но поведение разнится по устройствам/сетям? Подождите распространения и очистите кеши.
• DNS резолвится правильно, но HTTPS падает или застрял? SSL ждёт стабильного DNS.

Правильный конечный результат скучен: и example.com, и www.example.com ведут на одно и то же приложение, одно имя каноническое, другое перенаправляет, и HTTPS валиден.

Быстрый чек‑лист, который можно пройти за 5 минут

Когда настройка домена не проходит, исправления чаще всего находятся в нескольких быстрых проверках. Запустите их прежде, чем менять что‑то ещё.

• Подтвердите, что редактируете DNS в правильном месте (сопоставьте панель с авторитетными nameserver‑ами домена).
• Проверьте точность имени хоста и цели (нет пропущенных поддоменов, лишних точек). Сравните тип записи (A, AAAA, CNAME, TXT) с тем, что ждет ваш хост.
• Уберите конфликты (CNAME вместе с другими типами на том же имени или старые A/AAAA, которые больше не нужны).
• Проверьте с двух точек зрения (мобильные данные и Wi‑Fi). Если в одной сеть всё работает, а в другой — нет, это обычно кеш/распространение.
• Уважайте TTL. Если TTL 300 секунд, подождите 5–10 минут перед выводами. Если TTL 3600, рассчитывайте ближе к часу.

После того как DNS однозначно корректен, проверяйте SSL. Многие платформы начнут выпуск сертификата только после того, как домен последовательно резолвится на ожидаемую цель. Если вы проверили слишком рано, можно принять нормальную задержку за реальную ошибку.

Если вы добавляете кастомный домен к задеплоенному приложению на Koder.ai, используйте экран настройки домена как справочник для ожидаемой цели и повторно проверяйте статус только после того, как DNS успеет распространиться.

Следующие шаги: сделайте настройку домена повторяемой для каждого запуска

Самый быстрый способ не наступать на те же грабли с DNS и SSL — вести короткую «записку по настройке домена» для каждого проекта. Это повторяемый runbook, который можно скопировать при следующем запуске.

Простой шаблон заметки по настройке домена

Держите в документации проекта и заполняйте до правки DNS:

• Домены и имена хостов (корень, www и любые поддомены)
• Ожидаемые типы записей и цели (A, CNAME, TXT) и откуда они берутся
• Где редактируется DNS (какой провайдер) и активные nameserver‑ы
• Ожидания по SSL (кто выдаёт, как выглядит состояние «готов»)
• Шаги верификации, которые вы выполните (инструмент и ожидаемый результат)

Во время запуска назначьте одного человека ответственным за DNS. DNS чаще всего ломается, когда два человека одновременно «чинят» разные вещи (например, один меняет nameserver‑ы, другой правит записи).

На стороне хостинга планируйте безопасные откаты. Если платформа поддерживает снапшоты или rollback, сделайте снимок перед изменением маршрутизации, чтобы быстро вернуться к предыдущему рабочему состоянию. Если вы строите на Koder.ai, используйте Planning Mode, чтобы записать шаги по домену, применить их по порядку и откатить при проблеме.

Когда эскалировать (и кому)

Если вы подтвердили DNS, но проблема остаётся, перестаньте гадать и эскалируйте с доказательствами:

• Регистр показывает заблокированные nameserver‑ы или вы не можете их изменить
• Изменения DNS не появляются публично после ожидаемого окна TTL
• SSL продолжает падать долго после того, как DNS резолвится корректно (речь о часах, а не минутах)
• Видите конфликтующие записи, которые не можете удалить (баг UI провайдера или split DNS)

При эскалации приложите имя хоста, ожидаемые записи, текущие результаты резолвов и метки времени. Это превратит медленный обмен сообщениями в быстрый ремонт.