Что делать, если сайт не открывается: диагностика от DNS до приложения

Сайт работал вчера. Сегодня браузер показывает ошибку. И вот здесь начинается самое опасное: желание немедленно что-нибудь поменять — перезапустить сервер, перевыпустить сертификат, изменить DNS или переписать конфигурацию Nginx.

Иногда после этого сайт действительно оживает. Но остаётся неприятный вопрос: а что именно было сломано? Хорошая диагностика устроена иначе. Сайт — это цепочка нескольких систем. Если проверять их последовательно, область поиска очень быстро сужается.

Кот-детектив проверяет цепочку сайта от домена и DNS до Nginx и приложения

Сначала вспомним весь путь запроса

Когда человек открывает https://example.com, происходит примерно такая последовательность:

доменDNSIP443 / TLSNginxприложениеответ

Каждый элемент зависит от предыдущего. Если DNS приводит браузер не на тот сервер, бессмысленно изучать конфигурацию Nginx на правильной машине. Если TLS уже устанавливается, не нужно снова менять DNS из-за ошибки приложения.

Шаг первый: домен вообще существует?

Начнём с очевидного, которое иногда забывают проверить. Правильно ли написан домен? Не истёк ли срок его регистрации? Используется ли нужная доменная зона? Нет ли случайной опечатки вроде exmaple.com вместо example.com?

Пока имя неверно, вся дальнейшая цепочка не имеет значения.

Шаг второй: что говорит DNS

Следующий вопрос: на какой IP сейчас указывает домен?

Ожидаемый ответ DNS

example.com → 203.0.113.10

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

Если DNS показывает старый IP

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

Если авторитетный DNS уже возвращает новый адрес, а конкретное устройство всё ещё получает старый, чаще всего нужно не менять запись ещё раз, а дождаться окончания TTL.

Если DNS правильный — идём дальше

Предположим, example.com → 203.0.113.10, и это действительно IP нужного сервера. Первый слой можно считать проверенным.

домен ✓DNS ✓IP ✓сеть ?дальше ?

Мы уже исключили огромный класс возможных причин.

Сервер вообще доступен?

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

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

Порт — это отдельная проверка

Даже если сервер доступен по сети, нужный сервис может не принимать соединения. Для сайта особенно интересны два порта: 80 для HTTP и 443 для HTTPS.

🌐80 отвечаетHTTP доступен

🔒443 отвечаетможно проверять TLS

🚧порт закрытfirewall или сервис не слушает

HTTP работает, HTTPS не работает

Это одна из самых полезных диагностических ситуаций. Если http://example.com открывается, а https://example.com нет, базовый сервер доступен и DNS работает. Проблема находится где-то около порта 443, TLS или HTTPS-конфигурации.

443TLSсертификатNginx HTTPSпроверить

HTTPS открывается, но браузер ругается на сертификат

Это означает, что браузер уже нашёл IP, подключился к серверу, дошёл до порта 443, начал TLS-соединение и получил сертификат.

Теперь нужно смотреть именно на сертификат: подходит ли он для домена, не истёк ли срок, не нарушена ли цепочка доверия и не выбран ли вообще HTTPS-блок другого сайта.

Сертификат чужого сайта — особенно интересный сигнал

Если вы открываете example.com, а браузер показывает сертификат для another-site.com, запрос, вероятно, пришёл на сервер, но Nginx выбрал неправильный виртуальный хост.

Проверяем server_name, HTTPS server-блок, SNI и конфигурацию по умолчанию.

Открывается стандартная страница Nginx

Это даже хорошая новость. DNS, скорее всего, привёл к серверу, порт доступен, Nginx работает и браузер получил HTTP-ответ.

Теперь вопрос намного уже: почему Nginx выбрал не тот сайт? Частые причины — неправильный server_name, неактивная конфигурация или default_server.

Проверяем server_name

Ожидаемый виртуальный хост

server {
    listen 443 ssl;
    server_name example.com www.example.com;
}

Если имя не совпадает, Nginx не станет угадывать и может выбрать другой блок.

Конфигурация существует, но Nginx её не читает

Файл может лежать на сервере, выглядеть идеально и при этом вообще не участвовать в работе. Например, он находится в /etc/nginx/sites-available/, но не подключён через /etc/nginx/sites-enabled/.

В этот момент проблема уже не в содержимом файла: Nginx просто его не использует.

Поэтому сначала nginx -t

После изменения конфигурации полезно придерживаться одной и той же последовательности.

изменитьсохранитьnginx -treloadпроверитьготово

Проверка и применение

nginx -t
systemctl reload nginx

Если Nginx выбрал правильный сайт

Предположим, DNS правильный, HTTPS работает, сертификат хороший, а Nginx выбирает нужный server_name. Теперь нужно выяснить, что Nginx должен отдавать: файлы с диска или внутреннее приложение.

Статический сайт: проверяем root

Папка сайта

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

Теперь нужно убедиться, что файл действительно существует по адресу /var/www/example/index.html. Типовая ошибка: файлы лежат в одной папке, а Nginx смотрит в другую.

404 — это уже ответ

404 Not Found часто воспринимается как полный отказ сайта, хотя с точки зрения диагностики это довольно успешный результат. Сервер получил запрос, Nginx его обработал и сформировал ответ.

Проблема находится уже на уровне маршрута или отсутствующего ресурса.

403 — сервер нашёл что-то, но не отдаёт

403 Forbidden означает, что запрос понятен, но доступ запрещён. Причиной могут быть права на файлы, правила Nginx или ограничения доступа.

DNS, порт и TLS в этот момент уже не главные подозреваемые.

502 почти кричит: «смотри приложение»

Reverse proxy

location / {
    proxy_pass http://127.0.0.1:3000;
}

При 502 Bad Gateway Nginx принимает запрос нормально, но не получает ожидаемый ответ от приложения. Возможные причины уже конкретны: приложение не запущено, слушает другой порт, процесс упал или указан неправильный адрес.

503 — сервис временно недоступен

503 Service Unavailable обычно говорит, что сервис сейчас не способен обработать запрос: режим обслуживания, перегрузка или проблема с backend.

504 — кто-то слишком долго молчит

504 Gateway Timeout часто появляется, когда Nginx передал запрос приложению, но не дождался ответа вовремя. Backend может существовать, но отвечать слишком медленно — например, зависнуть на базе данных или внешнем API.

500 — приложение запустилось, но что-то пошло не так

500 Internal Server Error обычно означает, что запрос дошёл до приложения, но внутри произошла ошибка. Если пользователь видит 500 через работающий HTTPS, не стоит начинать с DNS и сертификата: эта часть цепочки уже отработала.

Именно поэтому нужны логи

Когда интерфейс говорит только 500, лог может сообщить намного больше.

Примеры реальных причин

database connection refused
permission denied
environment variable not found
address already in use

В этот момент проблема перестаёт быть загадкой. Логи — не последнее средство, а обычная часть диагностики.

У Nginx тоже есть логи

Типичные пути

/var/log/nginx/access.log
/var/log/nginx/error.log

access.log помогает понять, пришёл ли запрос и какой код вернулся. error.log часто объясняет, почему не открылся файл или почему недоступен upstream.

Самая полезная проверка: запрос вообще виден в логах?

Если пользователь открывает сайт, а новой записи в access.log нет, запрос, вероятно, вообще не дошёл до этого Nginx. Тогда возвращаемся назад: DNS, IP, порт, другой сервер, CDN или прокси.

Если запись появляется — Nginx запрос получил. Предыдущие этапы можно в основном исключить.

Не перезапускайте всё сразу

Плохая стратегия

restart nginx
restart app
restart database
change DNS
renew certificate
reboot server

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

Четыре типовых ситуации

🌐По IP работаетпо домену нет → DNS или server_name

🔒HTTP работаетHTTPS нет → 443, TLS, сертификат

🚪HTTPS даёт 502смотрите Nginx → backend

🧭Открывается чужой сайтserver_name, SNI, default_server

Сайт работает на сервере, но не снаружи

Если запрос к localhost работает, а с другого компьютера нет, это похоже на сетевую границу. Приложение может слушать только 127.0.0.1, внешний порт может быть закрыт firewall или запрос не доходит до машины.

Вчера работало, сегодня нет

Полезный вопрос: что изменилось? Сертификат истёк? Сервер перезагрузился? Приложение не стартовало автоматически? Закончился диск? Обновился пакет? Упал внешний сервис?

Даже если никто «ничего не трогал», системы меняются со временем: сроки истекают, диски заполняются, процессы падают.

Проверяйте диск

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

Иногда причина очень простая

No space left on device

Проверяйте процессы и порты приложения

Если Nginx проксирует запрос приложению, убедитесь, что процесс действительно существует и слушает ожидаемый порт. Например, Nginx отправляет на 127.0.0.1:3000, а приложение после обновления запустилось на 127.0.0.1:3001.

Обе системы исправны. Они просто разговаривают через разные двери.

Не забывайте про базу данных и внешние API

Цепочка может продолжаться дальше: браузер → Nginx → приложение → база данных → внешний API. Если база недоступна или сторонний сервис отвечает ошибкой, вся внешняя инфраструктура сайта может быть исправна, а функция всё равно не работать.

«Сайт не открывается» и «сайт работает неправильно» — не одно и то же

Если браузер вообще не может установить соединение, смотрим ранние уровни: DNS → сеть → порт → TLS. Если HTML уже открылся, но данные не загружаются, мы намного дальше: Nginx → приложение → API → база.

Можно собрать диагностику в одну лестницу

1Доменимя существует?

2DNS / IPведёт на нужную машину?

3Сеть / портдо сервера можно добраться?

4TLSзащищённое соединение устанавливается?

5Сертификатимя и срок корректны?

6Nginxвыбран нужный сайт?

7Маршруткуда уходит запрос?

8Файл / appесть ли ответ?

9Данныебаза и API доступны?

Не возвращайтесь назад без причины

Вы проверили DNS — он возвращает правильный IP. Не меняйте его снова из-за 502. Сертификат действителен — не перевыпускайте его из-за ошибки приложения. Nginx выбрал правильный блок — не переписывайте виртуальный хост из-за сломанной базы.

Каждый подтверждённый слой нужно временно считать невиновным.

После исправления проверьте цепочку ещё раз

Открывается ли домен? Работает ли HTTPS? Нет ли предупреждения сертификата? Загружается ли главная страница? Работает ли API? Нет ли новой ошибки в логах?

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

А потом спросите: почему это произошло

Есть два уровня ремонта. Первый — вернуть сайт в работу. Второй — сделать так, чтобы проблема не повторилась.

Если приложение пришлось запускать вручную, почему оно не стартовало после перезагрузки? Если сертификат обновляли руками, почему не сработало автоматическое продление? Если диск очистили — почему никто не заметил, что место заканчивается?

Мониторинг — это диагностика заранее

Идеальный вариант — узнать о проблеме раньше пользователя. Для этого наблюдают доступность сайта, HTTP-коды, срок сертификата, место на диске, состояние приложения и рост ошибок.

Тогда вместо «сайт уже два часа не работает» можно получить «приложение перестало отвечать 40 секунд назад».

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

Не знать наизусть все команды. Не помнить каждый параметр Nginx. Главная привычка проще: разделять систему на слои.

Не «интернет сломался», а «DNS правильный → 443 отвечает → TLS работает → Nginx возвращает 502 → приложение на 3000 не запущено».

Последняя фраза уже не выглядит страшной. Это обычная задача.

Весь сайт теперь перестаёт быть магией

Домен даёт человеку понятное имя. DNS превращает имя в IP. Сеть приводит запрос к серверу. Порт определяет точку входа. TLS создаёт защищённое соединение. Сертификат помогает проверить домен. Nginx выбирает нужный сайт и маршрут. Файл или приложение формирует ответ. Браузер показывает результат.