Почему сайт на VPS не открывается: проверяем сеть по порядку

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

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

Как запрос попадает на сайт

Когда посетитель вводит домен, компьютер сначала узнаёт его IP-адрес через DNS. DNS — система, которая связывает удобное имя вроде example.com с числовым адресом сервера. Затем компьютер открывает соединение с определённым портом этого адреса: обычно 80 для HTTP или 443 для HTTPS.

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

Получается последовательность:

1. Домен возвращает правильный IP-адрес.
2. До IP-адреса существует сетевой путь.
3. Правила провайдера и VPS пропускают нужный порт.
4. Веб-сервер слушает этот порт.
5. Веб-сервер узнаёт домен и возвращает правильный сайт.

Каждый следующий шаг имеет смысл только после предыдущего.

Сначала запишите точную ошибку

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

Команда ниже выполняется на внешнем компьютере. Она показывает заголовки ответа, ограничивает ожидание соединения пятью секундами и не загружает всё содержимое страницы:

curl -I --connect-timeout 5 https://example.com/

Замените example.com своим доменом. Параметр -I запрашивает только заголовки HTTP, а --connect-timeout 5 прекращает попытку, если соединение не установилось за пять секунд.

Сохраните точный результат. Could not resolve host указывает на проблему получения адреса по имени. Connection refused означает, что адрес ответил отказом на выбранном порту. Connection timed out чаще говорит о фильтрации или недоступном маршруте. Ответ вида HTTP/2 404 или HTTP/1.1 502 доказывает, что сеть уже довела запрос до веб-сервера; тогда причину ищут в его настройках или приложении.

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

Подключитесь к серверу по SSH и посмотрите адреса его сетевых интерфейсов. Сетевой интерфейс — программное представление сетевого подключения, через которое Linux отправляет и получает данные:

ip -brief address
ip route

Первая команда сокращённо показывает интерфейсы, их состояние и адреса. Рабочий интерфейс обычно имеет состояние UP. Адрес 127.0.0.1 принадлежит только самому серверу и не является публичным. Публичный адрес может совпадать с панелью провайдера или, при отдельной схеме трансляции адресов, назначаться провайдером снаружи.

Вторая команда показывает маршруты — правила, по которым Linux выбирает направление для пакетов. Для обычного VPS ожидается строка, начинающаяся с default via: после неё указан шлюз провайдера для внешнего трафика. Не добавляйте адрес или маршрут вручную, пока не сравните вывод с сетевыми данными в панели и документации провайдера.

Если SSH к этому же публичному адресу работает, базовый входящий путь уже существует. Тогда вероятнее проблема конкретного порта или программы, а не полное отсутствие сети.

Убедитесь, что веб-сервер слушает нужный порт

Порт можно представить как номер входа для конкретной сетевой программы. Слово «слушает» означает, что программа запущена и ожидает новые соединения на этом номере.

На VPS выполните:

sudo ss -lntp

Команда ss показывает сетевые соединения. Параметры оставляют только слушающие TCP-порты, показывают номера без преобразования в имена и добавляют процесс-владелец. sudo нужен, чтобы увидеть названия всех процессов.

Для обычного сайта ищите порт 80, а после подключения HTTPS — 443. Запись 0.0.0.0:80 означает приём на всех IPv4-интерфейсах. [::]:443 относится к IPv6 и в некоторых настройках также принимает IPv4. 127.0.0.1:80 доступен только с самого VPS, поэтому внешний посетитель к такому адресу не подключится.

Если нужного порта нет, сетевой фильтр пока ни при чём: принимать соединение некому. Проверьте состояние веб-сервера, например systemctl status nginx, и его конфигурацию. Если порт есть, переходите к правилам доступа.

Проверьте ответ программы изнутри сервера

Локальный запрос не проходит через внешний сетевой фильтр, но подтверждает, что веб-сервер способен ответить. Выполните его на VPS, подставив имя своего сайта:

curl -I -H 'Host: example.com' http://127.0.0.1/

Адрес 127.0.0.1 направляет запрос на этот же VPS. Заголовок Host сообщает Nginx, какой из размещённых сайтов запрошен. Это важно, если один веб-сервер обслуживает несколько доменов.

Ответ 200, 301 или 302 обычно означает, что Nginx нашёл сайт и вернул страницу либо ожидаемое перенаправление. 404 от Nginx показывает, что запрос дошёл до программы, но она не выбрала нужный сайт или не нашла файл. 502 означает, что Nginx работает, но не получил правильный ответ от приложения за ним. Эти случаи исправляются в конфигурации веб-сервера или приложения, а не в DNS.

Посмотрите правила доступа на VPS

Сетевой фильтр, который часто называют firewall, разрешает или запрещает соединения по адресу, порту и источнику. В Ubuntu им нередко управляют через UFW. Эта программа создаёт правила Linux в более простой форме.

Если вы настраивали UFW, сначала только посмотрите его состояние:

sudo ufw status verbose

Состояние inactive означает, что UFW сейчас не применяет свои правила. При active найдите разрешения для 80/tcp и 443/tcp, если сайту уже нужен HTTPS. Также должно сохраняться правило для фактического порта SSH.

Не отключайте UFW целиком ради проверки. Добавьте отсутствующее точечное правило по инструкции о сетевом фильтре Ubuntu, снова выполните внешний запрос и убедитесь, что не открылись ненужные службы.

У провайдера может быть ещё один сетевой фильтр в панели — его называют облачным firewall или группой безопасности. Правила Ubuntu его не отменяют. Сверьте привязку правила к нужному VPS и отдельно проверьте входящие TCP-порты 80 и 443 для IPv4 и IPv6, если IPv6 используется.

Проверьте, куда ведёт домен

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

nslookup example.com

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

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

Подключение записей и HTTPS с самого начала разобрано в отдельной инструкции о домене, Nginx и сертификате.

Отдельно проверьте HTTP и HTTPS

HTTP на порту 80 и HTTPS на порту 443 — два разных соединения. Рабочий HTTP не подтверждает наличие сертификата, а исправный сертификат не гарантирует ответ приложения.

С внешнего компьютера выполните оба запроса:

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

Первый запрос часто должен вернуть перенаправление 301 или 308 на адрес с https://. Во втором ожидается успешный ответ сайта. Проверьте, что перенаправление ведёт на правильный домен, а не образует цикл.

Если HTTPS сообщает о несовпадении имени, сервер предъявляет сертификат для другого домена. Ошибка срока действия требует проверки часов VPS и процедуры продления. Не используйте параметр -k как исправление: он лишь отключает проверку сертификата у конкретного клиента и скрывает проблему.

Как читать итог проверки

Используйте первую неудачную точку:

• домен возвращает другой IP — исправляйте DNS;
• у VPS нет ожидаемого адреса или маршрута — сверяйтесь с панелью провайдера;
• нужный порт отсутствует в ss — запускайте и настраивайте веб-сервер;
• локальный запрос работает, внешний получает тайм-аут — проверяйте фильтры VPS и провайдера;
• внешний запрос получает HTTP-ошибку — разбирайте Nginx или приложение;
• HTTP работает, HTTPS нет — проверяйте порт 443 и сертификат.

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

Для обращения в поддержку приложите время проверки, домен, публичный IP, точный текст ошибки и относящийся к ней вывод. Перед отправкой удалите cookie, заголовки авторизации, токены и внутренние адреса, которые не нужны для диагностики.

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

• Ubuntu Server: основы сетевой конфигурации
• Ubuntu Server: настройка UFW
• NGINX: руководство для начинающих
• curl: параметры командной строки