Используйте этот контрольный список для диагностики проблем с DNS, задержек распространения и тайминга SSL — простые шаги для проверки и устранения неполадок.
«Пользовательский домен не работает» — это собирательная фраза для нескольких разных сбоев. Браузер показывает симптом, а не причину. Прежде чем что‑то менять, опишите, что вы фактически видите.
Типичные симптомы включают:
Чаще всего проблема в одном из пунктов:
Перед началом устранения неполадок убедитесь, что у вас есть доступ к двум местам: где вы редактируете DNS‑записи (регистратор или провайдер DNS) и где вы привязываете домен на стороне хостинга. Например, если вы подключаете задеплоенное приложение на Koder.ai к кастомному домену, вам нужен доступ к DNS домена и к настройкам домена в панели приложения.
Некоторые исправления мгновенные (например, исправление опечатки). Другие требуют времени. Изменения DNS могут долго распространяться, и SSL обычно не завершится, пока DNS не начнёт корректно резолвиться и домен не станет доступен. Цель — перестать гадать и поочерёдно подтвердить каждый уровень.
Большинство проблем с доменами сводится к несоответствию между (1) именем хоста, которое вы проверяете, (2) где управляется DNS, и (3) куда фактически указывает запись. Когда эти три вещи совпадают, SSL обычно остаётся последним шагом.
Домены обычно бывают в двух формах: корневой домен (example.com, также называемый apex) и поддомены (www.example.com, app.example.com). Это связанные, но отдельные DNS‑записи. Поэтому нормально, когда www работает, а апекс нет, или наоборот.
Nameserver‑ы решают, кто отвечает за вашу DNS‑зону. Если вы купили домен у одной компании, но nameserver‑ы указывают на другую, нужно редактировать DNS там, куда указывают nameserver‑ы. Многие ситуации «я обновил, но ничего не поменялось» возникают потому, что записи правили в неправильной панели.
Вот что делают основные типы записей:
www)TTL — это «как долго кешировать ответ». Низкий TTL означает, что кешы обновляются быстрее. Высокий TTL значит, что придётся ждать дольше, даже после исправления записи. Наблюдать старое значение некоторое время — нормально.
Когда пользовательский домен не работает, обычно проблему можно отнести к одной из четырёх категорий: DNS не резолвится, DNS указывает не туда, SSL не готов, или проблема возникает у некоторых пользователей из‑за кеширования.
Используйте это дерево решений:
www работает, а корень нет (или наоборот), вероятно настроено только одно имя хоста или есть конфликтующие правила редиректа.Двигайтесь быстрее, записав точное имя хоста, которое падает (apex vs www) и точное сообщение об ошибке. На платформах, которые автоматизируют домены и сертификаты, различие между «не найден хост» и «сертификат ожидается» подскажет, нужно ли править DNS‑записи или просто ждать SSL после того, как DNS станет видимым.
Множество ошибок начинаются с простой рассинхронизации: вы настроили DNS для одного имени хоста, а тестируете другое.
Сначала запишите точное имя хоста, которое хотите сделать рабочим. Корневой домен выглядит как example.com. Поддомен — как www.example.com или app.example.com. Это отдельные DNS‑записи, так что «www работает» не означает, что корень тоже будет.
Далее найдите ожидаемую цель в панели вашего хоста. Некоторые платформы дают IP‑адрес (для A или AAAA). Другие дают имя хоста (для CNAME). Если хост предоставляет значение в экране настройки домена, считайте его источником истины.
Прежде чем что‑то менять, зафиксируйте текущие настройки. Делайте просто:
Также подтвердите, что вы редактируете нужную DNS‑зону. Легко обновить неверный домен, неправильную среду или чужой аккаунт провайдера.
Многие проблемы — просто неправильный тип записи для того имени хоста, которое вы пытаетесь подключить. Начните с разделения на два случая: корневой домен (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 или поддомена), лишние пробелы или вставленное неверное значение.
Прежде чем двигаться дальше, ищите конфликты. Они чаще всего создают проблемы:
www или корняМножество случаев «пользовательский домен не работает» вовсе не про значение записи. Они происходят потому, что запись была добавлена у неправильного провайдера. Если домен использует nameserver‑ы Провайдера A, изменение записей в панели Провайдера B ни на что не повлияет, даже если записи там выглядят правильно.
Проверьте, какими nameserver‑ами действительно пользуется ваш домен. Обычно это видно в настройках домена у регистратора в разделе «Nameservers». Для дополнительной проверки можно спросить DNS напрямую с вашего компьютера:
dig NS example.com
Nameserver‑ы, которые вернёт эта команда, и есть авторитетные.
Короткая проверка здравого смысла:
ns1... и ns2..., эти точные значения должны быть указаны у регистратора.Если вы обновляете записи у неправильного провайдера, у вас часто будет две панели с разными данными. Важны только авторитетные nameserver‑ы.
Также следите за задержками после смены nameserver‑ов у регистратора. В период перехода результаты могут выглядеть непоследовательно в зависимости от места тестирования. Если nameserver‑ы всё ещё меняются, приостановите правки записей, пока набор nameserver‑ов не стабилизируется.
«Пропагация» — это не один переключатель. Это цепочка кешей DNS (ISP, сотовые операторы, публичные резолверы и ваши собственные устройства), которые обновляются с разной скоростью. Поэтому ваш домен может работать у коллеги, но не у вас.
TTL подсказывает, как долго кешы могут хранить ответ. Если старый TTL был 1 час, некоторые люди будут видеть старое значение около часа. Понижение TTL помогает только если вы сделали это до изменения.
Чтобы отделить задержки кеширования от реальных ошибок, выполните несколько быстрых проверок:
www)Если запись везде неправильная (неверный IP, отсутствует www, старый CNAME), исправляйте её. Если в большинстве мест записи верные, а в одной сети всё ещё видно старое значение, скорее всего это задержка кеширования.
SSL‑сертификаты обычно не выдаются по одной простой причине: центр сертификации не может подтвердить домен, пока DNS не укажет на правильную цель стабильно.
Обычная последовательность проста:
Типичные блокеры легко упустить. Неверная A или CNAME‑цель отправит проверки в неправильное место. Старая AAAA‑запись может переопределять рабочую A‑запись для части посетителей, поэтому HTTPS у них падает. Отсутствующая TXT‑запись может помешать выпуску сертификата.
Используйте симптомы, чтобы отличить «ещё выдаётся» от «неправильной конфигурации»:
Пока ждёте, не переключайте записи туда‑сюда. Каждое изменение сбрасывает счётчик и может создать «раздвоенный» мир, где разные сети видят разные ответы. Установите правильные записи один раз, затем периодически проверяйте резольв и верификацию, пока сертификат не будет выпущен.
Если вы используете платформу вроде Koder.ai, безопасный порядок тот же: подтвердите, что DNS указывает на ожидаемую цель, удалите неверные AAAA‑записи, если они есть, и дайте SSL‑у время после стабилизации 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:// для апекса и www. Вам нужно одно ясное «домашнее» имя и один аккуратный редирект.
www) и перенаправляйте другое на него.Если результаты различаются по сетям, вероятно это кеширование или распространение. Ведите небольшой лог: что вы изменили, где, время и наблюдения.
Большинство проблем с 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, если провайдер поддерживает.
Практический путь:
example.com нет записи (или она указывает не туда)? Исправьте апекс.Правильный конечный результат скучен: и example.com, и www.example.com ведут на одно и то же приложение, одно имя каноническое, другое перенаправляет, и HTTPS валиден.
Когда настройка домена не проходит, исправления чаще всего находятся в нескольких быстрых проверках. Запустите их прежде, чем менять что‑то ещё.
После того как DNS однозначно корректен, проверяйте SSL. Многие платформы начнут выпуск сертификата только после того, как домен последовательно резолвится на ожидаемую цель. Если вы проверили слишком рано, можно принять нормальную задержку за реальную ошибку.
Если вы добавляете кастомный домен к задеплоенному приложению на Koder.ai, используйте экран настройки домена как справочник для ожидаемой цели и повторно проверяйте статус только после того, как DNS успеет распространиться.
Самый быстрый способ не наступать на те же грабли с DNS и SSL — вести короткую «записку по настройке домена» для каждого проекта. Это повторяемый runbook, который можно скопировать при следующем запуске.
Держите в документации проекта и заполняйте до правки DNS:
www и любые поддомены)Во время запуска назначьте одного человека ответственным за DNS. DNS чаще всего ломается, когда два человека одновременно «чинят» разные вещи (например, один меняет nameserver‑ы, другой правит записи).
На стороне хостинга планируйте безопасные откаты. Если платформа поддерживает снапшоты или rollback, сделайте снимок перед изменением маршрутизации, чтобы быстро вернуться к предыдущему рабочему состоянию. Если вы строите на Koder.ai, используйте Planning Mode, чтобы записать шаги по домену, применить их по порядку и откатить при проблеме.
Если вы подтвердили DNS, но проблема остаётся, перестаньте гадать и эскалируйте с доказательствами:
При эскалации приложите имя хоста, ожидаемые записи, текущие результаты резолвов и метки времени. Это превратит медленный обмен сообщениями в быстрый ремонт.
Обычно это означает, что один из уровней цепочки работает неправильно: DNS не резолвится, DNS указывает не туда, сервер/хост не распознаёт ваше имя хоста или HTTPS/SSL ещё не выпущен. Начните с записи точной ошибки, которую вы видите, и точного имени хоста, которое вы вводили (apex vs www).
Потому что example.com (апекс) и www.example.com — это разные имена хостов с отдельными DNS‑записями. Частая ситуация — корректная CNAME для www, в то время как апекс либо не имеет A‑записи, либо указывает не туда, либо требует другого типа записи у вашего DNS‑провайдера.
Проверьте nameserver‑записи домена у регистратора и сравните их с тем провайдером DNS, в котором вы вносите изменения. Только провайдер, указанный в активных nameserver‑записях, является авторитетным; правки в других местах не повлияют на то, что видит интернет.
Используйте A, если хост дал вам IPv4‑адрес; AAAA — только если хост дал IPv6‑адрес; CNAME — когда хост дал имя хоста (часто для www). TXT — для верификации и challenge‑записей; их нужно добавлять на точное имя, которое требует хост.
Неправильная или устаревшая AAAA‑запись может отправлять часть посетителей по IPv6 на старый сервер, тогда как остальные попадают по IPv4 на правильный адрес — это создаёт эффект «у меня работает, а у другого нет». Если хост не дал IPv6‑адрес, удаление некорректной AAAA‑записи часто решает проблему.
Чаще всего потому, что на стороне хостинга настроено только одно имя хоста (только апекс или только www), или есть конфликтующие правила перенаправления, которые гоняют запросы между HTTP и HTTPS или между апексом и www. Выберите одно каноническое имя, настройте оба имени и сделайте один аккуратный редирект.
Да. Обычно нужно сначала убедиться, что DNS последовательно указывает на правильную цель из нескольких мест. Выпуск SSL‑сертификата обычно не завершится, пока домен не будет стабильно резолвиться на ожидаемый хост, поэтому после корректной настройки DNS иногда просто нужно подождать.
TTL (time to live) — это интервал, в течение которого резолверы кешируют ответ, поэтому даже после исправления записи некоторые сети будут показывать старое значение до истечения TTL. Тестируйте с двух сетей (например, Wi‑Fi и мобильные данные) и не вносите новые DNS‑изменения каждые пару минут, чтобы наблюдать распространение.
Используйте повторяемую проверку, например dig или nslookup, чтобы подтвердить, что ответы A/AAAA/CNAME/TXT соответствуют ожидаемому значению, затем протестируйте http:// и https:// для апекса и www. Если одна сеть показывает другие DNS‑ответы, это скорее кеширование; если все сети показывают неверные ответы, это ошибка конфигурации.
На Koder.ai используйте экран настройки домена в приложении как источник истины для ожидаемой цели DNS, затем внесите точные правки у авторитетного провайдера DNS. После изменения DNS дайте ему время распространиться перед повторной проверкой SSL и используйте снапшоты/откат, если меняете маршрутизацию на рабочем проекте.