MHOSTMHOST

Сайт не открывается

Когда сайт не открывается, причина почти всегда одна из немногих: веб-сервер не запущен, порт закрыт файрволом, DNS указывает не туда, истёк SSL-сертификат или в конфигурации есть ошибка, которую видно только в логах. В этой статье — пошаговая диагностика на VPS mHost: от процесса на сервере до браузера пользователя, — которая поможет быстро найти, что именно сломалось.

Что понадобится

  • Доступ по SSH под root или пользователем с sudo — большинство проверок выполняются в терминале.
  • Домен, который должен указывать на этот VPS, — понадобится для Шагов 5 и 6 (DNS и SSL). Если сайт пока должен открываться только по IP, эти два шага можно пропустить.
  • Информация о том, какой веб-сервер установлен — Nginx, Apache или Caddy. Если не уверены, посмотрите статьи «Nginx: установка и первый сайт», «Apache: установка и виртуальные хосты» или «Caddy: автоматический HTTPS» — либо просто попробуйте команды для каждого из них по очереди в Шаге 2.
Совет: проверяйте шаги по порядку — каждый следующий шаг предполагает, что предыдущий пройден успешно. Если уже понятно, в какую сторону копать (например, браузер прямо указывает на проблему с сертификатом), можно сразу перейти к нужному шагу.

Шаг 1. Определите симптом: как именно сайт не открывается

То, как именно отвечает (или не отвечает) сервер, сразу сужает круг подозреваемых. Проверьте с любого компьютера с доступом в интернет — не обязательно с самого сервера:

bash
curl -I --max-time 10 https://example.com

Замените example.com на свой домен. Если сайт пока без HTTPS, замените https:// на http://. По тому, чем именно ответит curl, определите, какой шаг проверять первым:

Важно: если проверяете curl прямо на сервере по адресу 127.0.0.1 или localhost, результат докажет только то, что сервис отвечает локально, — и ничего не скажет о доступности сайта снаружи: файрвол и DNS на loopback-адрес не влияют. Для реальной картины проверяйте по домену или публичному IP, желательно с другого компьютера.
  • Ошибка `curl: (6)` — «Could not resolve host» — домен вообще не резолвится: опечатка в адресе либо DNS ещё не настроен — см. Шаг 5.
  • Ошибка `curl: (7)` — «Connection refused» — до сервера пакеты доходят, но порт закрыт: сервис не запущен либо слушает не тот адрес или порт — см. Шаги 2–3.
  • Ошибка `curl: (28)` — «Connection timed out» — запрос зависает и не получает ответа вообще: чаще всего файрвол молча отбрасывает пакеты — см. Шаг 4. Причиной может быть и неверный IP в DNS-записи.
  • Ошибка `curl: (60)` — «SSL certificate problem» (или предупреждение о сертификате в браузере) — проблема с TLS-сертификатом — см. Шаг 6.
  • Ответ приходит с кодом 500, 502, 503 или 504 — веб-сервер отвечает, но с ошибкой на своей стороне или на стороне приложения за ним — см. Шаг 7 (логи).
  • Ответ приходит, но не то, что ожидалось (404, чужой сайт, старая версия страницы) — сеть и сертификат в порядке, дело в конфигурации самого сайта — тоже см. Шаг 7.

Если не уверены, что именно не так, — просто пройдите Шаги 2–7 по порядку.

Шаг 2. Проверьте, что веб-сервер запущен

Самая частая причина — служба веб-сервера остановлена или упала после ошибки в конфигурации. Команда systemctl status зависит от того, какой веб-сервер установлен:

  • Nginx (все дистрибутивы) — systemctl status nginx
  • Apache на Ubuntu/Debian — systemctl status apache2
  • Apache на AlmaLinux/Rocky Linux — systemctl status httpd
  • Caddy (все дистрибутивы) — systemctl status caddy
bash
systemctl status nginx

Пример, когда всё в порядке:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-07-09 10:12:03 UTC; 2h 14min ago
       Docs: man:nginx(8)
   Main PID: 1234 (nginx)

Пример, когда служба упала:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Thu 2026-07-09 12:40:11 UTC; 3min ago

Важна строка Active: active (running) — служба работает; inactive (dead) — остановлена, но не упала; failed — упала, обычно из-за ошибки в конфигурации или занятого порта.

Если служба не active (running), запустите её (замените nginx на нужное имя службы из списка выше):

bash
sudo systemctl start nginx

Если сразу после этого статус снова failed, посмотрите причину в системном журнале:

bash
sudo journalctl -xeu nginx --no-pager -n 50
Совет: если служба вообще отказывается стартовать и journalctl показывает ошибку конфигурации или занятый порт — это отдельная тема, разобрана подробнее в статье «Служба не запускается».

Шаг 3. Проверьте, что сервер слушает порты 80 и 443

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

bash
sudo ss -tlnp | grep -E ':80 |:443 '

Пример вывода, когда всё в порядке:

LISTEN 0      511          0.0.0.0:80         0.0.0.0:*    users:(("nginx",pid=1234,fd=6))
LISTEN 0      511          0.0.0.0:443        0.0.0.0:*    users:(("nginx",pid=1234,fd=7))
  • State — LISTEN означает, что порт открыт и ждёт подключений.
  • Local Address:Port — адрес и порт, которые слушает процесс. 0.0.0.0 (или *) означает все сетевые интерфейсы, порт доступен снаружи; 127.0.0.1 — только сам сервер, снаружи (и даже по домену или IP сервера) недоступен.
  • Process — какой именно процесс держит порт (имя и PID).

Если строк с портом 80 или 443 нет вообще — на сервере никто их не слушает. Вернитесь к Шагу 2: либо служба не запущена, либо в её конфигурации указан другой listen (nginx) / Listen (Apache).

Совет: если сайт работает через reverse proxy — например, Node.js-приложение из статьи «Node.js приложение с PM2 и Nginx» или контейнер из статьи «Docker и Docker Compose», — на портах 80/443 должен слушать именно Nginx или Apache, а само приложение — свой внутренний порт, обычно на 127.0.0.1. Если 80/443 не слушает никто, а внутренний порт приложения — слушает, значит reverse proxy не настроен или не запущен.
Готово: если для портов 80 и 443 есть строки LISTEN с адресом 0.0.0.0 (или *) — сервис слушает как надо, проблема не здесь. Переходите к Шагу 4.

Шаг 4. Проверьте файрвол

Даже если сервис слушает порт правильно, файрвол на самом VPS может блокировать входящие соединения снаружи.

Ubuntu / Debian (ufw)

bash
sudo ufw status

Пример:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Если строк для 80/443 нет, добавьте их:

bash
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

AlmaLinux / Rocky Linux (firewalld)

bash
sudo firewall-cmd --list-all

Ищите в выводе строку services — она должна содержать http и https (либо соответствующие порты должны быть перечислены в строке ports):

services: ssh dhcpv6-client http https

Если http/https в выводе нет, откройте их:

bash
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
Совет: если снаружи запрос зависает и обрывается по таймауту (curl-ошибка 28 из Шага 1), а не получает мгновенный connection refused, — это типичный симптом именно закрытого файрвола: пакеты просто отбрасываются без ответа.
Совет: полный разбор установки и настройки ufw — порты, политика по умолчанию, профили — в статье «Файрвол ufw: порты».
Готово: если 80 и 443 разрешены в выводе выше — файрвол не блокирует сайт, проблема не здесь. Переходите к Шагу 5.

Шаг 5. Проверьте DNS: указывает ли домен на этот сервер

Сервис запущен, порт открыт — а сайт всё равно не открывается по домену? Проверьте, что домен вообще указывает на IP этого VPS.

bash
dig +short example.com

Ожидаемый результат — IP-адрес, совпадающий с публичным IP вашего VPS (посмотреть его можно в карточке сервера в VMmanager 6, либо прямо на сервере командой curl -4 ifconfig.me).

Если dig вернул пустой ответ или другой IP, учтите задержку на распространение изменений (TTL) и проверьте напрямую через публичный DNS-резолвер, в обход возможного локального кеша:

bash
dig +short example.com @1.1.1.1

Чтобы убедиться, что дело именно в DNS, а не в самом сервере, обратитесь к серверу напрямую по IP с заголовком Host — так, будто домен уже резолвится правильно:

bash
curl -I -H "Host: example.com" http://203.0.113.10/

Замените 203.0.113.10 на реальный IP сервера. Если так сайт открывается (код 200 OK), а по домену — нет, проблема на 100% в DNS, а не на сервере.

Совет: как устроены DNS-записи и сколько занимает их обновление — в статье «Основы DNS»; как именно привязать домен к VPS mHost — в статье «Привязка домена к серверу».
Готово: если dig +short example.com возвращает IP вашего сервера — DNS настроен верно, проблема не здесь. Переходите к Шагу 6 (если сайт на HTTPS) или к Шагу 7.

Шаг 6. Если сайт на HTTPS — проверьте сертификат

Актуально, если браузер показывает предупреждение о сертификате или соединение обрывается именно на порту 443 (а не молчит вовсе — это был бы Шаг 3 или 4).

Проверьте сам сертификат, не открывая браузер:

bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates

Пример вывода:

subject=CN=example.com
notBefore=Mar 11 08:00:00 2026 GMT
notAfter=Jun  9 08:00:00 2026 GMT
  • notAfter — дата истечения. Если она в прошлом, сертификат просрочен — именно этим чаще всего объясняется предупреждение NET::ERR_CERT_DATE_INVALID в Chrome.
  • subject — домен, на который выпущен сертификат. Если он не совпадает с адресом в браузере (например, сертификат только на www.example.com, а открывают example.com без www), браузер покажет ошибку несовпадения имени, даже если сам сертификат ещё действителен.

Если сертификат выпущен через certbot (обычно вместе с Nginx или Apache), посмотрите список сертификатов и их статус:

bash
sudo certbot certificates
Found the following certs:
  Certificate Name: example.com
    Domains: example.com www.example.com
    Expiry Date: 2026-06-09 08:00:00+00:00 (INVALID: EXPIRED)
    Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem

Если сертификат просрочен, проверьте, почему не сработало автопродление, и продлите вручную:

bash
systemctl list-timers | grep certbot
sudo journalctl -u snap.certbot.renew.service --no-pager -n 50
sudo certbot renew

Самые частые причины провала автопродления:

  • Порт 80 был закрыт в момент продления — certbot проверяет владение доменом по HTTP, без открытого порта 80 продление не проходит — см. Шаг 4.
  • Домен перестал указывать на этот сервер — сменили DNS-запись или перенесли сайт — см. Шаг 5.
  • Сертификат выпущен на другое имя, чем то, что реально открывают в браузере, — само по себе продление тут ни при чём, нужно перевыпустить сертификат с нужными доменами.
Совет: если сайт работает на Caddy — сертификаты он получает и продлевает сам, без certbot, и команда certbot certificates тут не подойдёт. Смотрите его собственные логи: journalctl -u caddy -n 50 --no-pager — там будут видны ошибки получения сертификата, если они есть.
Совет: полная настройка HTTPS через certbot, включая автопродление, — в статье «Бесплатный SSL с Let's Encrypt (certbot)».

Шаг 7. Прочитайте логи веб-сервера

Если служба запущена, порты открыты, DNS и сертификат в порядке, а сайт всё равно отвечает не так, как нужно, — ответ почти всегда в логах.

  • Nginx — /var/log/nginx/error.log и /var/log/nginx/access.log (все дистрибутивы).
  • Apache на Ubuntu/Debian — /var/log/apache2/error.log и /var/log/apache2/access.log, либо отдельные файлы для конкретного сайта, если они заданы в VirtualHost через ErrorLog/CustomLog.
  • Apache на AlmaLinux/Rocky Linux — /var/log/httpd/error_log и /var/log/httpd/access_log.
  • Caddy — по умолчанию пишет в системный журнал, а не в файл: journalctl -u caddy -n 50 --no-pager.
bash
sudo tail -n 50 /var/log/nginx/error.log
Совет: если в конфигурации сайта заданы свои пути логов, фактические пути для nginx покажет команда sudo nginx -T | grep -E 'access_log|error_log' — она выводит все директивы access_log/error_log из основного конфига и всех подключённых файлов сразу.

Если сама служба не стартует и до записи в error.log дело не доходит, посмотрите системный журнал:

bash
sudo journalctl -xeu nginx --no-pager -n 50

Типичные записи в логах и что они означают:

  • `bind() to 0.0.0.0:80 failed (98: Address already in use)` — порт уже занят другим процессом: например, Apache и Nginx запущены одновременно, или остался «зависший» старый процесс. Найдите его: sudo ss -tlnp | grep ':80 '.
  • `No such file or directory` для корня сайта — неверный root (nginx) или DocumentRoot (Apache), либо в каталоге нет index.html/index.php.
  • `(13: Permission denied)` при чтении файлов сайта, `403 Forbidden` в браузере — не хватает прав на файлы/каталоги, либо (на AlmaLinux/Rocky) доступ блокирует SELinux — пример настройки контекста через semanage/restorecon есть в статье «Nginx: установка и первый сайт».
  • `connect() failed (111: Connection refused) while connecting to upstream` — это ошибка не самого веб-сервера, а backend-приложения за ним: оно не запущено или слушает не тот порт. Проверьте процесс приложения — статьи «Node.js приложение с PM2 и Nginx», «Python и FastAPI: продакшн-деплой», «Django на VPS», «Docker и Docker Compose».
  • 502 или 504 в браузере и в access.log — то же самое: backend недоступен или отвечает слишком медленно.
  • Логи не растут вообще, или последняя запись обрывается на середине строки — вероятно, на сервере закончилось место на диске — см. статью «Диск заполнен».
  • Сайт открывается, но очень медленно или не всегда — это уже не «не открывается», а высокая нагрузка на сервер — см. статью «Высокая нагрузка на сервер».

Что дальше

Если прошли все шаги, а сайт по-прежнему не открывается или причина не нашлась в перечисленном выше, — скорее всего, дело уже не в инфраструктуре VPS, а в коде или конфигурации самого приложения. Смежные темы: полная настройка HTTPS — статья «Бесплатный SSL с Let's Encrypt (certbot)»; файрвол — статья «Файрвол ufw: порты»; если не запускается сама служба — статья «Служба не запускается»; общий чек-лист базовой защиты сервера — статья «Чеклист базовой защиты VPS».

Похожие статьи

НазадНе могу подключиться по SSHДалееСервис не запускается