Как подключить домен к VPS и включить HTTPS в Nginx

Чтобы сайт открывался по привычному адресу, нужно связать три отдельные части. DNS направляет домен на IP-адрес VPS. Nginx принимает запрос и отдаёт файлы нужного сайта. HTTPS шифрует соединение и подтверждает, что посетитель связался с владельцем домена.

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

В примерах используется домен example.org и учебный IP 203.0.113.10. Они должны быть заменены вашими значениями. Инструкция предполагает Ubuntu Server, настроенный SSH и пользователя с правом выполнять команды через sudo.

Направьте домен на публичный адрес VPS

DNS-запись типа A связывает доменное имя с адресом IPv4. Откройте управление DNS у регистратора домена или DNS-провайдера и создайте запись для основного имени:

Тип: A
Имя: @
Значение: 203.0.113.10

Знак @ в большинстве панелей обозначает сам домен без добавочной части, то есть example.org. Если панель просит полное имя, следуйте её формату. Для адреса www.example.org создайте отдельную запись A на тот же IP или запись CNAME, которая ссылается на основной домен.

Запись AAAA выполняет ту же задачу для IPv6. Добавляйте её только после того, как провайдер выдал IPv6, он виден на VPS и входящие соединения по нему разрешены. Наличие адреса в тарифе ещё не доказывает, что весь путь работает.

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

Проверьте DNS с внешнего компьютера

Следующую команду выполните на своём компьютере, а не на VPS. Она спрашивает настроенный DNS-сервер, какой адрес соответствует домену:

nslookup example.org

В разделе ответа должно появиться значение A-записи — публичный IPv4 вашего VPS. Если там показана AAAA-запись, проверьте и её. Несколько адресов допустимы только тогда, когда каждый из них ведёт на сервер, способный обслужить сайт.

Если ответ пуст или содержит старый IP, подождите не меньше указанного TTL и сравните результат через другую сеть. Выпускать сертификат пока рано: запрос центра сертификации тоже может попасть на прежний адрес.

Установите Nginx и убедитесь, что он запустился

Nginx — веб-сервер: программа, которая постоянно ожидает запросы браузеров и возвращает страницы, изображения и другие файлы. Установите пакет из репозитория Ubuntu:

sudo apt update
sudo apt install nginx
systemctl status nginx --no-pager

Первая команда получает свежий список пакетов, вторая устанавливает Nginx. Третья показывает состояние его службы. В норме присутствует строка active (running): программа запущена и готова принимать соединения.

Если установка сообщает, что порт 80 уже занят, не завершайте неизвестный процесс. На сервере уже может работать Apache, панель управления или другое приложение. Узнайте владельца порта через sudo ss -lntp и решите, какая программа должна принимать веб-запросы.

Подготовьте отдельный каталог сайта

Файлы разных сайтов лучше хранить в разных каталогах. Создайте каталог для example.org и простую страницу, по которой можно узнать именно эту настройку:

sudo install -d -o admin -g admin -m 755 /var/www/example.org/html
nano /var/www/example.org/html/index.html

Команда install -d создаёт весь указанный каталог. Параметры -o и -g назначают владельцем пользователя и группу admin, а режим 755 разрешает Nginx проходить по каталогам и читать файлы, но оставляет запись только владельцу. Если ваш пользователь называется иначе, замените оба значения admin.

Редактор nano откроет новый файл index.html. Для проверки достаточно сохранить в нём короткий отличимый текст, например заголовок «Сайт example.org подключён». Не помещайте в /var/www исходники, закрытые ключи, файл .env с паролями или каталог .git: всё внутри корня сайта следует считать потенциально доступным веб-серверу.

Подробное разделение владельцев и прав рассматривается в следующем материале о файлах сайта и Nginx.

Объясните Nginx, какой домен обслуживать

Один Nginx может отдавать несколько сайтов с одного VPS. Для каждого создаётся блок server: в нём указаны порт, имена доменов и каталог с файлами. Такой блок часто называют виртуальным хостом.

Откройте отдельный конфигурационный файл:

sudoedit /etc/nginx/sites-available/example.org

Добавьте минимальную конфигурацию, заменив домен и путь, если у вас они отличаются:

server {
    listen 80;
    listen [::]:80;

    server_name example.org www.example.org;
    root /var/www/example.org/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Две строки listen принимают HTTP на порту 80 по IPv4 и IPv6. server_name перечисляет домены этого сайта. root задаёт каталог, из которого разрешено отдавать файлы, а index — файл для адреса /.

Блок location / применяется ко всем путям сайта. Директива try_files сначала ищет запрошенный файл, затем каталог и возвращает настоящий ответ 404, если ничего нет. Для обычного многостраничного сайта это правильнее, чем всегда возвращать главную страницу.

Включите конфигурацию и проверьте её

На Ubuntu файлы из sites-available хранятся как доступные настройки, а символическая ссылка в sites-enabled включает выбранный сайт. Символическая ссылка — небольшая запись, указывающая на другой файл; при редактировании исходного файла меняется и активная конфигурация.

Создайте ссылку, проверьте все настройки Nginx и только затем перечитайте их:

sudo ln -s /etc/nginx/sites-available/example.org /etc/nginx/sites-enabled/example.org
sudo nginx -t
sudo systemctl reload nginx

Если ссылка уже существует, команда ln сообщит об этом. Не создавайте вторую: проверьте текущую через readlink -f /etc/nginx/sites-enabled/example.org. Команда nginx -t должна подтвердить успешный синтаксис и проверку файла. При любой ошибке не выполняйте reload, а исправьте указанную строку.

reload заставляет Nginx перечитать настройки без остановки текущих соединений. После него служба должна оставаться в состоянии active (running), что можно проверить через systemctl status nginx --no-pager.

Разрешите входящие запросы к сайту

Для проверки сертификата и обычного сайта извне нужны TCP-порты 80 и 443. Если на VPS включён UFW, разрешите профиль Nginx, но не удаляйте правило SSH:

sudo ufw app info 'Nginx Full'
sudo ufw allow 'Nginx Full'
sudo ufw status verbose

Первая команда показывает, какие порты содержит профиль; ожидаются 80 и 443 по TCP. Вторая добавляет разрешение, третья выводит итоговые правила. Если вы не используете профиль, разрешайте точные порты по инструкции о UFW и nftables.

Провайдер может фильтровать входящие соединения ещё и в своей панели. Разрешение UFW не проходит сквозь внешний запрет. Проверьте, что облачный сетевой фильтр также пропускает 80 и 443, а правило прикреплено именно к этому VPS.

Добейтесь рабочего HTTP до выпуска сертификата

С внешнего компьютера откройте http://example.org/ или запросите только заголовки командой:

curl -I http://example.org/

Ответ должен прийти от вашего Nginx. Код 200 означает, что страница найдена. Если открывается стандартная страница Nginx или другой сайт, запрос выбрал не тот блок server: проверьте server_name, активные ссылки в sites-enabled и DNS.

При тайм-ауте сначала используйте последовательность из статьи о сетевой диагностике VPS. Сертификат не следует настраивать, пока HTTP по домену не работает из внешней сети.

Выпустите сертификат для работающего домена

TLS — протокол, который шифрует HTTPS-соединение и позволяет браузеру проверить сертификат сайта. Сертификат связывает доменное имя с ключом сервера. Бесплатные сертификаты Let’s Encrypt выдаются на ограниченный срок и поэтому должны продлеваться автоматически.

Certbot получает сертификат и может добавить HTTPS-настройки в Nginx. Способ его установки зависит от поддерживаемой версии Ubuntu; перед выполнением откройте официальный мастер Certbot для Nginx. Для предлагаемой там установки через snap команды выглядят так:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx -d example.org -d www.example.org

Первая команда устанавливает Certbot в изолированном формате snap. Вторая делает команду доступной по обычному системному пути. Третья просит сертификат для двух имён и предлагает настроить Nginx. Не включайте www.example.org, если такая DNS-запись ещё не работает.

Во время выпуска укажите действующий адрес электронной почты для важных уведомлений и прочитайте условия центра сертификации. Выберите перенаправление с HTTP на HTTPS, если сайт уже готов постоянно работать по защищённому адресу.

Проверьте HTTPS и будущее продление

С внешнего компьютера выполните два запроса. Первый должен перенаправить на защищённый адрес, второй — вернуть страницу без ошибки сертификата:

curl -I http://example.org/
curl -I https://example.org/

В HTTP-ответе ожидается код перенаправления и заголовок Location: https://example.org/.... HTTPS должен отвечать кодом сайта. Циклические перенаправления, другое доменное имя или ошибка срока сертификата требуют исправления до публикации ссылок.

Certbot устанавливает автоматический запуск продления, но его наличие нужно проверить заранее:

sudo certbot renew --dry-run
systemctl list-timers | grep -i certbot

Параметр --dry-run выполняет тестовое продление через испытательный сервер и не заменяет действующий сертификат. Успешный тест подтверждает, что домен, порт и интеграция Certbot сейчас работают. Вторая команда показывает расписание автоматического запуска.

Что считать готовым результатом

Подключение завершено, если домен возвращает адрес VPS, HTTP перенаправляет на HTTPS, защищённая страница открывается без предупреждения, а тест продления проходит успешно. Сохраните названия DNS-записей, путь конфигурации Nginx и дату следующей автоматической проверки в рабочей заметке.

Замена обычных HTML-файлов не требует перезапуска Nginx. Для изменений конфигурации всегда повторяйте sudo nginx -t перед reload. Следующий урок настроит владельца и права файлов сайта без режима 777, а затем маршрут перейдёт к первой управляемой публикации.

Как отключить ошибочную конфигурацию

Если новый сайт мешает другим доменам, удалите только включающую ссылку, а не сам файл и не каталог с данными:

sudo rm /etc/nginx/sites-enabled/example.org
sudo nginx -t
sudo systemctl reload nginx

После удаления ссылки Nginx перестанет использовать этот блок, но конфигурация останется в sites-available для исправления. Сертификаты и файлы сайта также сохранятся. Это обратимый откат, после которого можно спокойно найти ошибку.

Первоисточники

• NGINX: руководство для начинающих
• NGINX: как выбирается server_name
• Ubuntu Server: сетевой фильтр UFW
• Certbot: официальная инструкция для Nginx
• Let’s Encrypt: как работает проверка HTTP-01