Beget упал и программисты ответили: что срочно делать с сайтами на Бегет

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

Наибольшая доля опубликованных жалоб пришлась на Санкт-Петербург – 12% сообщений, а Москва обеспечила еще 10%. Ленинградская область заняла 8%, Кемеровская область – 5%, Московская область – 4%. Эти показатели отражают географию обращений, но не долю отключенных сайтов и не масштаб повреждения серверной инфраструктуры.

Проблемы затронули разные устройства: 40,2% зарегистрированных обращений приходилось на Windows, еще 25,2% – на macOS. Пользователи Android составили 17,8%, владельцы iOS – 12,1%, Linux – 3,7%. Такая статистика указывает на разнообразие пострадавших пользователей, однако сама по себе не раскрывает техническую причину инцидента.

Почему Beget не работает: причины сбоя и официальная позиция провайдера

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

Руководитель отдела программистов SEO-агентства РОСТСАЙТ Алексей Лялин объясняет, как за 10–15 минут самому определить, где именно оборвалась связь:

«Начните с DNS. Выполните в терминале dig example.ru A или nslookup example.ru и сравните ответ с тем IP, который указан в панели хостинга. Если адрес не совпадает или запрос вообще не разрешается – проблема в DNS, а не на сервере, и дальнейшая диагностика бессмысленна, пока это не исправлено.

Затем проверьте сам сервер, минуя DNS: curl -I https://example.ru --resolve example.ru:443:IP-адрес. Если сервер отвечает кодом 200 или 301 – он работает. Если соединение зависает на этапе TLS-handshake или обрывается по таймауту, запустите traceroute или mtr example.ru и посмотрите, на каком узле пропадают пакеты. Обрыв на последнем хопе – это хостинг; обрыв на транзитном узле оператора – это магистраль или фильтрация.

Делайте это из двух-трёх независимых сетей: домашний провайдер, мобильный интернет, любой VPS за пределами страны. Разные результаты из разных сетей – почти всегда признак сетевых ограничений, а не поломки.

Если сервер отвечает, но кодом 502 или 504 – nginx жив, а PHP-FPM или приложение не отвечает. Смотрите error.log веб-сервера и логи PHP: типичные записи – upstream timed out, connect() failed, MySQL server has gone away. Код 403 при исправном сайте чаще всего означает срабатывание защиты от DDoS или блокировку по IP.

Почту проверяйте отдельно: dig example.ru MX покажет, куда уходят письма, а telnet mail.example.ru 25 или openssl s_client -connect mail.example.ru:993 – отвечает ли почтовый сервер. Если MX-запись в порядке и порт открыт, письма накапливаются в очереди отправителя и дойдут после восстановления; стандартный срок повторных попыток у большинства серверов – до 4–5 суток.

Все результаты – коды ответов, вывод traceroute, время проверки и сеть, из которой вы проверяли, – сохраните. С такими данными поддержка хостинга разбирается в разы быстрее, чем с сообщением „сайт не открывается“».

Предпринимателю важно различать неисправность хостинга и нарушение маршрутизации между посетителем и сервером. Во втором случае вход в панель Бегет может оставаться доступным через одного оператора, но перестать работать через другого. Аналогичные трудности иногда затрагивают почту Бегет и административные сервисы, поэтому их необходимо проверять отдельно.

Бегет (Beget) не работает: что произошло с серверами и кто виноват в отключении сайтов

Серверы Beget 2 ноября не ломались – по заявлению провайдера, трафик до них не доходил. Предварительная причина, названная компанией, – изменения в работе ТСПУ, технических средств противодействия угрозам, которые стоят на сетях всех крупных российских операторов связи. Это оборудование анализирует проходящие пакеты и может их замедлять, обрывать или отбрасывать по адресу, порту, протоколу или содержимому. Если правила фильтрации затронули диапазоны адресов, в которых размещён Бегет хостинг, сайты становятся недоступны у части операторов при полностью исправных серверах.

Руоводитель РОСТСАЙТ и главный инженер веб-компании Александр Кривов объясняет, чем такой сбой отличается от поломки сервера с точки зрения трафика:

«Когда падает сервер, вы видите одно из двух: либо соединение по TCP не устанавливается и через 30–60 секунд получаете таймаут, либо устанавливается и сервер отвечает ошибкой 5xx. Это одинаково из любой сети и в любое время.

Когда работает фильтрация, картина другая. Соединение может устанавливаться, TLS-рукопожатие начинаться – и обрываться на середине пакетом RST, который прислал не сервер, а промежуточный узел. В tcpdump это видно по TTL такого пакета: он не совпадает с TTL нормальных ответов сервера. Или соединение проходит, но скорость падает до десятков килобит – это шейпинг, а не блокировка. Или сайт открывается с третьей попытки, потому что часть пакетов просто отбрасывается.

Второй признак – зависимость от маршрута. У одного оператора сайт работает, у другого нет, через VPN работает у всех. Для сервера это невозможно: он не знает и не выбирает, через кого к нему пришёл запрос.

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

2 ноября наблюдались все три признака: разная доступность по операторам, восстановление „волнами“ по регионам, работающие серверы по данным мониторинга. Поэтому ответ на вопрос „кто виноват“ технически простой: не сервер и не ваш сайт. А вот кто именно и что изменил в фильтрации – это может сказать только официальный разбор, которого на момент публикации нет».

Для владельца сайта из этого следует практический вывод: вопрос «Бегет (Beget) не работает или нет» в такой ситуации не имеет единого ответа. Один и тот же сайт в одну и ту же минуту открывался у клиента в Казани и не открывался у клиента в Петербурге, и оба были правы. Поэтому ни одно сообщение в чате, ни одна проверка с одного устройства не говорит о состоянии сервера. Говорит о нём только проверка из нескольких независимых сетей по методике из предыдущего раздела.

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

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

Панель управления – это такой же веб-сайт, как и ваш. Она размещена в сети того же провайдера. Трафик до неё проходит через тех же операторов и те же фильтры. Поэтому при сетевом сбое Бегет вход отказывает одновременно с сайтами клиентов. Это не признак потери данных. Файлы и базы лежат на дисках серверов, до которых просто не доходят запросы.

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

Руководитель отдела программистов Алексей Лялин рассказал о том, как работать с сайтом, когда панель недоступна:

«Первое, что проверяю, – SSH. Если порт 22 отвечает, панель мне не нужна. Через консоль я вижу состояние сервера, логи, базу и могу всё, что умеет панель, кроме оплаты услуг. 2 ноября у части клиентов SSH работал, когда веб не открывался, – фильтрация шла по портам 80 и 443.

Если и SSH недоступен – проверяю из другой сети. Мобильный интернет, VPN, VPS за рубежом. Если хоть откуда-то доступ есть – всё цело, работаю оттуда.

Если доступа нет ниоткуда – ничего не делаю. Не меняю DNS, не восстанавливаю из бэкапа на другой площадке, не пишу поддержке каждые десять минут. Жду. Любое действие без доступа к данным – это действие вслепую.

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

Бегет почта: что происходит с письмами во время сбоя

Почта устроена так, что короткий простой письма не теряет. Отправляющий сервер не доставил письмо – он ставит его в очередь. Повторные попытки идут по нарастающей: через минуту, через пять, через полчаса, через час. Большинство серверов повторяют до 4–5 суток. Только после этого отправитель получает отказ. Значит, письма за часы простоя придут с задержкой, но придут.

Что действительно ломается во время сбоя:

• Исходящие уведомления с сайта. Форма вызвала mail() или SMTP, получила ошибку, письмо не ушло. Повторной попытки у большинства CMS нет. Заявка в базе есть, уведомления о ней – нет.

• Почтовые клиенты на компьютерах. Outlook и Thunderbird при недоступном IMAP показывают ошибку и могут отключить учётную запись. После восстановления её нужно включить вручную.

• Веб-интерфейс почты. Недоступен вместе с панелью. Не означает остановку доставки.

Что проверить после восстановления:

• dig example.ru MX – записи указывают на почтовые серверы хостера.

• dig example.ru TXT – SPF-запись на месте и не повреждена.

• Отправить письмо с внешнего ящика и обратно, засечь время доставки.

• Отправить тестовую заявку с сайта и дождаться уведомления.

• Проверить папку спама у получателей: после простоя репутация IP может временно просесть.

Если почта критична, настраивается резервный MX. Это второй почтовый сервер у другого провайдера с меньшим приоритетом в DNS. При недоступности основного он принимает письма и передаёт их позже. Настраивается один раз, стоит несколько сотен рублей в месяц.

Когда включат Бегет: можно ли ускорить восстановление сайта и продаж

Ускорить восстановление работы хостинга владелец сайта не может. Но он может ускорить момент, когда сайт снова откроется именно у его клиентов, и сократить потери заказов за время простоя. Это разные задачи. Первая решается провайдером и операторами связи. Вторая – вами.

Почему Beget не назвал время восстановления доступа к сайтам

При сетевом сбое доступ к сайтам возвращается не одним переключением, а волнами. Провайдер меняет маршрутизацию или добивается изменения правил фильтрации. Эти изменения доходят до разных операторов связи в разное время. У абонентов одного оператора сайт открывается через час, у другого – к вечеру. Единого момента восстановления доступа для всех пользователей 2 ноября не существовало. Поэтому провайдер его и не объявлял.

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

«Задержка складывается из четырёх слоёв.

Первый слой – работа провайдера. Диагностика, поиск обходного маршрута, согласование с операторами связи. 2 ноября на это ушло несколько часов.

Второй слой – обновление маршрутов BGP. Если хостер меняет анонсы своих IP-сетей, новые маршруты расходятся по интернету от нескольких минут до часа. Отдельные операторы держат устаревшие маршруты дольше.

Третий слой – DNS-кэш операторов. Если хостер переключил сайты на другие IP-адреса, резолверы операторов отдают старый адрес до истечения TTL записи. TTL задаёт владелец домена: это может быть 5 минут, а может быть 24 часа.

Четвёртый слой – кэш на стороне посетителя. Браузер, операционная система, домашний роутер. Сайт уже доступен, а посетитель видит ошибку, потому что его устройство помнит неудачную попытку соединения.

На первые два слоя владелец сайта повлиять не может. Третий сокращается заранее – низким TTL. Четвёртый – прямо сейчас, сбросом кэша».

Как сбросить кэш, если провайдер сообщил о восстановлении, а сайт не открывается

Порядок – от быстрого действия к долгому:

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

• Сбросить DNS-кэш операционной системы: Windows – ipconfig /flushdns; macOS – sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; Linux – resolvectl flush-caches.

• Перезагрузить роутер: у него собственный DNS-кэш.

• Сменить DNS-сервер на устройстве с операторского на публичный: 77.88.8.8 (Яндекс), 8.8.8.8 (Google), 1.1.1.1 (Cloudflare). Разные резолверы обновляют записи в разное время.

• Проверить сайт с мобильного интернета. Если там он открывается – у вашего домашнего оператора ещё не обновились маршруты. Это вопрос ближайшего часа.

Что ускоряет возврат заказов после восстановления доступа

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

Из access.log контакты посетителей не извлечь: там только IP-адрес, время и адрес страницы. Но если на сайте стоит Яндекс Метрика с Вебвизором или CRM с идентификацией посетителей, часть несостоявшихся заказов восстанавливается по сессиям. Этим покупателям стоит написать первыми.

Что делать владельцу сайта во время массового сбоя хостинга Beget

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

Пять действий, которые удлиняют простой

Руководитель отдела программистов Алексей Лялин сообщил об ошибках, которые приходется исправлять после аварии на Бегет:

«Первая ошибка – смена NS-записей у регистратора „чтобы быстрее переехать“. Новые NS начинают действовать не сразу, а в течение TTL, часто это сутки. Всё это время часть посетителей идёт на старые серверы, часть – на новые. Если новые ещё не настроены, вы получаете второй простой поверх первого.

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

Третья – массовая отправка тикетов. Пять обращений от одного клиента попадают в одну очередь и обрабатываются последовательно. Каждое новое обращение отодвигает ответ на первое.

Четвёртая – изменение настроек сайта во время сбоя. Правят .htaccess, меняют конфигурацию, отключают плагины. Доступ возвращается – сайт не работает уже по новой причине, и непонятно, по какой.

Пятая – публичные обещания клиентам „через час всё заработает“. Провайдер этого не обещал. Через час не заработало. Клиент потерян дважды».

Что делать вместо этого

Заглушка ставится только на отдельный поддомен или другой домен. Основной домен не трогается. Если переключить основной домен на заглушку с кодом 200, поисковые роботы получат вместо каталога одну страницу с текстом. Это вредит индексации сильнее, чем сам простой.

Что означают коды ответа, если сервер всё же отвечает

Бегет хостинг во время сетевого сбоя чаще не отвечает вообще. Но если ответ приходит, код указывает на место проблемы.

Ошибки 500–504 – это проблемы сервера или приложения, а не сети. Если вы видите их 2 ноября, ваша ситуация отличается от массовой. Таким обращениям поддержка уделяет отдельное внимание, потому что они не закрываются общим решением.

Как настроить мониторинг, чтобы узнавать о сбое раньше клиентов

Большинство владельцев сайтов 2 ноября узнали о проблеме от покупателей. Это самый дорогой способ. Мониторинг стоит от нуля до нескольких сотен рублей в месяц и присылает уведомление в течение одной-пяти минут после начала простоя.

Что настраивать:

• Проверку HTTPS главной страницы с интервалом 1–5 минут минимум из двух российских точек и одной зарубежной.

• Проверку по содержимому: сервер должен вернуть не просто код 200, а страницу с определённой строкой. Иначе заглушка хостера с кодом 200 будет считаться рабочим сайтом.

• Проверку формы или API: раз в час тестовый запрос, который проходит весь путь до базы.

• Проверку срока сертификата и домена: уведомление за 14 дней.

• Уведомления в Telegram и SMS, не только на почту. Почта может лежать вместе с сайтом.

Сервисы: UptimeRobot (бесплатно до 50 проверок с интервалом 5 минут), Яндекс Мониторинг, ping-admin.ru, HetrixTools. Для сайта с заказами достаточно бесплатного тарифа любого из них.

Бегет почта и заказы: как сохранить обращения клиентов во время аварии

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

Где хранится заявка и что с ней происходит при сбое

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

Руководитель РОСТСАЙТ Александр Кривов – о том, что конкретно делать в первый час после возвращения доступа:

«Иду от самого надёжного источника к самому ненадёжному.

Первый – кабинет платёжного шлюза. Там видны все оплаты за период простоя. Сравниваю со списком заказов на сайте. Оплата есть, заказа нет – значит, callback не дошёл. Большинство шлюзов повторяют callback несколько раз в течение суток, но не все. Можно нажать „повторить уведомление“ вручную или создать заказ руками.

Второй – база данных сайта. Заявки, которые PHP успел записать, лежат там независимо от почты. Запрос вида SELECT * FROM orders WHERE created_at BETWEEN '2026-11-02 03:00' AND '2026-11-02 18:00' показывает всё, что дошло. Для WordPress с Contact Form 7 без плагина сохранения – не покажет ничего: эта форма только отправляет письмо. Это главная уязвимость типового сайта.

Третий – access.log. Команда grep "POST" access.log | grep "02/Nov/2026" | grep -v " 200 " показывает попытки отправки, закончившиеся ошибкой. Контактов там нет. Но есть количество: вы узнаёте, сколько заявок потеряли.

Четвёртый – Бегет почта. Веб-интерфейс почты и Бегет личный кабинет открываю уже после первых трёх шагов. Входящие письма за период простоя придут сами с задержкой. А вот исходящие уведомления сайта – нет: они не отправились и не повторятся. Если заявки хранятся только в письмах, часть потеряна безвозвратно».

Как сделать так, чтобы заявки не терялись при следующем сбое

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

• Писать каждую заявку в базу данных до отправки письма. Для WordPress – Flamingo (к Contact Form 7), Gravity Forms, WPForms со встроенным хранением. Для Битрикса – веб-формы пишут в базу по умолчанию, но проверьте, что они не отключены. Для самописных сайтов – одна строка INSERT перед вызовом отправки письма.

• Дублировать уведомление в Telegram через бота. Это второй независимый канал с собственным сервером. Если почта не ушла – сообщение в Telegram ушло. Настройка – webhook на api.telegram.org, 20 минут работы.

• Отправлять письма через внешний SMTP-сервис с очередью. UniSender, Sendsay, SMTP.bz, Mailganer. Если сервис недоступен, письмо встаёт в очередь на их стороне, а не теряется.

• Включить повторные попытки передачи в CRM. В amoCRM и Битрикс24 это настраивается на стороне интеграции. Если CRM не ответила – заявка остаётся в очереди CMS и уходит позже.

• Включить повторные callback в платёжном шлюзе. У ЮKassa, Robokassa, Тинькофф Кассы есть настройка количества повторов. Поставьте максимум.

После этих настроек заявка при сбое теряется только в одном случае: если запрос вообще не дошёл до сервера. Это те посетители, которые увидели ошибку соединения в браузере. Их вернуть можно только рекламой и рассылкой – но вы хотя бы будете знать, сколько их было.

Что проверить, когда Бегет вход восстановлен

• Дата и время последнего заказа в базе до простоя и первого после – это ваше реальное окно потерь.

• Статус почтовых ящиков в панели: не переполнен ли ящик за время накопления очереди.

• Журнал отправки писем с сайта, если CMS его ведёт: какие уведомления не ушли.

• Наличие свежей резервной копии базы – на случай, если сверка с шлюзом потребует ручных правок.

Как восстановить позиции сайта в Яндексе после отключения Beget

Простой в несколько часов позиции не снижает. Робот Яндекса получил таймаут – он не удаляет страницу, а откладывает её обход и возвращается позже. Снижение начинается, когда недоступность длится дни, или когда после восстановления сайт продолжает отвечать с ошибками. Поэтому задача после сбоя – не «вернуть позиции», а убедиться, что роботу ничего не мешает обходить сайт в обычном режиме.

Как робот Яндекса реагирует на разные ответы сервера

Три нижние строки – единственный способ потерять позиции за короткий простой. Все они возникают не из-за хостинга, а из-за неправильной заглушки или редиректа на стороне владельца сайта.

Что проверить в первые сутки после восстановления сайта

Руководитель отдела программистов РОСТСАЙТ Алексей Лялин пояснил порядок проверки сайта:

«Сначала логи, потом Вебмастер. Вебмастер показывает данные с задержкой в день-два, а логи – прямо сейчас.

В access.log ищу визиты робота за период простоя: grep "YandexBot" access.log | grep "02/Nov/2026" | awk '{print $9}' | sort | uniq -c. Это даёт распределение кодов ответа, которые получил робот. Если там только таймауты – записей не будет вовсе, робот не дошёл до сервера, это лучший вариант. Если есть 200 – смотрю, что именно отдавалось по этим адресам. Если 404 или 301 – выписываю адреса, они пойдут на переобход в первую очередь.

Потом проверяю, что сейчас сайт отдаёт роботу то же, что и человеку: curl -A "Mozilla/5.0 (compatible; YandexBot/3.0)" -I https://example.ru/. Код 200, правильный Content-Type, без редиректов на мобильную версию или страницу-заглушку.

Третье – robots.txt и sitemap. curl https://example.ru/robots.txt – файл отдаётся, в нём нет Disallow: /, который иногда ставят на время работ и забывают убрать. curl -I https://example.ru/sitemap.xml – код 200. Если сайт генерирует sitemap динамически и во время сбоя робот получил по его адресу ошибку, Вебмастер покажет это как проблему с картой сайта.

Четвёртое – скорость ответа. После восстановления сервер может работать медленнее из-за холодного кэша. Время ответа главной и категорий должно укладываться в 1–2 секунды. Если больше 3 – робот снизит частоту обхода уже по этой причине, независимо от сбоя».

Что смотреть в Яндекс Вебмастере на второй-третий день

Если через 7–10 дней показы по важным страницам не вернулись, причина уже не в простое. Нужно смотреть техническое состояние этих страниц отдельно.

Переобход: что отправлять и чего не отправлять

Инструмент «Переобход страниц» в Вебмастере принимает ограниченное число адресов в сутки – для большинства сайтов несколько десятков. Тратить лимит на весь сайт бессмысленно.

Порядок приоритетов:

1. Страницы, которые по логам отдавали роботу 404, 301 или заглушку во время сбоя.

2. Главная страница и основные категории.

3. 10–20 страниц с наибольшим поисковым трафиком по данным Метрики.

4. Страницы, которые в Вебмастере попали в «Исключённые» с причиной «Ошибка HTTP».

Остальное робот обойдёт сам в течение одной-двух недель. Дополнительно можно обновить lastmod в sitemap для изменённых страниц и отправить их через IndexNow – этот протокол Яндекс поддерживает, и он быстрее стандартного обхода.

Чего не делать в первую неделю

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

• Не менять структуру URL и не настраивать массовые редиректы.

• Не закрывать сайт от индексации на время проверки.

• Не удалять страницы, которые временно выпали из индекса: они вернутся после переобхода.

Позиции после короткого простоя восстанавливаются сами при одном условии: сайт стабильно отвечает кодом 200 и за 1–2 секунды. Если это условие выполнено, никаких дополнительных работ по SEO сбой не требует.

Как построить сайт, который не ляжет вместе с Бегет хостинг при следующем сетевом сбое

Сбой 2 ноября показал: резервная копия на другом российском хостинге не спасает, когда проблема на сетях операторов. Нужна архитектура, при которой сайт остаётся доступен независимо от того, какие IP-адреса сегодня фильтруются. Это решаемая задача, и для большинства сайтов она укладывается в бюджет до 3 000 ₽ в месяц.

Александр Кривов назвал три уровня защиты по возрастанию стоимости:

«Уровень первый – статическая копия на CDN. Раз в сутки скрипт обходит сайт, сохраняет HTML, картинки и стили и выкладывает их в CDN с anycast-адресами: Selectel, EdgeЦентр, Cloudflare. У anycast один IP отвечает из десятков точек в разных сетях, и заблокировать его целиком сложнее, чем один сервер в одном дата-центре. При сбое основного сервера DNS переключается на CDN. Посетитель видит каталог, цены и контакты. Не работают только корзина и формы – для них ставится ссылка на Telegram и телефон. Стоимость – от нуля до 500 ₽ в месяц.

Уровень второй – автоматическое переключение DNS по состоянию сервера. DNS-провайдер с health check каждые 30–60 секунд проверяет основной сервер из нескольких точек. Три подряд неудачные проверки – A-запись переключается на резервный адрес, TTL 60 секунд. Это делают Cloudflare, Selectel DNS, NS1, Яндекс Cloud DNS. Переключение занимает две-три минуты вместо часов. Важно: проверки должны идти из российских сетей, иначе DNS увидит работающий сервер, когда для российских посетителей он лежит.

Уровень третий – второй живой сервер в другой сети. Не на другом российском хостинге в соседнем дата-центре, а в автономной системе с другими апстримами: другой город, другой магистральный оператор, при необходимости – другая страна. База реплицируется с задержкой в секунды, файлы синхронизируются rsync или через общее S3-хранилище. При сбое переключается DNS, и работает всё, включая заказы. Стоимость – от 1 500 ₽ в месяц за VPS плюс время на настройку репликации».

Технические требования к каждому уровню

Руководитель отдела программистов Алексей Лялин отметил две детали, которые ломают схему восстановления сайта, если их пропустить:

«Первая – где лежит DNS. Если DNS-серверы домена находятся у того же хостера, что и сайт, при сетевом сбое недоступны оба. Переключать нечем. DNS переносится к регистратору или к отдельному провайдеру, у которого серверы в разных сетях. Это бесплатно и делается за час.

Вторая – HTTPS на резерве. Сертификат должен быть выпущен и установлен на резервном сервере заранее. Let's Encrypt через DNS-валидацию позволяет держать один сертификат на обоих серверах. Если об этом не подумать, при переключении посетители увидят предупреждение браузера, и резерв окажется бесполезен».

Что проверить до того, как понадобится

• NS-записи домена указывают не на хостера сайта.

• TTL A-записи не больше 300 секунд.

• Health check настроен и присылает уведомление при переключении.

• На резерве установлен действующий сертификат.

• Тестовое переключение проведено и зафиксировано время полного восстановления доступа.

• Инструкция по ручному переключению лежит вне сайта и вне почты на этом же хостинге.

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

Бегет (Beget): сколько денег теряет бизнес из-за недоступности сайта

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

Потери = заказов в час × средний чек × часов простоя × доля посетителей, у которых сайт не открывался.

Последний множитель важен. 2 ноября Бегет хостинг был недоступен не у всех: у одних операторов сайт работал, у других нет. Долю недоступности берут из Метрики: сравнивают число визитов за часы простоя с тем же часом неделю назад. Если визитов было 40% от обычного – сайт не открывался у 60% посетителей.

Пример расчёта для интернет-магазина:

К прямым потерям добавляются три статьи, о которых обычно забывают:

• Рекламный бюджет, потраченный впустую. Клики на недоступный сайт оплачиваются. Сумму показывает отчёт Директа за часы простоя.

• Заявки, которые дошли, но не обработаны. Форма записала в базу, уведомление не ушло. Эти заказы не потеряны, но если их не найти (как – в разделе про почту и заказы), они превратятся в потери.

• Повторные обращения в поддержку и звонки. Время сотрудников, которые отвечали «не знаем, когда заработает».

Расчёт нужен не для жалобы хостеру – компенсации по типовому договору ограничены стоимостью услуги за период простоя. Он нужен, чтобы понять, сколько стоит резервная инфраструктура по сравнению с потерями. Если девять часов простоя стоят 75 тысяч рублей, резервный сервер за 500 рублей в месяц окупается первым же сбоем.

Почему после восстановления Бегет хостинг заказы не вернулись: где искать причину

Сайт открывается, Бегет вход работает, а конверсия вдвое ниже обычной. Это типичная картина первых суток после сбоя. Причины – технические и находятся по порядку.

Главный инженер и руководитель агентства РОСТСАЙТ Александр Кривов указал на то, что ломается после восстановления сайта чаще всего:

«После каждого длинного простоя проверяю одни и те же семь точек. В девяти случаях из десяти причина падения конверсии – в одной из них.

Первая – кэш. Страничный кэш сайта и кэш CDN могли сохранить страницу ошибки, которую сервер отдавал в момент восстановления. Посетитель видит „Ошибка 502“ на работающем сайте. Лечится полным сбросом кэша CMS и очисткой CDN.

Вторая – внешние скрипты. Капча Яндекса, виджет чата, карта, платёжная форма, скрипт Метрики. Если фильтрация задела домены этих сервисов, форма с капчей не отправляется, а Метрика не считает визиты – и вам кажется, что трафика нет. Проверяется в консоли браузера: красные строки с net::ERR_ или Failed to load resource.

Третья – сессии и корзины. Если сессии хранились в Redis или Memcached и эти сервисы перезапускались, все корзины обнулились. Посетитель вернулся – корзина пустая. Он не будет собирать её заново.

Четвёртая – обмен с 1С. Выгрузка остатков и цен не прошла в окно простоя. На сайте старые остатки. Посетитель заказывает товар, которого нет, или не заказывает товар, который есть.

Пятая – cron. Задачи, которые должны были выполниться за время простоя, не выполнились. Не обновились статусы заказов, не ушли письма о доставке, не пересчитались скидки.

Шестая – сертификат. Автопродление Let's Encrypt, выпавшее на день сбоя, не отработало. Браузер показывает предупреждение, посетитель уходит.

Седьмая – лимиты. После восстановления на сервер одновременно приходят отложенные запросы роботов, мониторинга, интеграций и живых людей. Сайт на минимальном тарифе упирается в лимит процессов PHP и отдаёт 502 части посетителей. Это видно в error.log по записям server reached pm.max_children».

Как увидеть потери в Метрике и отделить их от последствий

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

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

FAQ: 10 вопросов о сбое Бегет (Beget), которые задают владельцы сайтов

1. Можно ли потерять доменное имя из-за аварии Beget? Нет. Регистрация домена и хостинг – разные услуги, даже если оплачены у одного провайдера. Домен теряется только по истечении срока регистрации. Проверьте дату окончания командой whois example.ru и поставьте напоминание за месяц.

2. Нужно ли менять пароль от Бегет личного кабинета после аварии? Сам по себе сетевой сбой не означает утечки. Но если пароль простой, используется ещё где-то или не включена двухфакторная аутентификация – это повод исправить. При признаках чужого входа (незнакомые сессии в журнале, изменённые настройки) пароль меняется немедленно.

3. Можно ли работать с сайтом через FTP, если Бегет вход не открывается? Часто да: это разные сервисы на разных портах. Проверьте командой nc -zv example.ru 22. Если порт отвечает, через SSH или SFTP можно смотреть логи и состояние сервера, даже когда веб недоступен. Обычный FTP без шифрования не используйте.

4. Повлияет ли авария Beget на сертификат HTTPS? Сам простой сертификат не трогает. Но если на день сбоя приходилось автопродление Let's Encrypt, оно могло не отработать. Проверьте срок действия после восстановления: echo | openssl s_client -connect example.ru:443 2>/dev/null | openssl x509 -noout -dates. При необходимости перевыпустите в панели.

5. Почему сайт открывается с компьютера, но не с телефона (или наоборот)? Потому что это разные сети с разными операторами и разными резолверами. Во время сетевой фильтрации это типичная картина и признак того, что сервер исправен. Для чистоты проверки сбросьте DNS-кэш на устройстве или перезагрузите его.

6. Могли ли пропасть файлы или база данных? При сетевом сбое – нет, данные лежат на диске и никуда не деваются. При аппаратной аварии на стороне хостера – теоретически да. Поэтому после восстановления выборочно откройте несколько файлов и записей из базы и убедитесь, что свежая резервная копия создаётся.

7. Нужно ли сообщать клиентам о недоступности? Если простой заметен для клиентов и длится больше часа – да, коротко и без обещаний: «сайт временно недоступен, заказы принимаем по телефону и в мессенджере». Это сокращает поток повторных обращений и сохраняет доверие.

8. Можно ли принимать оплату, пока сайт лежит? Да, если у платёжного провайдера есть выставление счёта по ссылке или QR-коду из личного кабинета – у ЮKassa, Робокассы, Тинькофф Кассы это есть. Для юридических лиц – обычный счёт по почте. Учтите такие оплаты вручную, чтобы потом сопоставить с заказами на сайте.

9. Кто отвечает за персональные данные клиентов при аварии? По закону – оператор персональных данных, то есть владелец сайта, независимо от того, где сайт размещён. Сетевой сбой утечкой не является. Если есть основания подозревать несанкционированный доступ, это отдельная процедура с уведомлением Роскомнадзора в установленные сроки.

10. Когда можно снова включать рекламу? Когда пройдена проверка после восстановления: страницы открываются из разных сетей, тестовая заявка дошла до почты и CRM, тестовая оплата прошла, Метрика пишет данные. Включать рекламу по факту открывшейся главной страницы – платить за клики на сломанные формы.

Итог: Beget восстановится, но бизнесу необходим контроль технической устойчивости

Сбой 2 ноября 2026 года был сетевым, а не серверным: по данным провайдера, трафик не доходил до исправных серверов из-за изменений в работе ТСПУ. Для владельца сайта из этого следуют три практических вывода.

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

После восстановления доступа проверять нужно не главную страницу, а путь покупателя до подтверждения заказа: формы, капчу, CRM, callback платёжного шлюза, cron, сертификат, лимиты PHP. Именно они ломаются после долгого простоя, а не сервер.

И независимо от того, остаётесь вы на Beget или нет, у сайта должны быть DNS вне хостера, TTL не больше 300 секунд, внешние резервные копии и хотя бы статическая копия на CDN. Не потому, что следующий сбой обязательно случится у хостера, а потому, что в момент аварии настраивать это уже поздно.

Читайте также:

• Автоматизация без иллюзий: что действительно окупается в малом бизнесе
• Вместо кнута в России придумали пряники для тех, кто избавляется от западного софта
• Вся правда о цифровом рубле в «Магните»: о чем молчат разработчики