Как привязать домен к VPS и проверить DNS

Чтобы привязать домен к VPS, определите действующего DNS-провайдера, добавьте A-запись с IPv4 сервера, проверьте AAAA и отдельно настройте нужные поддомены. Затем сравните ответ авторитетного DNS с ответом обычного резолвера и проверьте сайт по имени. Так Вы отличите неправильный адрес от ошибки Nginx, firewall или HTTPS.

Инструкция поможет, если после подключения домена открывается старая страница, сайт доступен только по IP или компьютер и телефон показывают разные результаты. Примеры используют зарезервированный домен example.com и демонстрационный адрес 203.0.113.10. Замените их своими значениями. Результат работы — проверенная карта имён и понятный маршрут до Вашего сайта.

Где менять записи домена

Регистратор, DNS-провайдер и провайдер VPS могут быть разными компаниями. Регистратор ведёт регистрацию домена и позволяет указать NS, серверы имён. DNS-провайдер хранит зону с записями сайта, почты и других сервисов. VPS-провайдер выдаёт сервер. Покупка VPS сама по себе не переносит к нему DNS-зону.

Откройте панель домена и посмотрите действующие NS. Сравните их с серверами имён панели, в которой собираетесь менять записи. Если домен делегирован другому сервису, редактирование зоны у регистратора может вообще не повлиять на публичные ответы. Не создавайте одинаковые записи в нескольких панелях наугад: сначала найдите фактически обслуживающую зону.

dig example.com NS +short

Этот запрос получает ответ через резолвер Вашей сети. Резолвер ищет данные для клиента и может сохранять их в кэше; авторитетный сервер отвечает из собственной зоны. Для проверки цепочки делегирования пригодится dig +trace example.com, если сеть разрешает прямые DNS-запросы. Синтаксис и диагностические параметры доступны в официальном руководстве dig проекта BIND.

Сохраните текущие NS и экспорт зоны либо список записей. Запишите имя, тип, значение и TTL изменяемых строк. Эта копия позволит вернуть прежний адрес и объяснить поддержке конкретную ошибку. Для подключения сайта обычно достаточно A-записи в уже действующей зоне. Изменение NS затрагивает все записи домена, поэтому его планируют как отдельный перенос.

Какие записи нужны сайту и поддоменам

A связывает имя с IPv4, AAAA — с IPv6, CNAME указывает на другое имя. Эти типы описаны в справочнике DNS-записей Cloudflare. Для простого сайта без прокси основной домен направляется A-записью на публичный IPv4 VPS. AAAA добавляйте, когда IPv6 действительно настроен и сайт проверен по этому протоколу.

В панели символ @ часто обозначает корень зоны, но конкретный интерфейс может ожидать пустое поле или полное имя. Смотрите подсказку рядом с полем. Полное имя в поле для относительного имени иногда превращается в запись вроде example.com.example.com. После сохранения проверяйте итоговое имя снаружи, а не только заполненную форму.

• example.com: A на публичный IPv4 VPS
• www.example.com: A на тот же адрес либо CNAME на основной домен
• app.example.com: отдельная запись для приложения
• AAAA каждого имени: только проверенный IPv6, без оставшегося адреса старого сервера

Запись основного домена не создаёт все поддомены автоматически. Wildcard со звёздочкой имеет отдельные правила и не заменяет карту нужных имён. Для первого проекта проще перечислить адреса явно. Случайные дополнительные A с другим IP могут направлять часть соединений на другой сервер, который не готов обслуживать этот сайт.

При подключении сайта не удаляйте MX и TXT. Почта, SPF, DKIM и проверки владения могут продолжать работать у других поставщиков. Если переносите NS, заранее перенесите всю нужную зону. Сохраните список записей до и после изменения; исчезновение почты после переноса часто оказывается отдельной ошибкой, которую нельзя исправить заменой A.

Как учитывать TTL и разные ответы клиентов

TTL задаёт срок кэширования полученного DNS-ответа. Новый адрес на авторитетном сервере не заменяет мгновенно все ранее сохранённые ответы. Для запланированного переключения уменьшение TTL полезно заранее: старый ответ с прежним TTL должен сначала перестать действовать. Снижение TTL одновременно с IP не сокращает жизнь уже закэшированной старой записи.

Вместо общего ожидания «пока всё обновится» сравнивайте данные. Запишите момент изменения, старый адрес и прежний TTL. Получите ответ у авторитетного сервера, затем у резолвера своей сети и другого независимого резолвера. Если авторитетный ответ неверен, ожидание ничего не исправит. Если он верен, а один клиент видит старый IP, проверяйте кэш и путь разрешения имени именно этого клиента.

Не переключайте адрес туда и обратно после каждой неудачной попытки открытия. Так появляются дополнительные варианты, которые сохраняют разные клиенты. Во время переноса оставьте оба сервера работоспособными на согласованный период и следите за запросами. Работа с базой, финальная синхронизация и возврат разобраны в статье как перенести сайт на новый VPS.

При включённом DNS-прокси публичный ответ может содержать адреса прокси, а не VPS. Это соответствует такой схеме. Проверяйте режим записи в панели и отдельно origin, исходный сервер. До диагностики запишите маршрут: посетитель соединяется прямо с VPS или сначала с прокси? Иначе верный ответ промежуточного сервиса выглядит как «чужой IP».

Как проверить DNS без изменения настроек

Проверяйте каждое публичное имя и оба семейства адресов. Одна верная A-запись не исключает ошибку AAAA, которую выберет часть клиентов. Команды ниже только читают DNS и не меняют зону.

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig www.example.com A
dig @ns1.example.net example.com A

В последней строке имя сервера условное; возьмите настоящий NS из действующего делегирования. Если авторитетных серверов несколько, проверьте каждый. Разные ответы могут указывать на несогласованное состояние зоны. В полном выводе смотрите статус, секцию ANSWER, тип записи и адрес. Пустой +short сам по себе не объясняет, отсутствует запись или произошла ошибка.

NXDOMAIN означает, что полученный ответ считает запрошенное имя несуществующим. SERVFAIL сообщает о невозможности получить корректный ответ; проверяйте доступность DNS, делегирование и DNSSEC, если он включён. Отсутствие записи одного типа также не означает отсутствие самого имени. Не удаляйте всю зону после такого результата: сохраните запрос и исследуйте конкретный уровень.

Если имя в панели верное, но делегирование ведёт не туда, изменение записи не попадёт к клиенту. Если делегирование верное, но один авторитетный сервер отвечает иначе, прикладывайте поддержке ответы каждого NS и время проверки. Такое обращение намного полезнее скриншота браузера «сайт не работает». Пароль панели и приватные ключи для этого не нужны.

Почему правильный IP ещё не означает рабочий сайт

После DNS требуется доступный порт, разрешение сетевых правил и конфигурация веб-сервера для имени. Nginx должен знать server_name и каталог сайта либо адрес приложения. На одном VPS могут жить несколько проектов, поэтому запрос по IP или неизвестному имени может попасть в стандартную страницу или другой виртуальный сервер.

Проверьте HTTP на выбранном VPS, не дожидаясь изменения DNS у всех клиентов:

curl --resolve example.com:80:203.0.113.10 -I http://example.com/

Подстановка адреса применяется к одному запросу, а имя в HTTP сохраняется. Для HTTPS используйте порт 443 и https://, причём сертификат должен соответствовать домену. Отключение проверки сертификата не подтверждает готовность публичного HTTPS. Поведение параметра описано в официальном руководстве curl.

При ответе 200 сверяйте содержимое: заголовок, внутреннюю страницу и узнаваемый ресурс текущего выпуска. Редирект может вести на старый домен, даже если начальный адрес верен. Тайм-аут требует проверки сети и портов; чужая страница — выбора виртуального сервера; ошибка сертификата — HTTPS. DNS не исправляет конфигурацию приложения и не заменяет выпуск сертификата.

Следующий этап для готовых файлов HTML, CSS и JavaScript приведён в инструкции размещение статического сайта на VPS с Nginx и HTTPS. До изменения общих настроек подготовьте SSH-доступ и резервную консоль. Сначала проверьте нужный виртуальный сервер, затем включайте обязательный переход на HTTPS, чтобы неправильный редирект не затруднил диагностику.

Как найти причину по наблюдаемому результату

Меняйте одну установленную причину за раз и сохраняйте результаты до исправления. Если одновременно менять NS, IP, firewall и сертификат, невозможно понять, что помогло и что теперь нужно вернуть.

• В панели новый IP, у авторитетного NS старый: проверьте выбранную зону и сохранение записи
• A верна, некоторые клиенты попадают не туда: проверьте AAAA, дополнительные A и прокси
• Домен работает без www: проверьте запись www, server_name и имя в сертификате
• DNS верен, соединение не устанавливается: проверьте порт и сетевые правила
• С подстановкой curl сайт верен, обычным запросом нет: сравните DNS и фактический маршрут
• На нужном сервере старая страница: проверьте активный выпуск и кэш приложения

Отдельный компьютер может использовать hosts, специальный DNS браузера или настройки корпоративной сети. Тогда ошибка выглядит общей, но проявляется только на этом устройстве. Проверка телефона через мобильную сеть полезна как независимый опыт, однако не заменяет чтение авторитетной зоны. Сохраните, с какой сети и каким инструментом получен каждый ответ.

Проверьте готовность домена

Отмечайте пункт после проверки результата. Чек-лист сохраняет прогресс в этом браузере; он не делает DNS-запросы и не проверяет конфигурацию автоматически.

После проверки Вы знаете, кто обслуживает записи, куда ведёт каждое имя и какой сайт отвечает. Если нужна помощь с доменом или размещением проекта, Умная форма позволяет описать задачу. Укажите публичное имя, время проверки и текст ошибки. Не передавайте в описание пароль панели, приватный SSH-ключ или токен приложения.

Частые вопросы о домене и VPS

Обязательно ли покупать домен у провайдера VPS

Нет. Достаточно управлять действующей DNS-зоной и знать публичный адрес сервера. Регистрация в одной компании не является техническим условием.

Можно ли направить несколько доменов на один сервер

Да, если веб-сервер обслуживает каждое имя, а сертификаты покрывают нужные адреса. DNS не выбирает страницу внутри Nginx.

Нужна ли PTR для обычного сайта

Для обычного входящего HTTP-запроса PTR не является условием открытия сайта. Обратные записи имеют отдельное назначение, в том числе в почтовой инфраструктуре.

Можно ли поставить CNAME рядом с A

Обычный CNAME имеет ограничения на другие записи того же имени. Для корня зоны используйте A и AAAA либо документированную специальную функцию DNS-провайдера.

Нужно ли менять домен в настройках приложения

Проверьте разрешённые origin, адреса API, redirect URI входа и абсолютные ссылки. DNS не обновляет эти значения.

Когда можно выключать прежний сервер

После проверки нового маршрута, согласования данных и контроля оставшегося трафика. Успешного открытия только на собственном ноутбуке недостаточно.