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

Если сайт на вашем сервере BLACKBOX не открывается, пройдите проверки ниже по порядку: каждая исключает одну из причин. Команды из шагов 1, 2 и 9 и три теста curl в конце статьи выполняются на вашем компьютере, остальные — на сервере, по SSH под root. Адрес сервера указан в поле «IP» карточки сервера на странице «Мои серверы» панели app.blackbox.md (app.blackbox.md/my-servers, боковая панель → «Инфраструктура» → «Мои серверы»). Настроек веб-сервера, файрвола и сертификатов в панели нет.

Доступно: всем, у кого есть root-доступ по SSH к серверу BLACKBOX. Другие порты в сетевой фильтрации — по запросу через поддержку.

В командах замените ДОМЕН на ваш домен, а IP_СЕРВЕРА — на адрес сервера.

Коротко: что показывает браузер

Шаг 1. DNS: домен указывает на сервер

В Linux или macOS:

dig +short ДОМЕН
dig +short www.ДОМЕН
dig +short ДОМЕН AAAA

В Windows:

nslookup ДОМЕН

Первые две команды должны вывести IP_СЕРВЕРА (если www — запись CNAME, сначала появится имя, на которое она указывает, например ДОМЕН.). Третья не должна ничего выводить; адреса Cloudflare появятся, только если включён прокси Cloudflare. AAAA-запись, оставшаяся от старого хостинга, уводит часть посетителей на другой сервер — удалите её.

Шаг 2. Сервер работает

ssh root@IP_СЕРВЕРА

Если подключение прошло, сервер запущен и доступен из сети. Если нет — см. Не удаётся подключиться по SSH. Панель не показывает, запущен ли сервер; если вы остановили его кнопкой «Остановить», запустите его кнопкой «Запустить» на карточке (Перезагрузка, остановка и запуск сервера).

Шаг 3. Веб-сервер запущен и слушает порты 80 и 443

1. Проверьте службу. Для Apache вместо nginx укажите apache2 (Ubuntu, Debian) или httpd (AlmaLinux, CentOS Stream). В строке Active: должно быть active (running).

   systemctl status nginx

2. Если там inactive (dead) или failed, проверьте конфигурацию (должно быть «syntax is ok» и «test is successful», иначе команда покажет файл и строку с ошибкой), затем запустите службу и включите её автозапуск:

   nginx -t
   systemctl enable --now nginx

   Для Apache проверка выводит «Syntax OK»:

   # Ubuntu и Debian
   apache2ctl configtest
   # AlmaLinux и CentOS Stream
   apachectl configtest

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

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

Если по IP сайт открывается, а по домену — страница по умолчанию, значит, в server_name (nginx) или ServerName/ServerAlias (Apache) нет ДОМЕН и www.ДОМЕН. Ошибки вызывает и заполненный диск: Диск сервера заполнен.

Шаг 4. Файрвол на сервере пропускает порты 80 и 443

На новых серверах BLACKBOX не включает файрвол операционной системы. Если вы включили его сами, проверьте правила.

Ubuntu и Debian

ufw status

Status: inactive означает, что ufw ничего не блокирует. Если статус active, в списке должны быть 80 и 443 (например, 80,443/tcp ALLOW Anywhere, Nginx Full или Apache Full). Если их нет:

ufw allow 80,443/tcp

AlmaLinux и CentOS Stream

firewall-cmd --list-all

«FirewallD is not running» означает, что firewalld ничего не блокирует. Если он работает, в строке services: должны быть http и https. Если их нет:

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload

Внимание Веб- и VNC-консоли для клиентов нет: сервером управляют только по SSH. Не удаляйте правило для порта 22 и держите открытой вторую SSH-сессию, пока меняете файрвол. Подробнее: Файрвол: сетевая фильтрация и ufw/firewalld на сервере.

Шаг 5. Порт открыт в сетевой фильтрации

Трафик к серверу проходит ещё и через сетевую фильтрацию, которой управляет BLACKBOX. На новом сервере она пропускает SSH (22), HTTP (80), HTTPS (443) и ping; настроек файрвола в панели нет. Приложение на другом порту, например 3000, 8000 или 8080, недоступно из интернета, даже если порт разрешён в ufw или firewalld: запрос завершается по таймауту. Есть два варианта:

• рекомендуемый: поставьте перед приложением nginx на портах 80 и 443 — Приложения Node.js, Python и другие сервисы: nginx как обратный прокси;
• попросите поддержку открыть порт: укажите IP-адрес сервера, номер заказа (BBX-…), порт, протокол (TCP или UDP) и для чего он нужен.

Шаг 6. Приложение слушает правильный адрес

Проверьте, на каком адресе слушает приложение (здесь — порт 3000) и отвечает ли оно на самом сервере:

ss -tlnp | grep ':3000'
curl -I http://127.0.0.1:3000

• 127.0.0.1:3000 — приложение принимает подключения только с самого сервера. Для работы за nginx это правильно (proxy_pass http://127.0.0.1:3000), но напрямую извне оно недоступно.
• 0.0.0.0:3000 или *:3000 — приложение принимает подключения извне, если порт открыт и в сетевой фильтрации (шаг 5).
• Пусто — приложение не запущено или работает на другом порту; смотрите его журналы.

Если на 127.0.0.1 приложение отвечает, а сайт выдаёт 502 Bad Gateway, проверьте адрес и порт в proxy_pass. В AlmaLinux и CentOS Stream строка «(13: Permission denied)» в /var/log/nginx/error.log означает, что подключение блокирует SELinux:

setsebool -P httpd_can_network_connect 1

Контейнер, опубликованный как -p 127.0.0.1:8080:80, тоже слушает только локально: Установка Docker и Docker Compose.

Шаг 7. Сертификат HTTPS действителен

certbot certificates

У сертификата сайта в Domains: должен быть ДОМЕН (и www.ДОМЕН, если вы его используете), а строка Expiry Date: должна заканчиваться на (VALID: … days), а не на (INVALID: EXPIRED). «No certificates found.» означает, что на сервере не выпущено ни одного сертификата. Если сертификат истёк, проверьте продление, продлите его и перезагрузите конфигурацию веб-сервера (для Apache вместо nginx укажите apache2 или httpd):

certbot renew --dry-run
certbot renew
systemctl reload nginx

Какой сертификат на самом деле получает посетитель, покажет второй тест curl. Если там по-прежнему старый, веб-сервер не перечитал конфигурацию или в настройках для порта 443 указаны другие файлы. Ошибки certbot: Веб-сервер с HTTPS: nginx или Apache и Let's Encrypt. Коммерческий сертификат: SSL-сертификаты: бесплатные (Let's Encrypt) и коммерческие.

Шаг 8. Ошибки Cloudflare

Если домен проходит через прокси Cloudflare (на странице «DNS» панели у записи отмечен флажок «Прокси» или прокси включён прямо в аккаунте Cloudflare), Cloudflare сам подключается к вашему серверу и при неудаче показывает свою страницу ошибки.

Режим SSL выбирается в аккаунте Cloudflare, в разделе «SSL/TLS»; страница «DNS» панели его не меняет. Включайте «Full (strict)», когда на сервере уже есть действительный сертификат (документация Cloudflare о режимах SSL). Чтобы проверить сервер без Cloudflare, выполните третий тест curl или временно снимите флажок «Прокси».

Шаг 9. Кэш браузера и HSTS

• Откройте сайт в приватном окне, в другом браузере или из другой сети (например, через мобильный интернет) и сравните с тестами curl ниже.

• После изменения DNS очистите DNS-кэш компьютера. В Windows:

  ipconfig /flushdns

• HSTS: если сайт уже отправлял заголовок Strict-Transport-Security, браузер открывает его только по HTTPS и не даёт пропустить ошибку сертификата. Решение — действительный сертификат (шаг 7).

Три теста с curl

Выполняйте их на своём компьютере. В Windows PowerShell вместо curl пишите curl.exe.

1. Веб-сервер отвечает по IP, без DNS:

   curl -I http://IP_СЕРВЕРА

   Любой HTTP-ответ (200, 301, 403, 404) — сервер, сеть и порт 80 в порядке. Мгновенная ошибка (Connection refused, Couldn't connect to server) — порт 80 никто не слушает (шаг 3). Таймаут после долгого ожидания — пакеты отбрасываются (шаги 2, 4, 5).

2. Что получает посетитель:

   curl -vk https://ДОМЕН

   -k продолжает работу, даже если сертификат недействителен. Строка Connected to ДОМЕН (…) port 443 показывает, на какой адрес ушёл запрос. Строки subject: и expire date: — имя в сертификате и дата окончания его действия (curl в Windows может их не выводить). Строка < HTTP… — код ответа.

3. Ваш сервер в обход DNS и Cloudflare (--resolve отправляет запрос прямо на IP_СЕРВЕРА с именем домена):

   curl -I --resolve ДОМЕН:443:IP_СЕРВЕРА https://ДОМЕН

Совет Если третий тест проходит, а второй нет, с сервером всё в порядке: проблема в DNS (шаг 1) или в Cloudflare (шаг 8). Если третий тест выдаёт ошибку сертификата, исправьте сертификат (шаг 7).

Журналы

Последние строки журнала веб-сервера и журнала службы:

tail -n 50 /var/log/nginx/error.log
journalctl -u nginx -n 50 --no-pager

Журналы приложения: для службы systemd — первая команда, для контейнера — вторая, для Docker Compose — третья, из каталога проекта.

journalctl -u ИМЯ_СЕРВИСА -n 100 --no-pager
docker logs --tail 100 ИМЯ_КОНТЕЙНЕРА
docker compose logs --tail 100

Когда писать в поддержку

Если все проверки пройдены, а сайт по-прежнему не открывается извне, напишите нам: Создание тикета в поддержку. Укажите домен, IP-адрес сервера, номер заказа (BBX-…), результаты трёх тестов curl и то, что вы уже проверили.

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

Сайт работал, а потом перестал, хотя я ничего не менял. Чаще всего это истёкший сертификат (шаг 7), заполненный диск (Диск сервера заполнен) или остановившееся приложение (шаги 3 и 6). Если сайт пропал после перезагрузки, скорее всего, у службы не был включён автозапуск: включите его для веб-сервера и для приложения, как в шаге 3.

С телефона сайт открывается, а с компьютера — нет. Причина на компьютере или в вашей сети: DNS-кэш, кэш браузера или старая запись для домена в файле hosts (C:\Windows\System32\drivers\etc\hosts в Windows, /etc/hosts в Linux и macOS). См. шаг 9.

У меня тариф «VPS hosting» с панелью управления. Если на сервере работает панель управления, сайтами, веб-сервером и сертификатами управляйте через неё; не ставьте поверх неё другой веб-сервер. Тесты с dig и curl работают и здесь. Какая панель установлена и как в неё войти, уточните в поддержке: Тарифы «VPS hosting» с панелью управления.