Обсудить идею
Главная / Журнал / Переезд сайта на Timeweb: 7 часов до открытия по домену — наш опыт и чек‑лист
Кейсы · 9 ноября 2026 г., 07:40 МСК · 8 мин

Переезд сайта на Timeweb: 7 часов до открытия по домену — наш опыт и чек‑лист

Перенесли готовый сайт клиента на виртуальный хостинг Timeweb. Сам перенос занял 15 минут, а запуск по домену с сертификатом — ещё 7 часов. Хронология, с чем столкнулись и чек‑лист для любого переезда.

Переезд сайта на Timeweb: 7 часов до открытия по домену — наш опыт и чек‑лист

Это описание нашего личного опыта одного переноса и наше субъективное мнение. Материал не является юридической или технической экспертизой и не утверждает, что сервис что‑либо нарушил. У других клиентов опыт может быть другим.

Коротко: мы перенесли готовый сайт клиента на виртуальный хостинг Timeweb за 15 минут. Ещё 7 часов ушло на то, чтобы сайт открылся по домену у всех и получил бесплатный сертификат. Ниже — что происходило по порядку и чек‑лист, который поможет пройти переезд быстрее.

Исходные данные

  • Клиент — небольшая гостиница в центре Петербурга. Старый сайт перестал работать после сбоя у прежнего хостинга 2 ноября.
  • Мы собрали новый сайт на WordPress с админкой в его стиле: номера, цены, бронирование, политика, Метрика.
  • Клиент выбрал виртуальный хостинг Timeweb. Наша задача — перенести сайт и запустить на его домене. Почта клиента остаётся у прежнего провайдера — её трогать нельзя.

Хронология

Время (МСК)Что происходило
~20:30Клиент оформил хостинг. В письме — логин, пароль и IP
20:45По FTP вход есть. По SSH с этими данными — «доступ запрещён»
21:00После нескольких неудачных попыток входа соединения с нашего IP перестали проходить — и по SSH, и к сайтам на сервере. Скорее всего, сработала автоматическая защита
21:10Владелец включил SSH в панели
21:20Подошли пароль от аккаунта и логин без суффикса — в письме мы этого не нашли
21:22В веб‑консоли панели у нас не получилось вставить текст — ключ добавить не удалось
21:25Файлы сайта и база перенесены по SSH. Саму базу данных создали в панели
21:30Сайт работает на сервере, но по домену открывается заглушка «Ваш аккаунт готов к работе»
21:35Выяснили: домен привязан к «Основному сайту», а папка с именем домена не используется
23:32Обращение в поддержку: DNS обновлены 3 часа назад, сайт не виден
23:33Ответ: проверяют, «мы уже занимаемся». Решение в итоге нашли сами
00:30Заказ бесплатного сертификата в панели: «Сайт недоступен», «Домен не перенесён в Timeweb»
01:10Проверка из 12 стран: сайт открывается у 11 из 12, а у владельца — нет
01:20Нашли причину: у домена была IPv6‑запись (AAAA), которая вела не на сервер с сайтом
01:30Удалили AAAA у домена и у www
03:00Панель всё ещё показывает «Домен не у нас», сертификат не выпускается
03:30Решили выпустить сертификат на своём сервере; сайт остаётся на хостинге клиента
03:45DNS‑серверы ещё какое‑то время отдают разные ответы — ждём синхронизации
04:20Сертификат выпущен, сайт работает по https
04:50Запросы с нашего сервера к хостингу перестали проходить. Перенастроили схему: туннель через другой наш сервер и кэш

С чем мы столкнулись

1. Данные для SSH

В письме — логин вида cm…_rebornl и пароль. С ними работает FTP. Для SSH у нас подошли логин без суффикса и пароль от аккаунта. Если вы впервые включаете SSH — уточните в справке хостинга, какие данные нужны именно для него.

2. Автоматическая блокировка после неудачных входов

После нескольких неудачных попыток входа соединения с нашего IP перестали проходить не только по SSH, но и к сайтам. Многие хостинги так защищаются от подбора паролей — это нормальная мера. Важно знать о ней заранее: если сайт «не открывается» только у вас, а у остальных работает, причина может быть в такой блокировке.

3. Веб‑консоль

В панели есть консоль сервера, но вставить в неё длинный ключ у нас не получилось. Пришлось искать другой способ входа.

4. Две папки и заглушка

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

5. Главное: IPv6‑запись

У домена была запись AAAA (IPv6), которая вела не на сервер с нашим сайтом, а на заглушку.

Что это значит на практике: - У кого есть IPv6 — а это многие мобильные операторы — сайт может не открываться: устройство идёт по IPv6 и попадает на заглушку. - Let's Encrypt проверяет домен в том числе по IPv6 — и при такой записи сертификат не выпускается. - При проверке только A‑записи (IPv4) всё выглядит корректно, поэтому причину легко не заметить.

Заказ бесплатного сертификата в панели: «Сайт недоступен», «Домен не перенесён в Timeweb» (домен скрыт)
Заказ бесплатного сертификата в панели: «Сайт недоступен», «Домен не перенесён в Timeweb» (домен скрыт)

6. Поддержка

Обращение в поддержку: вопрос в 23:32, ответ в 23:33 (имена и домен скрыты)
Обращение в поддержку: вопрос в 23:32, ответ в 23:33 (имена и домен скрыты)

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

7. Сертификат для домена другого регистратора

Даже после удаления IPv6‑записей панель показывала у домена статус «Домен не у нас», и бесплатный сертификат не выпускался. Домен зарегистрирован у другого регистратора — так у многих. Мы не нашли в панели объяснения, что делать в этом случае, поэтому выпустили сертификат сами.

Раздел «Домены и SSL»: у домена статус «Домен не у нас», сертификата нет (адреса доменов скрыты)
Раздел «Домены и SSL»: у домена статус «Домен не у нас», сертификата нет (адреса доменов скрыты)

8. Синхронизация DNS‑серверов

После смены A‑записей DNS‑серверы какое‑то время отвечали по‑разному. Let's Encrypt спрашивает любой из них — поэтому проверка то проходила, то нет. Это решается ожиданием.

9. Платная опция при заказе сертификата

При заказе бесплатного сертификата у нас была отмечена опция «Настройка защищённого соединения» — 99 ₽ в месяц. Если вы умеете настроить перенаправление на https сами, проверьте, нужна ли она вам.

Как мы запустили сайт

  1. Проверили домен из 12 стран, отдельно по IPv4 и IPv6, и нашли лишнюю AAAA‑запись.
  2. Удалили AAAA у домена и у www.
  3. Подняли на своём сервере обратный прокси: посетитель приходит к нам, а мы передаём запрос сайту на хостинге клиента. Сайт, база и админка остаются у клиента.
  4. Направили домен на свой сервер и дождались синхронизации DNS.
  5. Выпустили сертификат Let's Encrypt на домен и www.
  6. Настроили WordPress для работы по https за прокси и заменили адреса в базе.
  7. Проверили результат снаружи — из десяти стран, включая Россию.

Почта клиента при этом не тронута.

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

Человеку без технического опыта пройти такие шаги самостоятельно сложно — поэтому ниже чек‑лист.

Чек‑лист: что проверить после переезда на любой хостинг

  1. IPv6 (AAAA). Есть ли AAAA у домена и у www и куда она ведёт. Если сайт по IPv6 не обслуживается — удалить.
  2. Куда привязан домен в панели — в какую папку. Класть файлы туда.
  3. SSH. Какие логин и пароль нужны именно для SSH, не путать с FTP.
  4. Не подбирать пароль. После нескольких ошибок многие хостинги блокируют IP, в том числе для сайтов.
  5. Почта. Записи MX, SPF, DKIM — сверить со старыми до смены DNS.
  6. Сертификат. Если панель не выпускает — проверить AAAA и кэш DNS.
  7. Проверка снаружи. Открывать сайт не только у себя: кэш DNS и блокировки сбивают с толку. Проверки из разных стран показывают реальную картину.
  8. Документы. Если на сайте есть формы заявок — политика обработки персональных данных и согласие должны быть на месте и после переезда.

Чему мы научились

  • Автопилот запуска домена. Клиент меняет DNS — наш сервер сам выпускает сертификат, включает https и присылает уведомление в Telegram.
  • https через свой сервер, если на хостинге его быстро не включить.
  • Перенос WordPress на хостинг клиента — файлы, база, замена адресов, проверка — за 15 минут.
  • Восстановление сайта из веб‑архива в его родном дизайне — с теми же адресами страниц, текстами и формами заявок.
  • Уведомления клиенту в Telegram‑боте: «сайт заработал», «сайт перестал открываться».

Итог

Сам перенос занял 15 минут, запуск по домену с сертификатом — ещё 7 часов. Большая часть времени ушла на поиск лишней IPv6‑записи и выпуск сертификата. Если вы переезжаете — пройдите чек‑лист выше. Если не хочется разбираться самим — напишите нам, поможем.

Материал отражает личный опыт и субъективное мнение автора по одному конкретному переносу и не является юридической консультацией.

Комментарии

Пока нет комментариев — будьте первым.

Комментарии публикуются после проверки.

Применим к вашей задаче

Хотите так же? Разберём бесплатно.

Написать в Telegram

Получили ✓ Разберём задачу и ответим вам лично.

Отвечаем лично. Без спама и обязательств — сначала разбираемся, потом предлагаем.

Отметьте согласие на обработку данных — без него мы не можем принять заявку.

Читайте также
Кейсы · 4 ноября 2026 г., 17:56 МСК

Beget не работает (4 ноября 2026): как мы за сутки подняли сайт клиента без доступа к хостингу

Хостинг Beget лёг после атаки, сайт магазина тканей перестал открываться, доступа к файлам нет. Рассказываем по шагам, как восстановили сайт из веб-архива и кэша Яндекса, перенесли домен и запустили на новом сервере.

Кейсы · 2 октября 2026 г.

Кейс: как собрать сайт-справочник на сотни страниц, который приводит людей из поиска

Как мы делаем справочники на 200–500 страниц без тяжёлой CMS: генератор статичных страниц, структура «ситуация → шаги → закон → куда обратиться», разметка и перелинковка.

Сайты · 8 ноября 2026 г., 07:01 МСК

Буду ли я съезжать с Бегет после сбоя? Нет — и вот почему

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