У недоступного сайта есть неприятная особенность: снаружи совершенно разные поломки выглядят почти одинаково. Посетитель вводит адрес, ждет несколько секунд и не получает нужную страницу. На этом сходство заканчивается. Домен мог закончиться вчера ночью, DNS может вести на старый сервер, браузер способен отказаться от соединения из-за сертификата, хостинг может ограничить ресурсы, PHP завершиться с ошибкой, а WordPress застрять после обновления плагина. Исправляются эти ситуации совершенно по-разному.
Поэтому фраза «сайт не работает» для диагностики почти бесполезна. Гораздо важнее выяснить, что именно происходит между вводом адреса и моментом отказа. Не находится домен? Не устанавливается защищенное соединение? Сервер отвечает кодом 500? Открывается главная, но не работает административная панель? С мобильного интернета все нормально, а через домашний Wi-Fi сайт недоступен? Каждый такой симптом отсекает часть возможных причин.
Худшее, что можно сделать в первые минуты, это начать менять все подряд. Переключить NS, удалить кэш, переустановить WordPress, изменить версию PHP, перевыпустить SSL и восстановить вчерашний бэкап. Даже если после этого сайт оживет, останется загадкой, что именно помогло и какие новые проблемы появились по дороге.
Сначала выясните, сайт не открывается у всех или только у вас
Это первая развилка, которая экономит больше всего времени. Если сайт недоступен только на одном компьютере, а с телефона через мобильную сеть открывается нормально, сервер, скорее всего, жив. Проблема может находиться в локальном DNS-кэше, браузере, расширении, антивирусе, VPN, маршруте интернет-провайдера или конкретной сети.
Откройте сайт на другом устройстве, затем попробуйте другую сеть. Например, отключите Wi-Fi на смартфоне и зайдите через мобильный интернет. Важно проверять именно тот URL, который не работает. Ситуация, когда example.ru открывается, а www.example.ru нет, отличается от полной недоступности домена. Точно так же главная страница может работать, а /wp-admin возвращать ошибку.
Посмотрите, что именно пишет браузер
Фраза «не открывается» скрывает важнейшую информацию. Сообщение о невозможности найти IP-адрес сервера заставляет смотреть в сторону DNS. Предупреждение о небезопасном соединении указывает на SSL/TLS. Код 403 означает, что сервер понял запрос, но отказывает в доступе. 404 говорит, что запрошенный ресурс не найден. Ошибки 500, 502, 503 и 504 относятся к серверной части.
Запишите сообщение или сделайте скриншот до того, как начнете что-либо менять. Особенно полезно сохранить HTTP-код и точное время появления ошибки. Если сервер возвращает 500, 502, 503 или 504, сначала нужно разбираться с серверной частью, а не менять доменные настройки.
Проверьте, не закончился ли срок регистрации домена
О домене легко забыть именно потому, что большую часть года он ничего от владельца не требует. Сайт работает, почта приходит, адрес печатается на визитках и в рекламе. Затем срок регистрации заканчивается, и привычная схема перестает работать.
Войдите в кабинет регистратора и посмотрите статус домена и дату окончания регистрации. Не ориентируйтесь только на письма с напоминаниями: они могли попасть в спам или уйти на старый адрес. Для рабочего проекта удобно включить автопродление и следить, чтобы способ оплаты оставался действующим.
Домен активен, но сайт не находится: проверяем DNS
Если домен зарегистрирован и активен, следующая точка проверки — DNS. Именно DNS сообщает, куда должен отправляться запрос к доменному имени.
Здесь важно вспомнить, не менялись ли недавно NS, A, AAAA или настройки CDN. После переноса сайта часто остается старый IP. После замены NS иногда забывают перенести саму DNS-зону. Бывает и наоборот: владелец редактирует A-запись в панели хостинга, хотя авторитетные NS домена принадлежат регистратору, поэтому изменение вообще не участвует в разрешении имени.
Если обозначения пока выглядят как набор букв, сначала полезно прочитать материал о DNS-записях домена. Для диагностики недоступности особенно важны NS, A и AAAA.
Почему после смены DNS сайт работает не у всех
После изменения A-записи владелец уже может видеть новую версию сайта, тогда как часть посетителей продолжает попадать на старую. Это нормальное следствие кэширования DNS: разные резолверы хранят предыдущий ответ до истечения TTL.
По этой причине старый сервер после миграции не стоит выключать в ту же минуту, когда изменен IP. Некоторое время запросы еще могут приходить на него. Если перенос только планируется, полезно заранее продумать миграцию сайта на новый хостинг и сначала проверить новую копию.
Не забывайте про AAAA
Одна из неприятных DNS-проблем возникает, когда владелец меняет A-запись на новый IPv4-адрес, но забывает о существующей AAAA-записи для IPv6. В результате по IPv4 домен ведет на новый сервер, а по IPv6 — на старый. Поведение зависит от сети пользователя, поэтому проблема кажется случайной.
Если хостинг не использует IPv6, не нужно сохранять старую AAAA просто потому, что она когда-то была создана. Если IPv6 используется, запись должна указывать на актуальную инфраструктуру.
Сайт открывается по IP, но не по домену
На первый взгляд это почти готовый диагноз DNS, но есть нюанс. Современный веб-сервер может обслуживать десятки сайтов на одном IP и определяет нужный проект по имени хоста. Поэтому открытие самого IP не обязательно должно показывать ваш сайт.
Гораздо важнее проверить, разрешается ли домен в правильный IP и настроен ли этот домен на стороне хостинга. После добавления DNS-записи имя обычно нужно также привязать к конкретному сайту в панели провайдера.
Проверьте, оплачен ли сам хостинг
Причина банальная, но встречается регулярно. Домен оплачен на год вперед, а хостинг продлевается ежемесячно. Карта изменилась, автоматический платеж не прошел, уведомление затерялось, аккаунт приостановлен.
Зайдите в панель провайдера и проверьте статус услуги. Не путайте срок домена и срок хостинга. Это две разные услуги, даже если они куплены у одной компании.
Хостинг работает, но аккаунт превысил лимиты
На виртуальном хостинге клиент получает определенную долю ресурсов. Ограничиваться могут процессорное время, память, количество процессов, дисковые операции, число файлов и другие параметры. Когда сайт достигает лимита, он может резко замедлиться, периодически возвращать 503, 508 или другие ошибки, а затем снова работать нормально.
Сам факт превышения лимита не означает, что нужно немедленно покупать самый дорогой тариф. Сначала выясните источник нагрузки. Если посещаемость выросла в пять раз, проект действительно мог перерасти текущий план. Если нагрузка появилась после установки одного плагина при прежнем количестве посетителей, причина скорее находится внутри сайта.
Проверьте свободное место на диске
Диск занимают не только изображения и файлы CMS. На нем могут храниться резервные копии, почта, кэш, журналы, временные файлы, старые архивы и базы данных. При заполнении диска приложение не может нормально записывать временные данные, обновляться или создавать новые файлы.
Если постоянно приходится освобождать последние мегабайты, стоит оценить, сколько дискового пространства действительно нужно сайту, и оставить запас вместо работы на пределе квоты.
Браузер показывает ошибку сертификата
Если вместо сайта появляется предупреждение о небезопасном соединении, проблема уже заметно сузилась. Сертификат мог истечь, не соответствовать доменному имени, быть установлен с неправильной цепочкой или отсутствовать для конкретного поддомена. После миграции бывает, что DNS уже ведет на новый сервер, а сертификат на нем еще не выпущен.
Отдельно проверяйте варианты с www и без www. Разобраться в принципах работы защищенного соединения поможет статья об SSL-сертификатах и HTTPS.
Сертификат исправен, но возник цикл перенаправлений
Иногда браузер сообщает о слишком большом количестве перенаправлений. Такое бывает после включения HTTPS сразу на нескольких уровнях. Одно правило переводит HTTP на HTTPS в веб-сервере, другое находится в .htaccess, третье добавляет WordPress или плагин, а CDN по-своему определяет протокол соединения с исходным сервером.
Похожий цикл возникает между www и версией без www, когда два правила противоречат друг другу. Нужно проследить цепочку редиректов и оставить однозначное направление.
Сайт отвечает 403 Forbidden
Код 403 означает, что сервер получил запрос, но доступ к ресурсу запрещен. Причиной могут быть права на файлы и каталоги, правила .htaccess, настройки веб-сервера, защитный модуль, блокировка IP или ограничения по стране.
Если 403 появился сразу после изменения прав доступа или установки защитного плагина, начните с последнего изменения. Не стоит выставлять всем файлам максимально разрешающие права в надежде «открыть сайт». Это плохой способ диагностики и потенциальная проблема безопасности.
Сайт отвечает 404 Not Found
404 означает, что сервер доступен, но не находит запрошенный ресурс. Если главная работает, а внутренние URL внезапно стали отдавать 404, проблема обычно не в домене и не в оплате хостинга.
В WordPress это часто связано с правилами постоянных ссылок и .htaccess. Если 404 возвращается для всего сайта, включая главную, проверьте, правильно ли домен привязан к каталогу на сервере и действительно ли файлы проекта находятся в нужной директории.
Белый экран вместо сайта
Белая страница без понятного сообщения характерна для PHP-приложений. Сервер мог столкнуться с фатальной ошибкой, но вывод подробностей посетителю отключен. Вместо включения отображения всех PHP-ошибок публично откройте error log.
На WordPress причиной часто оказывается конфликт плагина, тема, недостаток памяти или несовместимость с версией PHP. Самое ценное действие здесь — воспроизвести проблему и сразу посмотреть свежие строки журнала.
После обновления WordPress сайт перестал открываться
Если до обновления все работало, а сразу после него появилась ошибка, не нужно начинать диагностику с DNS. Определите, что именно обновлялось: ядро WordPress, тема или конкретный плагин. Если административная панель недоступна, расширение можно временно отключить через файловый менеджер или SFTP.
Восстанавливать весь сайт из старого архива следует осторожно. На интернет-магазине старая база может означать потерю новых заказов. Иногда достаточно вернуть один компонент, не затрагивая данные пользователей.
После смены PHP сайт перестал работать
Новая версия PHP может выявить несовместимость старого кода. Если проблема появилась сразу после переключения PHP, временный возврат прежней версии помогает подтвердить гипотезу. Но оставаться на устаревшей версии навсегда не стоит. Нужно найти компонент, который мешает обновлению.
В журнале PHP обычно можно увидеть фатальную ошибку и файл, где она возникла. Это надежнее, чем последовательно отключать все расширения наугад.
Сайт не может подключиться к базе данных
У WordPress есть узнаваемое сообщение об ошибке установления соединения с базой данных. Причины бывают простыми: изменился пароль пользователя базы, неверно указано имя сервера, база остановлена или повреждены параметры конфигурации.
Если проблема возникла после переноса, сравните реквизиты подключения на новом сервере с настройками приложения. На разных хостингах имя сервера базы не обязательно одинаковое. Не создавайте новую пустую базу вместо существующей, пока не убедитесь, что старая действительно потеряна.
Сайт не работает после переноса
Миграция объединяет сразу несколько потенциальных точек отказа. Нужно перенести файлы, базу, конфигурацию, проверить версию PHP и расширения, привязать домен, настроить DNS и выпустить сертификат.
Поэтому проблему нужно разложить на этапы. Работает ли новая копия до смены DNS? Разрешается ли домен в новый IP? Привязан ли домен к нужному каталогу? Импортирована ли база? Верны ли реквизиты подключения? Выпущен ли SSL?
Старый аккаунт не стоит удалять сразу после успешного открытия главной страницы. Сначала проверьте формы, почту, загрузку файлов, административную панель и фоновые задачи.
Сайт не открывается после подключения CDN
После подключения CDN или обратного прокси между браузером и хостингом появляется дополнительный слой. CDN может не достучаться до origin-сервера, исходный сервер может блокировать адреса прокси, сертификаты могут быть неправильно настроены на одном из участков, а DNS вести не туда.
Если проблема появилась непосредственно после подключения CDN, проверьте настройки origin и режим SSL. Полезно заранее понимать, как CDN взаимодействует с хостингом.
Сайт открывается очень долго, а потом показывает ошибку
Долгое ожидание перед отказом отличается от мгновенного «домен не найден». Запрос, вероятно, дошел до сервера и начал обрабатываться, но операция не завершилась вовремя. Причиной может быть тяжелый запрос к базе, зависшее внешнее API, нехватка PHP-процессов, перегрузка CPU или медленная операция внутри приложения.
Если сайт сначала просто стал медленным, а затем появились ошибки, возможно, это две стадии одной проблемы. В таком случае пригодится отдельная диагностика причин медленной загрузки сайта.
Проверьте фоновые задачи и Cron
Иногда сайт падает строго по расписанию. Каждый день ночью появляются 503, утром все нормально. Такая регулярность почти всегда заслуживает внимания. В это время может запускаться резервное копирование, импорт каталога, синхронизация, генерация фида или другая тяжелая задача.
Проверьте Cron и расписание плагинов. Сопоставьте время запуска с графиками ресурсов и журналами. Иногда достаточно изменить время или разбить обработку на части.
Проверьте, не атакуют ли сайт боты
Резкий рост нагрузки не всегда означает приток реальных покупателей. Сайт могут интенсивно обходить поисковые и коммерческие боты, сканеры уязвимостей и подборщики паролей. Особенно тяжелыми бывают запросы к динамическому поиску, фильтрам и страницам, которые плохо кэшируются.
Посмотрите журналы доступа и статистику запросов. Но блокировать все неизвестные боты одной грубой маской опасно: среди автоматического трафика находятся поисковые роботы и полезные сервисы.
Сайт могли заблокировать из-за вредоносного кода
Хостинг-провайдер может ограничить работу зараженного сайта, если тот рассылает спам, участвует в атаках или создает угрозу другим клиентам сервера. Если провайдер прислал уведомление о вредоносных файлах, простого снятия блокировки недостаточно.
Нужно найти источник заражения, удалить вредоносный код, обновить уязвимые компоненты и сменить скомпрометированные пароли. Восстановление чистой копии помогает только тогда, когда одновременно закрыта уязвимость.
Что проверить в панели хостинга за пять минут
Даже без командной строки панель виртуального хостинга обычно дает достаточно данных для первичной диагностики. Посмотрите статус услуги, свободное место, использование ресурсов, версию PHP, журналы ошибок, состояние SSL и привязку домена к сайту.
Если панель показывает графики, сопоставляйте их со временем сбоя. Фраза «CPU сейчас 5%» ничего не говорит о том, что происходило два часа назад, когда сайт был недоступен.
Почему резервная копия должна храниться не только на хостинге
Автоматические бэкапы провайдера удобны, но полагаться только на них рискованно. Если проблема затрагивает весь аккаунт, доступ к резервным копиям тоже может оказаться ограничен. Хорошая схема предполагает хотя бы одну актуальную копию вне основной площадки.
Важно периодически проверять, что архив действительно восстанавливается. Если резервное копирование пока устроено по принципу «кажется, хостер что-то сохраняет», стоит заранее настроить понятный процесс бэкапа.
Когда проблема действительно на стороне хостинга
Иногда владелец сайта ни при чем. На сервере может произойти аппаратный сбой, проблема сети, отказ хранилища или ошибка после обновления инфраструктуры. Косвенным признаком становится одновременная недоступность нескольких независимых сайтов одного аккаунта без каких-либо ваших изменений.
Проверьте официальные уведомления провайдера и обратитесь в поддержку. Отсутствие публичного объявления не доказывает, что аварии нет: локальная проблема может затрагивать один сервер или часть клиентов.
Что написать в поддержку, чтобы проблему нашли быстрее
Технической поддержке нужны воспроизводимые факты. Укажите домен, конкретный URL, время сбоя, HTTP-код или сообщение браузера и сеть, из которой выполнялась проверка.
Если проблема периодическая, напишите несколько временных интервалов. Если она возникает после определенного действия, опишите его. Если в журнале есть связанная с этим временем ошибка, приложите несколько соответствующих строк.
Такой запрос дает специалисту точку входа. Он может проверить серверный журнал именно в нужную минуту, а не пытаться поймать ошибку тогда, когда сайт уже снова работает.
Когда пора думать о смене тарифа или VPS
Переезд имеет смысл после того, как понятно, чего именно не хватает текущей площадке. Если проект стабильно упирается в ограничения виртуального хостинга при нормальной оптимизации и реальной посещаемости, более мощная среда действительно может быть следующим шагом.
Но VPS не является волшебной таблеткой. Вместе с ресурсами появляется ответственность за настройку, обновления, безопасность, мониторинг и резервное копирование. Плохо написанный запрос к базе будет плохо работать и на более дорогом сервере, просто некоторое время это будет менее заметно.
Как диагностировать недоступный сайт по порядку
Удобнее двигаться сверху вниз по цепочке запроса. Сначала проверяется сам домен: активен ли он и делегирован ли. Затем DNS: правильные ли NS, A и AAAA. После этого HTTPS: устанавливается ли защищенное соединение и соответствует ли сертификат домену.
Следующий уровень — веб-сервер. Какой HTTP-код он возвращает? Дальше идет приложение: PHP, WordPress, плагины, тема, база данных и внешние сервисы. Параллельно проверяются ресурсы аккаунта, свободный диск и фоновые задачи.
Если причина неизвестна, движение по цепочке не дает перескакивать между несвязанными гипотезами.
Что не нужно делать, если сайт внезапно перестал открываться
Не меняйте NS только потому, что «это связано с доменом». Не переустанавливайте CMS поверх рабочего проекта без резервной копии. Не удаляйте базу и не создавайте новую. Не отключайте SSL, если браузер сообщает о серверной ошибке, не связанной с сертификатом.
Не восстанавливайте недельный бэкап интернет-магазина, пока не понимаете, что произойдет с заказами за последние семь дней. Не выключайте старый сервер сразу после изменения DNS во время миграции.
И главное, не делайте десять изменений за один заход. У каждой правки должна быть гипотеза. После изменения нужно проверить результат.
Сайт снова заработал: расследование еще не всегда закончено
Если причина была очевидной, например закончилась оплата хостинга, после восстановления услуги вопрос можно закрыть. Но периодические 503, случайные таймауты и внезапные перезапуски приложения лучше не оставлять без объяснения.
То, что сайт снова открывается, означает только отсутствие проблемы в данный момент. Ночной Cron запустится снова. Диск продолжит заполняться. Бот вернется. После восстановления запишите причину и действия, которые помогли.
Недоступный сайт лучше диагностировать, а не чинить на удачу
Когда сайт не открывается, проблема может находиться на любом из нескольких уровней: домен, DNS, сертификат, сервер, ресурсы хостинга, PHP, база данных или сама CMS. Именно поэтому универсальная кнопка «починить сайт» не существует.
Зато существует понятная последовательность вопросов. Домен активен? DNS возвращает правильный адрес? HTTPS устанавливается? Какой HTTP-код приходит? Ошибка затрагивает весь сайт или одну страницу? Что менялось непосредственно перед сбоем? Что записано в журналах? Что происходило с ресурсами в этот момент?
Ответы обычно сокращают десятки возможных причин до двух или трех. Сохраните скриншот ошибки, время и проблемный URL. Проверяйте сайт из другой сети. Не забывайте о сроках домена и хостинга. Перед серьезным вмешательством делайте резервную копию и используйте журналы вместо догадок.
Тогда даже неприятная ситуация «сайт лежит» перестает быть хаосом. Она превращается в последовательность проверок, где каждый следующий шаг зависит от результата предыдущего.
