Сайт не работает после сбоя Beget: вопросы и ответы

Чаще всего причина в том, что сервер, на котором размещён сайт, недоступен. Это ещё не значит, что сайт потерян: если файлы и база данных сохранились, после восстановления сервера сайт снова заработает. Если данные повреждены или отсутствуют, понадобится восстановление из резервной копии или сборка сайта заново из архивных материалов. Проверить, что с вашим сервером: проверка сервера по IP.

Откройте сайт с телефона через мобильный интернет (без Wi-Fi и VPN) и попросите знакомых открыть его у себя. Если не открывается ни у кого — проблема на стороне сайта. Если у других открывается, а у вас нет — дело может быть в вашей сети, браузере или DNS-кэше: попробуйте другой браузер, режим инкогнито или перезагрузите роутер.

Точный срок может назвать только хостинг. Ориентиром (но не прогнозом) может быть состояние соседних серверов в той же сети — это видно здесь: проверка сервера по IP. Чтобы не проверять вручную, добавьте сайт в бот @rebornlab_bot — он напишет, когда сайт откроется.

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

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

Не обязательно. Чаще это проблема с сертификатом https: он истёк, не соответствует домену или установлен не полностью. Пока предупреждение не устранено, не вводите на сайте пароли и платёжные данные. Проверьте сертификат и обратитесь к хостингу или администратору сайта — его можно перевыпустить бесплатно (Let’s Encrypt).

Обычно это значит, что запрос дошёл до сервера, но нужный сайт к этому адресу не привязан. Причины: неверные DNS-записи, настройки домена или перенос аккаунта на другой сервер. Проверьте DNS-записи и почту — хостинг мог прислать письмо о переносе с новым IP-адресом.

Сервер работает с перебоями: его настраивают, перезапускают или он перегружен. Срок предсказать нельзя. Если перебои продолжаются, напишите в поддержку хостинга и укажите время, когда сайт не открывался. Бот отмечает такие сайты как «работает с перебоями» и не засыпает уведомлениями.

На Windows откройте «Командную строку», на Mac — «Терминал». Введите nslookup и адрес своего сайта без https, например: nslookup мой-сайт.ru, и нажмите Enter. Нужный IP-адрес указан в ответе в строке Address (Адрес), в последнем блоке. Проще: введите адрес сайта на странице проверка сервера по IP, команду набирать не придётся.

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

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

Введите адрес сайта или IP сервера на странице проверка сервера по IP — покажем, отвечает ли сервер, что с соседними серверами в той же сети и что делать дальше. Если сервер включён, но сайт не открывается, — его ещё подключают или аккаунт перенесли на другой сервер.

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

Шаг 1 — введите адрес сайта на странице проверка сервера по IP: она покажет IP-адрес, на который сейчас указывает домен (иногда это адрес защитного сервиса или CDN, а не самого хостинга). Шаг 2 — по IP видно сеть и сервер: включён ли он и что с соседями. Имя сервера (например, flanker6 или lancelot) пишут в письмах хостинга. Шаг 3 — пришлите IP в бот @rebornlab_bot: он напишет, когда сервер включится.

На странице статуса восстановления — живые цифры нашего мониторинга: сколько серверов отвечает в каждой сети и сколько сайтов из выборки открывается. Данные обновляются каждые 15 минут.

Актуальная цифра по нашим замерам — на странице статуса восстановления: там же графики по часам. Официальные данные публикует сам хостинг на своём сайте и в Telegram-канале.

Адрес панели — cp.beget.com, вход по логину и паролю от аккаунта. Если панель не открывается или выдаёт ошибку, её ещё восстанавливают — это не проблема вашего аккаунта. Не меняйте пароль наугад и не вводите его на сторонних сайтах: проверяйте, что адрес в строке браузера — именно cp.beget.com.

Во время восстановления хостинг может давать отдельные сервисы. Например, Бегет сообщал об отдельном сервисе управления доменами — domains.beget.ru. Проверяйте официальные объявления хостинга и не вводите данные аккаунта на сторонних сайтах, даже если они предлагают «восстановить доступ».

Основные способы — тикет в панели управления (cp.beget.com) и контакты на официальном сайте beget.com; новости о работах хостинг публикует в официальном Telegram-канале. В обращении сразу укажите адрес сайта, логин аккаунта и что именно не работает — так ответят быстрее. Во время массового сбоя ответы идут дольше обычного.

Официальные источники — сайт beget.com, база знаний beget.com/ru/kb и официальный Telegram-канал хостинга. Наш мониторинг на странице статуса — это независимые замеры: мы сами проверяем серверы и выборку сайтов. Они не являются официальной статистикой хостинга и могут от неё отличаться.

Запись DNS — строка, которая говорит, куда вести посетителей: например, A-запись указывает адрес сервера сайта, MX — адрес почтового сервера. Подзона (поддомен) — адрес вида shop.ваш-сайт.ru; у неё могут быть свои записи. Менять их нужно там, где ведётся DNS вашего домена.

Ping проверяет, отвечает ли сервер в сети, но не показывает, открывается ли сайт: сервер может отвечать, а сайт — нет. И наоборот, многие серверы не отвечают на ping вовсе, хотя сайт работает. Надёжнее открыть сайт в браузере с разных устройств или добавить его в бот — он проверяет открытие страницы (доступность сайта, а не работу всех его функций).

Входящая почта: сервер imap.beget.com, порт 993, шифрование SSL. Исходящая: сервер smtp.beget.com, порт 465, шифрование SSL. Логин — полный адрес ящика, пароль — от ящика (не от панели). Если письма не идут, возможно, сервер именно вашего ящика ещё не восстановлен.

Откройте webmail.beget.ru и введите полный адрес ящика вместе с доменом и пароль именно от ящика. Пароль от панели здесь не подойдёт. Если вход всё равно не работает, попробуйте подключить ящик в почтовой программе по IMAP. Если не работает и так, проблема, скорее всего, на стороне сервера почты: уточните в поддержке.

Почта на вашем домене (например, info@ваш-сайт.ru) работает через почтовый сервер, указанный в записях MX домена. Если этот сервер не работает — письма не доходят или приходят с задержкой. Как проверить, где ваша почта: пришлите адрес сайта в бот — он покажет почтовый сервер. Если почта на Яндексе или Mail.ru, сбой хостинга сайта её не касается.

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

Почта работает отдельно от панели. Два способа: 1) веб-почта Бегет — webmail.beget.ru, вход по адресу ящика и паролю от ящика; 2) почтовая программа или телефон: входящая почта — сервер imap.beget.com, порт 993 (SSL), исходящая — smtp.beget.com, порт 465 (SSL), логин — полный адрес ящика. Если почта не на Бегет, адреса серверов — у вашего почтового сервиса.

Да. На примере Яндекс 360 для бизнеса: 1) добавьте домен и подтвердите право владения; 2) создайте ящики с теми же адресами; 3) настройте записи MX, SPF и DKIM по инструкциям Яндекса — SPF у домена должна быть одна (если запись уже есть, её дополняют, а не создают вторую); 4) только после проверки переключайте почту. Смена MX не переносит старые письма — их переносят отдельно, например сборщиком писем. Похоже устроено и в VK WorkMail.

Сайт и почта работают через разные DNS-записи и часто через разные серверы: сайт — по записи A, почта — по записям MX. Восстановление одного сервиса не означает восстановления другого. Проверьте, куда указывают MX-записи домена, и состояние почтового сервера; если почта на хостинге — уточните в поддержке.

Регистратор — компания, у которой вы купили домен (например, RU-CENTER, REG.RU, Бегет). Для доменов .ru, .рф и .su узнать его можно на whois.tcinet.ru — в строке registrar будет название; для других зон — через whois-сервис этой зоны. Наша проверка «можно ли восстановить» тоже показывает регистратора.

Домен — это адрес сайта (как номер телефона). Хостинг — это сервер, где лежат файлы сайта (как сама квартира). Если сайт нужно перенести на другой сервер, адрес не меняется — в настройках домена просто указывают новый сервер.

DNS — это «телефонная книга» интернета: по адресу сайта она сообщает, на каком сервере он лежит. NS — это серверы, которые ведут эту книгу для вашего домена. Чтобы перенести сайт, обычно меняют запись A (адрес сервера) там, где ведётся DNS.

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

Сбой хостинга сам по себе домен не отбирает: право администрировать домен сохраняется в пределах оплаченного срока и по правилам доменной зоны. Проверьте дату окончания: на whois.tcinet.ru — строка paid-till. Если срок истекает скоро, а панель регистратора недоступна, следите за объявлениями регистратора.

После изменения DNS-записей обновление идёт не мгновенно: скорость зависит от TTL записи и кеширования у DNS-резолверов провайдеров. Смена A-записи обычно доходит за часы, а смена NS-серверов — дольше, до 1–3 суток. Пока кеш не обновится, часть людей попадает на старый адрес. Помогает поставить новый адрес и у старого DNS, если он ещё работает. Менять DNS на своём устройстве (например, на 77.88.8.8) имеет смысл, только если проблема в вашем резолвере.

Полноценная резервная копия обычно включает файлы сайта и базу данных (часто файл .sql). Если копия актуальна и не повреждена, сайт можно перенести на другой совместимый хостинг. Время и полнота восстановления зависят от размера проекта, состояния копии, технологий сайта и настроек сервера. Надёжнее, когда свежая копия хранится не только у хостинга, но и у вас.

Спросите разработчика — у него часто есть копия. Проверьте свой компьютер и облако (Яндекс Диск, Google Диск): архивы с названием сайта и расширением .zip или .tar.gz, файлы базы .sql. Когда хостинг откроет доступ к копиям в панели — скачайте их сразу, даже если сайт уже работает.

Проверьте веб-архив (archive.org), старые материалы на своём компьютере, фото и документы, которые передавали разработчику. Иногда изображения находятся в сохранённых копиях страниц или исходных файлах. Если оригиналов нет, используйте только изображения, на которые есть права. Что сохранилось в архиве именно у вас, покажет проверка «можно ли восстановить сайт».

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

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

Да, если есть копия или сайт хорошо сохранился в веб-архиве. Порядок: 1) сайт разворачивают на новом хостинге и проверяют на временном адресе; 2) в DNS домена меняют A-запись на новый сервер; 3) выпускают сертификат https и проверяют формы и почту. Посетители и поисковики переход не замечают: адрес сайта остаётся прежним.

Перенос по готовой копии — обычно несколько часов работы. Восстановление из веб-архива — от одного дня для небольшого сайта до двух-трёх для большого каталога. Цена зависит от размера сайта; бесплатно проверить, что сохранилось, можно здесь: проверка «можно ли восстановить сайт».

Сам по себе переезд на другой хостинг не означает потерю позиций. Чтобы минимизировать риски, сохраните прежний домен, адреса страниц, заголовки, тексты и структуру. После переезда проверьте доступность страниц, сертификат https, robots.txt и sitemap.xml. Если сайт долго был недоступен, роботам понадобится время, чтобы заново обойти страницы. Гарантировать прежние позиции нельзя, но правильный перенос помогает избежать проблем с индексацией.

Проверьте по порядку: 1) DNS уже указывает на новый сервер; 2) сертификат выпущен именно для вашего домена (и для www, если он используется); 3) цепочка сертификата установлена полностью; 4) настроено перенаправление с http на https. Бесплатный сертификат Let’s Encrypt выпускается за минуты, когда DNS уже обновился.

Если адреса страниц те же — немного. Проверьте: 1) Метрика считает визиты (отчёт «Посещаемость»); 2) в Вебмастере «Инструменты → Проверка ответа сервера» показывает 200 для главных страниц; 3) robots.txt не закрывает сайт, а на страницах нет случайного noindex; 4) все важные страницы есть в sitemap.xml. Если сайт долго не работал, отправьте главные страницы на переобход.

Веб-архив (archive.org) — бесплатная библиотека, которая годами сохраняет копии страниц сайтов. Посмотреть копии своего сайта можно на web.archive.org: введите адрес — откроется календарь снимков. Если сайт там есть, из него можно вернуть тексты, заголовки, структуру и часть картинок.

Можно: страницы, тексты, заголовки, описания для поиска, адреса страниц, часть фото. Нельзя: базу заказов и заявок, личные кабинеты, админку. Сайт возвращается как «витрина» — все страницы на месте, формы заявок делаются заново.

Универсального числа нет. Важнее не количество снимков, а то, насколько полно сохранились нужные разделы, тексты, изображения и файлы: для одного сайта хватит нескольких десятков страниц, а для другого даже сотни сохранённых адресов не дадут полноценного восстановления. Веб-архив не гарантирует сохранность сайта целиком. Начните с проверки: проверка «можно ли восстановить сайт».

Восстановленный из архива сайт — это готовые страницы без админки: правки вносит разработчик. Если позже появится копия от хостинга, можно вернуть родную админку (например, WordPress) — витрина просто заменяется.

Только если есть база данных или другая полноценная копия магазина. Веб-архив хранит страницы так, как их видели посетители, — в нём нет истории заказов, аккаунтов покупателей и внутренних данных. Из архива можно вернуть витрину: каталог, описания и цены на дату снимка.

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

Веб-архив ограничивает частые запросы и иногда сам бывает недоступен. Поэтому наша проверка ставит сайты в очередь и показывает ваше место. Не хотите ждать — нажмите «получить результат в боте», ответ придёт в Telegram.

В первую очередь — те, которые могли быть скомпрометированы: от панели хостинга, админки сайта, почты на домене, FTP/SSH. Пароль базы данных меняйте вместе с настройками сайта (в WordPress — файл wp-config.php), иначе сайт перестанет подключаться к базе. Ключи сторонних сервисов, прописанные в сайте (оплата, рассылки), тоже стоит перевыпустить.

Для WordPress: 1) сначала сделайте резервную копию; 2) проверьте пользователей с правами администратора; 3) плагины и темы — нет ли неизвестных, и обновлены ли они и сам WordPress; 4) задачи по расписанию (cron) и подключённые ключи API; 5) недавно изменённые файлы, особенно .php в папке uploads. Свежая дата изменения файла сама по себе не доказывает взлом — это повод для проверки. Если что-то нашли — сравните с чистой копией или позовите разработчика.

Не переходите по подозрительным ссылкам из писем и сообщений «от хостинга», не передавайте пароли и коды подтверждения, проверяйте адрес сайта в браузере (официальный — beget.com и его поддомены) и не скачивайте неизвестные программы «для восстановления». Если сомневаетесь — напишите в поддержку через официальный сайт.

Подключите мониторинг: он сам проверяет сайт по расписанию и пишет, если тот не открывается. Бесплатно — бот @rebornlab_bot: пришлите адрес сайта, он проверяет каждые 10 минут и пишет в Telegram, когда сайт упал и когда снова открылся. Для важных сайтов полезно настроить ещё и уведомления о скором окончании оплаты домена и хостинга.

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