Сайт перестал работать: что проверить и как найти причину

Когда сайт не открывается, самое дорогое действие — начинать хаотично менять настройки. Белый экран, ошибка 500, бесконечная загрузка и сообщение о недоступном домене выглядят похоже для пользователя, но возникают на разных уровнях. Поэтому сначала нужно определить границу сбоя: домен, DNS, TLS, сервер, приложение, база данных или внешний сервис.

Сначала зафиксируйте симптомы

До перезапусков и обновлений сохраните исходную картину. Она часто содержит единственную полезную подсказку.

• точный URL и время появления проблемы;
• текст ошибки и скриншот;
• открывается ли сайт с мобильного интернета;
• работает ли административная панель;
• затронуты все страницы или только отдельный раздел;
• были ли перед сбоем релиз, обновление, перенос или изменение DNS;
• доступен ли сервер по SSH и есть ли свободное место на диске.

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

Шаг 1. Проверьте домен и DNS

Домен может быть зарегистрирован, но перестать вести на нужный сервер. Причины — истекший срок регистрации, смена NS-серверов, ошибочная A- или AAAA-запись, незавершенный перенос зоны или конфликт старых записей.

Проверяем:

1. 1Делегирован ли домен и не истек ли срок регистрации.
2. 2Какие IP-адреса возвращают публичные DNS-резолверы.
3. 3Совпадают ли ответы из разных сетей.
4. 4Не осталась ли старая IPv6-запись, ведущая на другой сервер.
5. 5Не изменялись ли NS-записи в последние часы.

Для первичной проверки можно использовать инженерные инструменты сайта. Но наличие DNS-ответа еще не означает, что веб-приложение работает.

Шаг 2. Отделите SSL от ошибки приложения

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

Коды ответа помогают сузить поиск:

• 502 и 504 — веб-сервер не получил нормальный ответ от приложения;
• 500 — ошибка внутри приложения или его конфигурации;
• 403 — ограничения доступа, права или защитный слой;
• 404 на всех адресах — неверный virtual host, маршрутизация или потерянная сборка;
• постоянные 301/302 — цикл редиректов между HTTPS, доменами или прокси.

Шаг 3. Проверьте ресурсы сервера

На сервере сначала смотрят не конфигурационные файлы, а фактическое состояние:

• свободное место и inode;
• использование памяти и swap;
• загрузку CPU;
• состояние веб-сервера, приложения и базы данных;
• последние системные события;
• время ответа локального endpoint;
• срок жизни процессов после последнего релиза.

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

Подробнее инфраструктурный контур разобран на странице администрирования серверов и VPS/VDS.

Шаг 4. Найдите ошибку приложения

Если сервер отвечает, изучаем журналы вокруг точного времени сбоя. Нас интересует первая ошибка в цепочке, а не десятки последующих сообщений.

Типовые причины:

• несовместимость кода и версии runtime;
• отсутствие переменной окружения;
• неудачная миграция базы данных;
• исчерпание пула соединений;
• поврежденный кэш;
• ошибка после обновления CMS, модуля или зависимости;
• недоступность файлового хранилища;
• неверные права после переноса.

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

Шаг 5. Проверьте критичный бизнес-сценарий

Главная страница может открываться, а сайт фактически оставаться неработоспособным. После восстановления проверяем не только HTTP 200, но и действия пользователя:

• отправку формы и поступление заявки;
• авторизацию;
• поиск и фильтры;
• добавление товара в корзину;
• создание и оплату заказа;
• передачу данных в CRM;
• уведомления менеджеру и клиенту.

Именно поэтому мониторинг доступности должен проверять несколько точек, а не только главную страницу.

Что не стоит делать в первые минуты

• обновлять все компоненты «на всякий случай»;
• удалять кэш и журналы до сохранения исходных данных;
• восстанавливать старую копию поверх текущей базы без проверки;
• менять DNS одновременно у нескольких провайдеров;
• перезапускать сервер много раз, не фиксируя результат;
• скрывать ошибку редиректом на статичную страницу и считать инцидент закрытым.

Когда нужно подключать инженера

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

Главный результат аварийной работы — не просто вернуть страницу. Нужно зафиксировать первопричину, проведенные действия и меру, которая снизит вероятность повторения: мониторинг, резервирование, контроль диска, безопасный релиз или отдельная проверка бизнес-сценария.

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

Почему сайт открывается у администратора, но не у клиентов?

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

Можно ли просто перезапустить сервер?

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

Что делать, если доступов к серверу нет?

Начните с владельца учетной записи хостинга и панели провайдера. Параллельно соберите DNS, регистратора домена, репозиторий и контакты предыдущего подрядчика. Не создавайте новый сервер и не переключайте DNS, пока не понятно, где находятся актуальные файлы и база данных.

Как определить время фактического начала сбоя?

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