Как привязать домен к серверу HIP: DNS-записи и HTTPS через reverse proxy

Домен и сервер - это две независимые вещи, которые ничего не знают друг о друге, пока вы не свяжете их вручную. Привязать домен к серверу значит прописать DNS-запись, которая говорит миру: «за этим именем стоит вот такой IP». После этого остаётся, чтобы сам сервер согласился отвечать по этому домену и умел показывать сайт по HTTPS, а не голым http. В статье - какую запись выбрать, сколько реально ждать, пока она разойдётся, и как за десять минут поднять reverse proxy с сертификатом, который сам продлевается.

Коротко. В панели домена добавьте запись A с именем @ и значением - IPv4-адресом сервера, такую же для www; если у сервера есть IPv6, добавьте ещё пару AAAA. Подождите, пока записи разойдутся - обычно от нескольких минут до часа. На сервере поставьте Caddy: он умеет и раздавать сайт, и получать сертификат Let's Encrypt сам, без отдельного certbot и cron-задачи на продление. Проверьте результат запросом curl -I https://ваш-домен.

Что нужно перед началом

• Домен куплен у любого регистратора, и у вас есть доступ к панели, где редактируются его DNS-записи. Это может быть панель самого регистратора либо сторонний DNS-провайдер вроде Cloudflare, если на него переключены серверы имён (NS).
• Сервер работает и у него есть публичный IP-адрес - его вы найдёте в панели HIP на вкладке Информация.
• На сервере что-то слушает нужный порт: веб-сервер, приложение или reverse proxy. На пустом сервере домен всё равно «откроется» - просто покажет ошибку соединения, а не сайт.

Как привязать домен к серверу: два независимых уровня

Уровень 1 - DNS. Записи в зоне домена связывают имя с адресом. Запрос к site.ru сначала идёт на серверы имён домена, те возвращают IP из записи A (для IPv4) или AAAA (для IPv6), и только после этого браузер соединяется с самим сервером.

Уровень 2 - сервер. Запрос приходит с заголовком Host: site.ru. Веб-сервер или reverse proxy читает этот заголовок, решает, какой сайт отдавать, и обслуживает соединение - включая выпуск и продление TLS-сертификата для HTTPS.

Эти два уровня друг от друга не зависят, и это удобно: DNS-запись можно прописать заранее, до того как сервер настроен - домен просто будет указывать на адрес, где пока никто не отвечает, без ошибок и предупреждений.

Шаг 1. Узнайте IP-адрес сервера

Откройте сервер в панели my.hip.hosting, вкладка Информация, блок «Подключение» - тот же, что нужен для SSH-входа. Там указан IP-адрес и готовая строка ssh root@IP, из которой адрес можно просто скопировать (подробнее про сам вход - в статье Как подключиться к серверу HIP). Технически это IPv4. Отдельного IPv6 для всех тарифов и локаций HIP панель может не выдавать - если он у вашего сервера есть, ищите его на той же вкладке; если нет, ничего страшного, весь сценарий ниже работает и на одном IPv4.

Заодно стоит проверить, что на сервере вообще что-то слушает нужный порт. Подключитесь по SSH и выполните:

ss -tlnp

В выводе должны быть строки с :80 и :443 - если пока пусто, это нормально: веб-сервер появится в шаге 4, дальше по инструкции.

Шаг 2. Пропишите DNS-записи

Зайдите в панель, где управляется DNS домена. Ниже - порядок на примере Cloudflare, у регистраторов поля называются так же или очень похоже.

Добавьте запись:

• Тип - A
• Имя - @ (сам домен целиком, site.ru; часть панелей вместо @ просит оставить поле пустым или вписать имя домена полностью)
• Значение (IPv4 address / Content) - IPv4-адрес сервера из шага 1
• TTL - Auto или 300 секунд на время настройки

Маленький TTL не ускорит появление именно этой, самой первой записи - он влияет только на будущее: если вы позже поменяете IP, новое значение разойдётся быстрее, потому что резолверы не будут долго держать в кеше старое.

Добавьте вторую запись A для www с тем же IP, чтобы сайт открывался и с приставкой www, и без неё. Если у сервера есть IPv6, добавьте ещё пару записей AAAA - для @ и для www - со значением IPv6-адреса.

@

www

@

www

Вместо второй A-записи можно использовать CNAME. Запись CNAME с именем www и значением site.ru говорит «www - это псевдоним основного домена», и тогда IP правится в одном месте. Для самого домена (@, корень зоны) CNAME по стандарту DNS ставить нельзя - только A или AAAA. У некоторых DNS-провайдеров, включая Cloudflare, есть собственная функция вроде CNAME-flattening, которая обходит это ограничение на своей стороне, но это уже особенность конкретного провайдера, а не общее правило DNS.

Шаг 3. Дождитесь, пока записи разойдутся

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

Проверьте со своего компьютера:

dig +short site.ru

nslookup site.ru

• nslookup есть по умолчанию почти везде - в Windows, macOS, большинстве Linux.
• dig удобнее читается, но на Ubuntu и Debian его придётся поставить отдельно: sudo apt install dnsutils. На macOS он обычно уже есть.

Как только в ответе появится IP вашего сервера - записи применились. Проверить сразу из разных стран можно на сайтах вроде dnschecker.org.

Шаг 4. Откройте порты и поднимите reverse proxy с HTTPS

Приложение (сайт на Node.js, Python и так далее) обычно слушает локальный порт вроде 127.0.0.1:3000. Наружу по 80 и 443 его отдаёт reverse proxy - он же занимается сертификатом.

Если на сервере включён firewall - sudo ufw status покажет, так ли это, - разрешите на нём хотя бы порт 80 (без него не проходит стандартная проверка Let's Encrypt) и обязательно 443 для самого HTTPS-трафика после того, как сертификат уже выпущен. Сама установка веб-сервера порт наружу не открывает: она заставляет процесс слушать порт внутри сервера, а firewall - это отдельная настройка (подробно про неё - в статье Защита свежего VPS).

Мы бы поставили здесь Caddy, а не связку nginx плюс certbot. Разница не в мелочах: у Caddy получение и продление сертификата встроено в сам процесс, а у nginx это отдельная программа (certbot) плюс отдельная задача на продление, которую нужно один раз настроить и потом не забыть, что она вообще существует. Меньше движущихся частей - меньше того, что может сломаться через полгода, когда вы уже забудете, как это всё настраивали.

Установка Caddy на Ubuntu из официального репозитория:

sudo apt update

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

sudo apt update

sudo apt install -y caddy

• первые три команды добавляют ключ и адрес репозитория Caddy в систему - без этого apt не знает, откуда брать пакет;
• после установки Caddy сам запускается как служба systemd и остаётся работать в фоне.

Откройте конфиг Caddy текстовым редактором:

sudo nano /etc/caddy/Caddyfile

Уберите содержимое по умолчанию и впишите свой домен:

site.ru, www.site.ru {

reverse_proxy 127.0.0.1:3000

}

Примените конфигурацию:

sudo systemctl reload caddy

Caddy запросит сертификат сразу после того, как примет новый конфиг - не тогда, когда кто-то впервые откроет сайт в браузере. Для этого нужны открытые порты 80 и 443 и уже разошедшаяся DNS-запись; если запись ещё не применилась или порт закрыт firewall, выпуск сертификата не пройдёт, и это будет видно в логе:

journalctl -u caddy -n 50

Проверьте результат:

curl -I https://site.ru

Успешный ответ - это заголовки вашего сайта без ошибки сертификата; конкретный код и версия протокола (HTTP/1.1, HTTP/2 или HTTP/3) зависят от того, как настроено само приложение за прокси.

Если доменов и поддоменов на сервере станет много и вы будете перевыпускать сертификаты часто, держите в голове реальный лимит Let's Encrypt: не больше 50 новых сертификатов на один зарегистрированный домен верхнего уровня в неделю и не больше 5 дублирующих сертификатов на один и тот же набор имён в неделю. Для одного-двух сайтов это не встретится никогда, но при автоматизации массового выпуска - вполне реальная стена.

Если предпочитаете nginx

Схема та же: DNS указывает на сервер, порты 80 и 443 открыты, конфиг связывает домен с локальным портом приложения. Разница только в том, что сертификат ставится отдельно через certbot --nginx, а reverse-proxy-конфиг пишется вручную в отдельном файле. Если у вас уже есть настроенный nginx с другими сайтами или нужна директива, которой в Caddy пока нет, - это разумный вариант. Подробный разбор конфига, заголовков прокси и firewall-правил под nginx - в статье nginx и ufw перед вашим приложением, а если хочется довести Caddy до более сложной конфигурации, чем один домен на один порт - в статье Caddy: веб-сервер с автоматическим HTTPS.

Поддомены и вебхуки

Каждый поддомен - это отдельная DNS-запись. Нужен api.site.ru - добавьте A с именем api и тем же IP (или CNAME на site.ru), а в Caddyfile - отдельный блок:

api.site.ru {

reverse_proxy 127.0.0.1:4000

}

Если телеграм-бот работает на вебхуках, ему нужен публичный HTTPS-адрес - обычно как раз поддомен вроде hook.site.ru, настроенный тем же способом. Боту на long polling (постоянных запросах к серверам Telegram вместо приёма входящих) домен вообще не нужен.

Обратная зона (PTR) - не для этого случая

Запись A связывает имя с IP - это «прямая» зона. Запись PTR работает наоборот, связывает IP с именем, и нужна в основном для отправки почты: принимающие серверы её проверяют, и без неё письма чаще уходят в спам. Для обычного сайта по HTTPS она не требуется вовсе. Если у вас на этом сервере ещё и своя почта - подробный разбор PTR, включая как его прописать в панели HIP и как проверить командой dig -x, есть в статье Обратная DNS-запись и заказ дополнительного IPv4.

Частые вопросы

Нужно ли переключать серверы имён (NS)?

Только если вы хотите управлять DNS не у регистратора, а у стороннего провайдера вроде Cloudflare. Если записи правятся прямо в панели регистратора, NS трогать не нужно.

Сколько ждать после изменения DNS-записей?

Обычно от нескольких минут до часа при небольшом TTL, иногда - до нескольких часов. Смена серверов имён может занять до суток, потому что кешируется на уровне реестра доменов, а не только у резолверов пользователей.

Можно ли получить HTTPS-сертификат без домена?

Нет для публичного сертификата от Let's Encrypt - удостоверяющий центр выпускает сертификат на конкретное имя и должен убедиться, что вы им владеете, а для этого имя должно резолвиться в ваш сервер. По голому IP можно только сгенерировать самоподписанный сертификат, и браузеры будут показывать его как небезопасный.

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

Да. У каждого домена - свои DNS-записи на тот же IP и свой блок в Caddyfile или конфиге nginx. Reverse proxy различает сайты по заголовку Host из запроса браузера.

Нужен ли статический IP, чтобы прописать домен?

IP, который сервер получает при заказе, как правило закреплён за ним и сам по себе не меняется - его можно спокойно прописывать в DNS. Меняется он обычно только при заказе нового сервера, а не при обычной работе или переустановке ОС на этом же сервере.

Стоит ли включать оранжевое облако (прокси) в Cloudflare?

Можно, если нужна защита от DDoS и кеш статики, но тогда HTTPS на самом сервере всё равно обязателен, а режим SSL в Cloudflare нужно выставить Full (strict) - иначе участок между Cloudflare и вашим сервером останется незашифрованным. Без прокси (серое облако) - это просто DNS, всё работает так, как описано выше.

Коротко

• Домен привязывается через DNS-запись: A на IPv4 сервера обязательно, AAAA на IPv6 - только если он у сервера есть.
• DNS и сам сервер - независимые уровни: запись можно прописать заранее, до настройки прокси.
• Записи распространяются не мгновенно - обычно от нескольких минут до часа, смена NS - дольше.
• Порт слушает процесс, а открывает его наружу firewall - это две разные настройки, проверяйте обе.
• Для HTTPS проще один раз поставить Caddy: сертификат получает и продлевает сам, без certbot и отдельного cron.
• PTR-запись для обычного сайта не нужна - она про почту, а не про открытие страницы в браузере.

Что дальше

• Caddy: веб-сервер с автоматическим HTTPS - если один домен на один порт вам уже мало и нужна конфигурация сложнее.
• nginx и ufw перед вашим приложением - та же задача через nginx, с подробным разбором firewall-правил.
• Защита свежего VPS - firewall и первые шаги на новом сервере, если ещё не настроены.
• Обратная DNS-запись и заказ дополнительного IPv4 - если на этом же сервере планируете отправлять почту.