[Главная](https://servhidden.com/ru) / [Руководства по приватному хостингу](https://servhidden.com/ru/guides) / Как перенести сайт на офшорный хостинг без простоя Эксплуатация # Перенос на офшорный хостинг без простоя Почти каждая болезненная миграция — это провал не техники, а порядка действий: TTL, сниженный в ночь переезда, а не за два дня до него, сертификат, выпущенный после смены DNS, а не до неё, и cron-задача, оставленная активной на сервере, который больше не авторитетен. Это последовательность, которая полностью убирает окно простоя — а заодно раскрывает то, что обычные гайды опускают: что переезд навсегда фиксирует о вас и что с этим всё ещё можно сделать. [Читать руководство](#guide-body) [FAQ](#guide-faq) ## На этой странице - [Руководство](#guide-body) - [FAQ](#guide-faq) - [Похожие руководства](#guide-related) - [Рекомендуемые страницы](#guide-cta) Без KYC Только крипто Без логов DMCA игнорируется Полный root NVMe SSD 18 мин чтения Обновлено Aug 2026 На этой странице [01Что на самом деле означает «нулевой простой»](#Что-на-самом-деле-означает-нулевой-простой) [02Снизьте DNS TTL за несколько дней до переезда](#Снизьте-dns-ttl-за-несколько-дней-до-переезда) [03Составьте опись того, что переносите, а не того, что помните](#Составьте-опись-того-что-переносите-а-не-того-что-помните) [04Сначала соберите новый сервер и защитите его прежде, чем он станет что-то хранить](#Сначала-соберите-новый-сервер-и-защитите-его-прежде-чем-он-с) [05Копируйте данные дважды: сначала медленный проход, потом быстрый](#Копируйте-данные-дважды-сначала-медленный-проход-потом-быстр) [06Протестируйте новый сервер прежде, чем о нём узнает DNS](#Протестируйте-новый-сервер-прежде-чем-о-нём-узнает-dns) [07Переключение по шагам](#Переключение-по-шагам) [08Что миграция оставляет после себя](#Что-миграция-оставляет-после-себя) [09Вопрос домена: перенести или начать с чистого листа?](#Вопрос-домена-перенести-или-начать-с-чистого-листа) [10Правильно выводите старый хост из эксплуатации](#Правильно-выводите-старый-хост-из-эксплуатации) [11Вся последовательность на одной странице](#Вся-последовательность-на-одной-странице) [FAQЧастые вопросы](#guide-faq) [→Рекомендуемые страницы](#guide-cta) Никто не переносит работающий сайт ради развлечения. Это случается потому, что нынешний хостер вдруг требует фото паспорта, пересылает жалобу со сроком в двадцать четыре часа, или потому что страна, где стоит его дата-центр, перестала выглядеть разумным местом для хранения ваших данных. Что бы вас к этому ни подтолкнуло, опасен именно сам переезд — это единственный момент, когда сайт может погаснуть, и единственный момент, когда неосторожный шаг способен намертво привязать новый сервер к личности, от которой вы пытались уйти. У обоих рисков одно и то же лекарство, и это не инструмент. Это порядок действий. Миграция, выполненная в правильной последовательности, не оставляет окна недоступности сайта, потому что оба сервера какое-то время работают одновременно, а DNS переключается последним. Миграция, выполненная в неправильном порядке, одновременно даёт и простой, и след. Дальше — эта последовательность, описанная для тех, кто переезжает на офшорный хостинг без KYC, а не просто перекладывает сайт между двумя обычными провайдерами: механика та же, а вот зачистка после переезда — нет. ## Что на самом деле означает «нулевой простой» Фразу используют слишком вольно, и именно в этой вольности люди и обжигаются. Отдавать HTTP с двух машин одновременно — просто. Держать *состояние* согласованным, пока обе машины работают одновременно, — вот что сложно, и это единственная часть, где вообще можно потерять данные. Поэтому прежде чем что-либо планировать, определите, с чем из перечисленного вы имеете дело на самом деле: ответ задаёт форму всей ночи. | Что вы переносите | Что на самом деле кусается | Каким должен быть план | | --- | --- | --- | | Статический сайт, сайт-визитка, сгенерированный вывод | Ничего. Делить нечего — состояния нет | Скопировать, проверить, переключить. По-настоящему нулевой простой | | CMS с базой данных — WordPress, Ghost, форум | Комментарии, логины и посты одновременно попадают в две базы | Заморозка на запись длиной в **минуты**, в самый тихий час | | Магазин или что угодно, принимающее заказы | Раздвоение состояния тихо теряет оплаченные заказы | Возьмите короткое окно обслуживания. Это дешевле сверки | | Всё, что использует cron или фоновые обработчики | Одна и та же задача срабатывает на обоих серверах — двойные письма, двойные списания | Отключите расписание на старом хосте *до* запуска нового | | Почта на том же домене | Записи MX устаревают в кэшах по своему собственному таймеру, не связанному с вашей записью A | Переносите почту отдельной ночью и держите старый MX принимающим почту ещё неделю | Обратите внимание: по-настоящему бесплатна только первая строка. Везде дальше «нулевой простой» означает «заморозка записи настолько короткая, что на неё никто не заводит тикет». Две минуты режима только для чтения в 04:00 — это статистическая погрешность; два часа раздвоенной записи в две базы — это выходные, потраченные на сверку. Выбирайте заморозку. Оба сервера работают одновременно, а DNS переключается последним — именно поэтому у правильно выстроенного переключения нет окна простоя вообще. ## Снизьте DNS TTL за несколько дней до переезда Это единственный шаг с временем на подготовку, поэтому он идёт первым — и именно его чаще всего пропускают. Ваш TTL — время жизни записи — сообщает каждому резолверу в интернете, как долго он может держать вашу запись в кэше, прежде чем спросить снова. Если у вашей записи A TTL равен 86400, резолвер, который заглядывал в неё час назад, будет отдавать старый IP ещё двадцать три часа — что бы вы ни поменяли у регистратора. Важная деталь: само снижение TTL подчиняется старому TTL. Резолверы узнают о новом, более коротком значении только тогда, когда истечёт срок жизни старой закэшированной копии. Поэтому снижайте TTL до 300 секунд **минимум за один полный период старого TTL до переключения** — при суточном TTL это значит сделать это за 24–48 часов. Тогда весь интернет сходится на новой записи в течение пяти минут после изменения, и переключение перестаёт быть событием с интригой. Через несколько дней после переезда верните TTL к разумному значению. TTL в 300 секунд — отличный инструмент, но плохая постоянная настройка: он умножает объём запросов и делает вашего DNS-провайдера куда более острой единой точкой отказа. ## Составьте опись того, что переносите, а не того, что помните У каждой провалившейся миграции один и тот же разбор полётов: что-то, чего не было в списке, забыли скопировать. Корень сайта и базу данных помнят все; список ниже — это всё остальное, и его стоит пройти буквально, а не по памяти. - **Запланированные задачи.** crontab -l для каждого пользователя, плюс таймеры systemd. Здесь прячутся хуки продления сертификатов и ночные задания. - **Определения сервисов.** Собственные юниты systemd, vhosts веб-сервера, пулы PHP-FPM, любой конфиг supervisor. - **Секреты и окружение.** Файлы .env, API-ключи, пароли базы данных, соли приложения — и учтите, что их нужно не просто скопировать, а сменить. - **Материалы TLS.** Сертификаты и, что важнее, аккаунт ACME и конфигурация продления. - **Почтовая идентичность.** Приватные ключи DKIM, записи SPF и DMARC. Несовпадение здесь не ломается громко — оно просто тихо отправляет вашу почту в спам. - **Загруженные медиафайлы.** Часто лежат вне корня сайта, часто оказываются самым тяжёлым, что у вас есть. - **Всё внешнее, что доверяет вашему IP.** Белые списки платёжного шлюза, адреса для вебхуков, файрволы баз данных, сторонние API с ограничением по IP. Это причина номер один ситуации «сайт работает, а оформление заказа сломано» в три часа ночи. - **Список пакетов.** dpkg --get-selections или его аналог — чтобы на новой машине были те же расширения и библиотеки, а не почти те же. Запишите список до того, как начнёте копировать. Позже эта опись станет вашим планом тестирования — каждая её строка — это то, что нужно проверить на новом сервере, прежде чем о нём узнает DNS. ## Сначала соберите новый сервер и защитите его прежде, чем он станет что-то хранить Закажите сервер назначения заранее и дайте ему день-два поработать пустым. Пересечение по времени ничего не стоит — небольшой офшорный VPS обходится в несколько долларов в месяц, — а вот собирать систему под давлением времени, с замороженной базой данных, которая ждёт, стоит очень дорого. Осознанно повторите старое окружение: тот же дистрибутив и та же мажорная версия, та же мажорная версия PHP, Node или Python, та же мажорная версия базы данных. Соблазн заодно всё модернизировать огромен, и ему нужно полностью сопротивляться. Если сайт сломается после переключения, вы хотите, чтобы изменилась ровно одна переменная. Обновляйте стек через пару недель, в скучный будний день, с возможностью откатиться. Защитите сервер, пока он ещё пуст. SSH только по ключам, файрвол с запретом по умолчанию, автоматические обновления безопасности — [чек-лист хардненинга первого часа](https://servhidden.com/ru/guides/first-hour-vps-hardening-checklist) — это именно такой список, и применить его к машине, на которой ещё ничего нет, гораздо проще. Если данные достаточно чувствительны, чтобы из-за них менять юрисдикцию, это ещё и подходящий момент решить вопрос с [шифрованием данных на диске](https://servhidden.com/ru/guides/full-disk-encryption-on-a-vps), потому что добавлять его задним числом — значит затевать ещё одну миграцию. ## Копируйте данные дважды: сначала медленный проход, потом быстрый Инстинкт подсказывает копировать всё прямо во время окна обслуживания. Сделайте наоборот. Запустите полную копию за несколько дней, пока старый сайт спокойно отдаёт трафик, а при переключении сделайте второй проход, который переносит только изменившееся. Первый проход может занять шесть часов, и никто этого не заметит. Второй занимает девяносто секунд — это и есть весь ваш бюджет простоя. Для файлов rsync -aHAX --numeric-ids сохраняет права, владельца, жёсткие ссылки и расширенные атрибуты; флаг --numeric-ids важен, потому что UID редко совпадают между двумя свежесобранными машинами. Запустите его один раз заранее, затем ещё раз непосредственно перед переключением с теми же аргументами — второй запуск перенесёт только дельту. Базы данных требуют той же двухфазной обработки, но других инструментов. mysqldump --single-transaction или pg_dump дают согласованный ранний снимок, на котором можно собирать и тестировать систему. При переключении либо снимите второй дамп во время короткой заморозки записи, либо — для крупной базы, где даже короткая заморозка ощутима, — заранее, за несколько дней, разверните новый сервер как реплику старого, дайте ей догнать мастер и затем повысьте её. Репликация сокращает заморозку до секунд. Она же превращает двухчасовую миграцию в двухдневный проект, поэтому используйте её только тогда, когда размер базы этого действительно требует. **Забирайте (pull), а не отправляйте (push), и никогда — через свой ноутбук.** Инициируйте копирование с нового сервера, чтобы передача шла напрямую между хостами со скоростью дата-центра. Прогонять гигабайты через домашнее соединение медленно, и это оставляет ваш домашний IP в логах доступа обеих машин — а именно такой связи и призвана избежать миграция, продиктованная соображениями приватности. Если даже то, что старый хостер узнает ваш новый IP, неприемлемо, не копируйте напрямую вообще: вместо этого разверните новый сервер из собственного [зашифрованного бэкапа, хранящегося отдельно](https://servhidden.com/ru/guides/vps-backup-strategy), и тогда машины вообще не обменяются ни одним пакетом. ## Протестируйте новый сервер прежде, чем о нём узнает DNS Вы можете отдавать реальное имя хоста с нового IP, не меняя ни одной публичной записи, — и вам стоит это сделать: именно это делает переключение скучным и бессобытийным. Добавьте строку в локальный /etc/hosts, направив домен на новый IP, либо пропустите этот шаг и поручите то же самое curl для одного запроса: curl -I --resolve example.com:443:203.0.113.10 https://example.com/ Теперь пройдитесь по описи. Загрузите главную страницу и три страницы поглубже. Войдите в аккаунт. Отправьте форму. Загрузите файл. Проверьте, что подключение к базе данных смотрит на новую, локальную, а не всё ещё на старый хост через интернет — ошибка, которая прекрасно работает ровно до того момента, как вы отмените старый сервер. Запустите cron-задачи вручную и прочитайте их вывод. Проверьте редиректы и то, что отсутствующий URL по-прежнему возвращает 404, а не 200. Выпустите TLS-сертификат сейчас, до переключения, а не после. Используйте проверку DNS-01: она подтверждает владение доменом через TXT-запись и потому работает, пока запись A всё ещё указывает на старый сервер. Если дождаться проверки HTTP-01 после смены DNS, каждый ранний посетитель в этот промежуток получит предупреждение о сертификате — самостоятельно устроенный простой ровно в том окне, которое вы и пытались защитить. ## Переключение по шагам К этому моменту новый сервер уже собран, защищён, наполнен данными, протестирован под реальным именем хоста и держит действительный сертификат. Само переключение теперь — короткий, скучный список, и это именно то, к чему мы шли. - Если от сайта зависит кто-то ещё, объявите об окне обслуживания, затем переведите старый сайт в режим только для чтения или обслуживания. - **Отключите cron и фоновые обработчики на старом хосте.** Сделайте это до запуска их на новом, а не после. - Выполните финальный проход дельты rsync и финальный дамп базы данных, затем импортируйте его. - Запустите приложение на новом сервере и заново прогоните дымовые тесты через --resolve, уже на финальных данных. - Смените записи A и AAAA на новый IP. При TTL в 300 секунд весь интернет подтянется в течение пяти минут. - Включите cron и обработчики на новом хосте. - Смотрите на оба лога доступа бок о бок. Трафик стекает со старого сервера и появляется на новом; когда старый затихает, переключение завершено. - Оставьте старый сервер работающим, обслуживающим запросы и нетронутым на неделю. Это ваш путь отката. Восьмой шаг — тот, который обычно вырезают, а это самая дешёвая страховка во всём списке. За цену нескольких долларов вы сохраняете возможность вернуть DNS назад — восстановление за пять минут — на всё время, пока не убедитесь, что всё в порядке. ## Что миграция оставляет после себя Вот часть, которую обычные гайды по миграции опускают, и та самая часть, что важнее всего, если вы переезжали ради приватности, а не ради цены. Перенос сайта не стирает его историю. Несколько публичных и полупубличных записей о старом устройстве переживают переезд навсегда, и знание того, какие именно, — это разница между по-настоящему чистым разрывом и лишь ощущением такового. | Что фиксирует переезд | Кто может это прочитать | Что вы реально можете сделать | | --- | --- | --- | | Пассивный DNS — исторические записи A | Кто угодно, через коммерческие сервисы истории | **Ничего.** Старый IP навсегда связан с именем. Планируйте так, будто это публичная информация, потому что это она и есть | | Логи Certificate Transparency | Кто угодно, навсегда, с поиском по домену | В списке — каждый когда-либо выпущенный сертификат, включая забытые поддомены с «внутренними» именами. Предпочитайте wildcard-сертификаты описательным именам | | Учётные записи у старого хостера | Старый хостер и все, кто может его к этому принудить | Данные карты, email регистрации, IP входов. Направление без KYC защищает будущее, а не прошлое | | История WHOIS | Коммерческие архивы истории WHOIS | Если домен хоть раз регистрировался с реальными данными, этот снимок уже сохранён. Приватность, включённая позже, его не отзывает | | Идентификаторы аналитики и рекламы | Поставщик сервиса и любой, кто читает исходный код вашей страницы | Один и тот же трекинг-ID окончательно связывает два сайта. Выпустите новый или откажитесь от него | | Дампы и бэкапы, оставшиеся на старом диске | Тот, кому это хранилище достанется следующим | Удалите и перезапишите до отмены сервера. На общем хранилище считайте, что удаление — это намёк, а не гарантия | | Заголовки Received: в отправленной почте | Каждый получатель, навсегда | Ничего задним числом не исправить. Новый путь несёт только почта, отправленная после переезда | | Ваши собственные подключения во время копирования | Ваш интернет-провайдер и логи доступа обоих хостов | Это единственный пункт, полностью в вашей власти. Никогда не подключайтесь ни к одной из машин с IP, который вас идентифицирует | Честный итог таков: миграция не может переписать прошлое — она может только перестать его пополнять. Это всё ещё стоит очень многого, но меняет саму постановку решения: если ваша модель угроз требует, чтобы ни один наблюдатель не мог связать новый сайт со старым, перенос того же домена на новый хостинг этого не даёт — и никакая аккуратность при переключении этого не изменит. Для такого случая нужны новое имя и чистый старт — подробнее об этом дальше. Если же ваша цель — просто перестать с сегодняшнего дня порождать идентифицирующие записи и перенести правовой центр тяжести в выбранную вами юрисдикцию, перенос делает ровно это. Наш [гайд по опсеку сервера](https://servhidden.com/ru/guides/server-opsec-staying-anonymous) описывает привычки, которые сохраняют это в чистоте и дальше. ## Вопрос домена: перенести или начать с чистого листа? Сайт и домен — независимые друг от друга решения, и их часто путают. Вы можете перенести хостинг сегодня и никогда больше не трогать регистратора; смена сервера сама по себе никак не требует трогать домен. А вот *стоит* ли его трогать, целиком зависит от того, что домен уже о вас знает. - **Оставить домен, сменить регистратора.** Разумно, когда у домена есть ценность — ссылки, позиции в выдаче, имя, которое люди набирают руками. Это фиксирует будущее записи WHOIS, но не её историю, и сохраняет в целости все сигналы ранжирования. Для большинства коммерческих сайтов это правильный ответ. - **Оставить домен, не менять вообще ничего, кроме хостинга.** Вполне разумно, если вы переезжали ради юрисдикции, аптайма или позиции по DMCA, а не ради анонимности. Простейший из возможных ходов, нулевой риск для SEO. - **Новый домен с редиректом со старого.** Сохраняет позиции в выдаче и публично, навсегда связывает два имени. Выбирайте этот вариант ради преемственности, но никогда ради приватности — редирект и есть та самая связь. - **Новый домен, чистый разрыв.** Единственный вариант, реально разрывающий связь, и он стоит вам всех позиций в выдаче и всех входящих ссылок, что у вас были. Регистрируйте его приватно с самого начала, потому что домен анонимен ровно настолько, насколько анонимна была его первая регистрация. Наш гайд по [анонимной регистрации домена за криптовалюту](https://servhidden.com/ru/guides/anonymous-domain-registration-with-crypto) подробно разбирает, как сделать это правильно. Выбирайте осознанно, и выбирайте до переключения, а не во время него. Передумать насчёт домена после того, как DNS уже переехал, значит проделывать деликатную часть работы дважды. ## Правильно выводите старый хост из эксплуатации Через неделю-две после переключения, когда логи нового сервера скучны, а логи старого пусты, приходит время закрывать старый аккаунт. Делайте это именно в таком порядке, потому что самый соблазнительный короткий путь — нажать «отменить» — как раз тот, что оставляет ваши данные на чужом диске. - Убедитесь, что ничто больше не указывает на старый IP: проверьте жёстко прописанные адреса в сторонних вебхуках, белых списках, мониторинге, и любую забытую DNS-запись вроде случайно оставшегося поддомена mail или cpanel. - Смените все секреты, когда-либо жившие на этой машине, — пароли баз данных, API-ключи, соли приложения, ключи DKIM, ключи SSH. Не переносите их на новый сервер. - Удалите свои публичные ключи SSH и любой доступ поддержки со старого сервера. - Удалите приложение, дампы и бэкапы, затем перезапишите свободное место, чтобы беглое чтение переработанного тома не дало ничего. - Только после этого отключайте услугу и удаляйте из старого аккаунта любой сохранённый способ оплаты. **Всё, что жило на железе, которое вы больше не контролируете, по определению скомпрометировано.** Не потому что ваш старый хостер злонамерен, а потому что этот диск вернётся в общий пул, и вы никогда не узнаете, что пережило зачистку. Смена пароля базы данных занимает две минуты. Обнаружить месяцы спустя, что ключ с выведенного из эксплуатации сервера всё ещё что-то открывает, — куда дольше. ## Вся последовательность на одной странице Если убрать всю аргументацию, миграция хостинга — это девять шагов, и срочность есть только у двух из них: - **За два дня:** снизьте DNS TTL до 300 секунд. - **За два дня:** закажите и защитите сервер назначения, версия в версию повторяя старый стек. - **За несколько дней:** составьте опись — cron, секреты, TLS, почтовые ключи, медиа, белые списки IP, пакеты. - **За несколько дней:** выполните первую полную копию данных, напрямую между хостами. - **До окна:** выпустите сертификат через DNS-01 и проверьте всё через --resolve. - **Окно (минуты):** заморозьте запись, отключите старый cron, выполните дельта-копирование и финальный дамп, запустите новое приложение. - **Окно (секунды):** смените запись A, затем включите cron на новом хосте. - **Следующая неделя:** держите старый сервер живым как путь отката, следите за обоими логами, затем снова поднимите TTL. - **После этого:** смените секреты, зачистите диск, отмените услугу — и помните о том, чего переезд стереть не мог. В этом списке нет ничего сложного. Каждый болезненный шаг — это шаг, сделанный не по порядку: TTL, сниженный в ночь переключения, сертификат, выпущенный после смены DNS, cron-задача, оставленная активной на машине, которая больше не авторитетна. Выстройте порядок правильно — и самой интересной частью миграции станет выбор, куда поставить сервер, а не сам переезд. Если вы ещё не определились с этим, начните с [гайда по юрисдикциям](https://servhidden.com/ru/guides/choosing-an-offshore-jurisdiction). FAQ ## Миграция хостинга — частые вопросы ### 01 Сколько простоя стоит реально ожидать? Для статического сайта — вообще никакого: оба сервера могут одновременно отдавать один и тот же контент, поэтому смена DNS проходит незаметно. Для всего, что использует базу данных, простой равен ровно длине заморозки записи — обычно от двух до десяти минут, если вы заранее уже сделали полную копию данных. Важна не скорость переключения DNS, а то, сколько вы копируете прямо в окне обслуживания. Скопируйте почти всё заранее, за несколько дней, — и окно сожмётся до размера дельты. ### 02 Сколько времени занимает распространение DNS? Никакого распространения на самом деле нет — это слово описывает то, чего не происходит. Резолверы просто кэшируют вашу запись ровно на срок, указанный в TTL, и запрашивают её снова, когда этот срок истекает. Если действующий TTL был равен 86400, часть резолверов будет отдавать старый IP ещё 24 часа. Снизьте TTL до 300 секунд минимум за один полный период старого TTL до переключения — и весь интернет подтянет ваше изменение в течение пяти минут. ### 03 Обязательно ли переносить ещё и домен? Нет. Регистратор и хостинг совершенно независимы друг от друга, и перенос сайта с оставлением домена ровно там, где он был, работает прекрасно. Стоит ли переносить и его, зависит от причины миграции: если это юрисдикция, цена или позиция по DMCA, оставьте домен в покое. Если это анонимность, учтите, что у домена есть собственная, отдельная история — архивы WHOIS хранят те данные, с которыми он был зарегистрирован впервые, и смена хостинга этого никак не касается. ### 04 Можно ли перенести сайт так, чтобы старый хостер не узнал, куда я переехал? Нет, если копировать напрямую между двумя машинами — одна сторона подключается к другой, и это фиксируют оба лога доступа. Если эта связь действительно важна для вашей модели угроз, не копируйте напрямую вообще: разверните новый сервер из собственного зашифрованного бэкапа, хранящегося отдельно, — тогда провайдеры вообще не обменяются ни одним пакетом. В любом случае никогда не инициируйте передачу с подключения, которое вас идентифицирует, и не упоминайте адрес назначения ни в одном тикете в поддержку старого провайдера. ### 05 Стоит ли заодно обновить ОС или весь стек? Нет, и это самая частая самостоятельно устроенная причина провала миграции. Меняйте одну вещь за раз. Если после переключения сайт ведёт себя не так, вам нужно единственное объяснение-кандидат, а не выбор между новой машиной, новой версией PHP и новой мажорной версией базы данных. Повторите старое окружение версия в версию, завершите перенос, убедитесь в неделе чистых логов, а затем обновляйте стек отдельно, с возможностью откатиться. ### 06 Испортит ли миграция позиции сайта в поиске? Заметно — нет, при условии что домен, URL-адреса и контент остаются теми же: Google индексирует URL, а не IP-адреса, и сама по себе смена хостинга не является сигналом ранжирования. Сохраните структуру URL без изменений, возвращайте те же коды состояния и не совмещайте переезд с редизайном или сменой схемы URL. Если же вы переезжаете ещё и на новый домен, ждите временной просадки даже при корректных редиректах 301, и учтите, что эти редиректы заодно публично свяжут два имени между собой. ### 07 Нужно ли перевыпускать TLS-сертификаты? Да — новому серверу нужны собственные сертификат и приватный ключ, а перенос старого ключа на новый сервер — плохая привычка, даже если технически она работает. Выпустите сертификат до переключения через проверку DNS-01: она проходит через TXT-запись и потому срабатывает, пока запись A ещё указывает на старый хост. Если дожидаться проверки HTTP-01 после смены DNS, вы гарантированно получите полосу предупреждений о сертификате ровно в том окне, которое пытались защитить. ### 08 Когда старый сервер безопасно отменять? После недели-двух тишины в логах старой машины и чистых логов на новой — эта задержка и есть ваш путь отката, а стоит она несколько долларов. Прежде чем отменять, проверьте, что ничто внешнее больше не указывает на старый IP, смените все секреты, когда-либо жившие на этом сервере, затем удалите данные и перезапишите свободное место. Отмену — в самом конце. Если сначала нажать «завершить», ваша база данных останется на диске, который вы больше не контролируете. Похожие руководства ## Читайте также [### Как выбрать офшорную юрисдикцию для хостинга в 2026 году Перед покупкой Практическая система принятия решений при выборе офшорной юрисдикции: законы о хранении данных, MLAT-риски, позиция по DMCA, скорость судебных решений и реальная практика правоприменения — по каждой стране. FAQ из 6 вопросов](https://servhidden.com/ru/guides/choosing-an-offshore-jurisdiction) [### VPS против выделенного сервера для задач с требованиями к конфиденциальности Перед покупкой Когда VPS достаточен, когда общая аренда становится уязвимостью, а когда bare metal — единственный честный ответ. Аппаратная изоляция, риски гипервизора и соотношение цены и модели угроз. FAQ из 6 вопросов](https://servhidden.com/ru/guides/vps-vs-dedicated-for-privacy) [### Собственный VPN на VPS без KYC: WireGuard против OpenVPN Эксплуатация Почему собственный VPN превосходит коммерческих провайдеров, и как WireGuard и OpenVPN реально сравниваются по конфиденциальности, производительности и операционным рискам в 2026 году. FAQ из 6 вопросов](https://servhidden.com/ru/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 для AI-инференса (и где помещается RTX 5090) Перед покупкой Руководство по выбору GPU: какая NVIDIA GPU подходит для self-хостируемых LLM, изображений, видео, голоса и файнтюнинга в 2026 году. RTX 4090 vs RTX 5090 vs H100 SXM5 vs двойной H100 — VRAM, пропускная способность, $/токен, когда каждый из них выигрывает. FAQ из 6 вопросов](https://servhidden.com/ru/guides/rtx-4090-vs-h100-for-ai-inference) [### Офшорный Windows RDP для форекс-трейдинга MT4 / MT5 / cTrader Эксплуатация Полное руководство: зачем нужен Windows RDP для форекс-трейдинга, как выбрать офшорную юрисдикцию с низкой латентностью, настройка MT4 / MT5 / cTrader / Expert Advisor, латентность до брокерских серверов и путь no-KYC чекаута. FAQ из 6 вопросов](https://servhidden.com/ru/guides/offshore-windows-rdp-for-forex-trading) [### Хостинг с игнорированием DMCA: что это реально означает в 2026 году Перед покупкой Что на самом деле даёт хостинг с «игнорированием DMCA», какие юрисдикции действительно его поддерживают, для каких задач он нужен и какие авторско-правовые ловушки этот термин не покрывает. FAQ из 6 вопросов](https://servhidden.com/ru/guides/dmca-ignored-hosting-explained) [### Анонимная регистрация домена за криптовалюту: WHOIS-приватность в 2026 году Конфиденциальность Практическое руководство 2026 года по регистрации доменов без раскрытия личности: режимы WHOIS по TLD, выбор регистратора, варианты оплаты криптовалютой и операционные ошибки, которые всё равно вас раскроют. FAQ из 6 вопросов](https://servhidden.com/ru/guides/anonymous-domain-registration-with-crypto) [### Криптоплатежи за хостинг: Monero против Bitcoin против USDT Конфиденциальность Как выбор монеты влияет на то, что провайдер узнаёт о вас. Конфиденциальность, комиссии, финальность и уязвимость к анализу блокчейна для XMR, BTC и USDT — с чёткой рекомендацией. FAQ из 6 вопросов](https://servhidden.com/ru/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Действительно ли офшорный хостинг анонимен? Честный ответ Конфиденциальность Офшорный хостинг без KYC избавляет от идентификации, которую собирает обычный провайдер, — но «анонимность» зависит от способа оплаты, логирования у провайдера и Вашей собственной opsec-дисциплины. Вот что на самом деле можно отследить. FAQ из 6 вопросов](https://servhidden.com/ru/guides/is-offshore-hosting-truly-anonymous) [### Первый час защиты VPS: чек-лист Эксплуатация Конкретный, последовательный чек-лист для защиты нового VPS менее чем за час: SSH-ключи, файрвол, fail2ban, автоматические обновления и сокращение поверхности атаки, которое останавливает большинство оппортунистических атак. FAQ из 6 вопросов](https://servhidden.com/ru/guides/first-hour-vps-hardening-checklist) [### Что такое хостинг без KYC? Определение, законность и принцип работы Конфиденциальность Хостинг без KYC позволяет арендовать сервер без какой-либо проверки личности — без имени, электронной почты и документов. Здесь подробно объясняется, что это означает, как работает технически, законно ли это и как выбрать надёжного провайдера. FAQ из 6 вопросов](https://servhidden.com/ru/guides/what-is-no-kyc-hosting) [### Законен ли офшорный хостинг? Честный ответ 2026 года Перед покупкой Офшорный хостинг законен — и для вас, и для провайдера. Разбираемся, что на самом деле означает этот термин, где проходит настоящая правовая граница, какие мифы стоит отбросить и как пользоваться им ответственно. FAQ из 6 вопросов](https://servhidden.com/ru/guides/is-offshore-hosting-legal) [### Как оплатить хостинг через Monero (XMR) — пошаговое руководство Конфиденциальность Пошаговое руководство по оплате VPS или выделенного сервера с помощью Monero (XMR): почему XMR — наиболее приватный вариант, как его приобрести и как работает оформление заказа — от выставления счёта до запуска сервера за считанные минуты. FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-pay-for-hosting-with-monero) [### Как анонимно разместить сайт — практическое руководство 2026 Конфиденциальность Практическое многоуровневое руководство по размещению сайта без привязки к личности: аккаунт, оплата, домен, юрисдикция, подключение и контент — каждый уровень разобран отдельно. FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-host-a-website-anonymously) [### Как настроить WireGuard VPN на VPS — пошаговое руководство Эксплуатация Создайте собственный приватный VPN на VPS с помощью WireGuard: почему самостоятельный хостинг надёжнее коммерческих решений, полная инструкция от установки до подключения клиента, а также советы по укреплению безопасности. FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Как самостоятельно разместить LLM на GPU-сервере — руководство 2026 года Эксплуатация Запустите собственную большую языковую модель на арендованном GPU-сервере: почему самостоятельный хостинг превосходит API, какой GPU и модель выбрать, настройка с Ollama или vLLM и стоимость. FAQ из 6 вопросов](https://servhidden.com/ru/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof-хостинг против офшорного хостинга — в чём разница? Перед покупкой Bulletproof-хостинг и офшорный хостинг постоянно путают — но это совершенно разные вещи. Здесь объясняется реальная разница, почему это важно и что именно вам нужно. FAQ из 6 вопросов](https://servhidden.com/ru/guides/bulletproof-vs-offshore-hosting) [### Как купить VPS за Bitcoin — пошаговая инструкция (2026) Перед покупкой Понятное руководство для начинающих: как купить VPS за Bitcoin — получить BTC, выбрать тариф, оплатить счёт и запустить сервер без банковской карты и без привязки личных данных. FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-buy-a-vps-with-bitcoin) [### Лучшие страны для хостинга, игнорирующего DMCA, в 2026 году Перед покупкой Где размещать серверы, недосягаемые для американских требований о снятии контента: юрисдикции, которые реально работают, что на самом деле означает «игнорирование DMCA» и как сделать правильный выбор. FAQ из 6 вопросов](https://servhidden.com/ru/guides/best-countries-for-dmca-ignored-hosting) [### Как разместить скрытый сервис Tor (сайт .onion) — руководство 2026 года Эксплуатация Настройте onion-сервис Tor на VPS: что такое скрытый сервис, почему это наиболее надёжная форма анонимного хостинга, полная инструкция по настройке и способы сохранить реальную анонимность. FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-host-a-tor-hidden-service) [### Настройка офшорного почтового сервера — самостоятельный хостинг частной почты в 2026 году Эксплуатация Запустите собственный приватный почтовый сервер на офшорном VPS: зачем переходить на самостоятельный хостинг, что для этого нужно, практическая настройка с готовым почтовым стеком и как обеспечить доставляемость писем. FAQ из 6 вопросов](https://servhidden.com/ru/guides/offshore-mail-server-setup) [### Руководство по хостингу криптонод — запустите блокчейн-ноду на VPS Эксплуатация Как разместить блокчейн-ноду на сервере: зачем запускать собственную ноду, как подобрать конфигурацию для Bitcoin, Ethereum, Monero и других сетей, настройка и обеспечение конфиденциальности. FAQ из 6 вопросов](https://servhidden.com/ru/guides/crypto-node-hosting-guide) [### GPU-хостинг для Stable Diffusion — запустите собственный сервер генерации изображений Эксплуатация Запустите Stable Diffusion на собственном GPU-сервере: зачем самостоятельно хостить генерацию изображений, какой GPU выбрать, как настроить веб-интерфейс и во сколько это обойдётся по сравнению с облачными сервисами. FAQ из 6 вопросов](https://servhidden.com/ru/guides/gpu-hosting-for-stable-diffusion) [### OpSec сервера — Как оставаться анонимным при управлении сервером Конфиденциальность Операционная безопасность для тех, кто управляет анонимным сервером: ошибки, которые раскрывают личность, привычки, которые их предотвращают, и способы по-настоящему разделить идентичности. FAQ из 6 вопросов](https://servhidden.com/ru/guides/server-opsec-staying-anonymous) [### Руководство по настройке сидбокса — создайте собственный приватный сидбокс в 2026 году Эксплуатация Как развернуть собственный сидбокс на сервере: что такое сидбокс, как подобрать конфигурацию, установить торрент-клиент с веб-интерфейсом и обеспечить приватность и безопасность. FAQ из 6 вопросов](https://servhidden.com/ru/guides/seedbox-setup-guide) [### Как обойти DPI-цензуру с помощью собственного VPS (гайд 2026) Конфиденциальность Ваш VPN перестал работать? Как обойти DPI-цензуру с помощью собственного VPS: что на самом деле обнаруживает глубокая инспекция пакетов, какой из пяти протоколов 2026 года побеждает какую блокировку, и полное пошаговое руководство по VLESS+REALITY. FAQ из 6 вопросов](https://servhidden.com/ru/guides/bypass-dpi-censorship-with-your-own-vps) [### Полнодисковое шифрование на VPS: LUKS и что оно реально защищает Эксплуатация Как зашифровать VPS с помощью LUKS: тома данных, полное шифрование корня с удалённой разблокировкой по SSH, параметры для небольшого сервера и честный разбор того, от чего защищает шифрование диска. FAQ из 8 вопросов](https://servhidden.com/ru/guides/full-disk-encryption-on-a-vps) [### Скрытие IP исходного сервера: CDN, обратный прокси и утечки Конфиденциальность Ставить ли CDN перед офшорным сервером: что он скрывает, какой канал для жалоб вы получаете взамен, шесть способов утечки исходного IP и как проверить свой. FAQ из 8 вопросов](https://servhidden.com/ru/guides/hiding-your-origin-server-ip) [### Бэкап VPS: шифрование, второй провайдер, проверенное восстановление Эксплуатация Хостер не хранит бэкапы. Что убивает серверы, почему push-бэкап умирает вместе с сервером, restic против Borg, забытые ключи и как проверить восстановление на практике. FAQ из 8 вопросов](https://servhidden.com/ru/guides/vps-backup-strategy) [### Свой сервер Matrix: федерация, метаданные и что не скрывает E2EE Эксплуатация Что даёт свой сервер Matrix на практике: Synapse против Conduit, server_name, который нельзя изменить, диск, который съедает медиатека, и что раскрывает федерация. FAQ из 8 вопросов](https://servhidden.com/ru/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Эксплуатация Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ из 8 вопросов](https://servhidden.com/ru/guides/self-host-a-crypto-payment-gateway) ## Дайте миграции куда приземлиться Офшорные KVM-серверы в семи юрисдикциях от $7.50/мес, с полным root-доступом, накопителями NVMe и безлимитным трафиком, разворачиваются менее чем за пять минут после подтверждения криптоплатежа. Поднимите сервер назначения заранее, копируйте данные в своём темпе и переключайтесь, когда всё готово. [Тарифы VPS](https://servhidden.com/ru/vps) [Офшорный хостинг](https://servhidden.com/ru/offshore-hosting) [Все локации](https://servhidden.com/ru/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "Офшорные VPS и выделенные серверы в 7 юрисдикциях. Без KYC, без логов, только криптовалюта. Приватность — не функция, а архитектура.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Как перенести сайт на офшорный хостинг без простоя", "description": "Порядок, который делает миграцию хостинга скучной: снизьте DNS TTL заранее, держите оба сервера параллельно, замораживайте запись на минуты, а не часы, — и подчистите след из пассивного DNS, Certificate Transparency и WHOIS, который оставляет переезд.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "ru", "keywords": "перенос сайта на офшорный хостинг, смена хостинга без простоя, миграция сервера без даунтайма, перенос VPS на новый хостинг, DNS TTL при переезде сайта, переезд на хостинг без KYC, чек-лист миграции сайта, миграция сервера через rsync", "articleSection": "Эксплуатация", "wordCount": 3446 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Сколько простоя стоит реально ожидать?", "acceptedAnswer": { "@type": "Answer", "text": "Для статического сайта — вообще никакого: оба сервера могут одновременно отдавать один и тот же контент, поэтому смена DNS проходит незаметно. Для всего, что использует базу данных, простой равен ровно длине заморозки записи — обычно от двух до десяти минут, если вы заранее уже сделали полную копию данных. Важна не скорость переключения DNS, а то, сколько вы копируете прямо в окне обслуживания. Скопируйте почти всё заранее, за несколько дней, — и окно сожмётся до размера дельты." } }, { "@type": "Question", "name": "Сколько времени занимает распространение DNS?", "acceptedAnswer": { "@type": "Answer", "text": "Никакого распространения на самом деле нет — это слово описывает то, чего не происходит. Резолверы просто кэшируют вашу запись ровно на срок, указанный в TTL, и запрашивают её снова, когда этот срок истекает. Если действующий TTL был равен 86400, часть резолверов будет отдавать старый IP ещё 24 часа. Снизьте TTL до 300 секунд минимум за один полный период старого TTL до переключения — и весь интернет подтянет ваше изменение в течение пяти минут." } }, { "@type": "Question", "name": "Обязательно ли переносить ещё и домен?", "acceptedAnswer": { "@type": "Answer", "text": "Нет. Регистратор и хостинг совершенно независимы друг от друга, и перенос сайта с оставлением домена ровно там, где он был, работает прекрасно. Стоит ли переносить и его, зависит от причины миграции: если это юрисдикция, цена или позиция по DMCA, оставьте домен в покое. Если это анонимность, учтите, что у домена есть собственная, отдельная история — архивы WHOIS хранят те данные, с которыми он был зарегистрирован впервые, и смена хостинга этого никак не касается." } }, { "@type": "Question", "name": "Можно ли перенести сайт так, чтобы старый хостер не узнал, куда я переехал?", "acceptedAnswer": { "@type": "Answer", "text": "Нет, если копировать напрямую между двумя машинами — одна сторона подключается к другой, и это фиксируют оба лога доступа. Если эта связь действительно важна для вашей модели угроз, не копируйте напрямую вообще: разверните новый сервер из собственного зашифрованного бэкапа, хранящегося отдельно, — тогда провайдеры вообще не обменяются ни одним пакетом. В любом случае никогда не инициируйте передачу с подключения, которое вас идентифицирует, и не упоминайте адрес назначения ни в одном тикете в поддержку старого провайдера." } }, { "@type": "Question", "name": "Стоит ли заодно обновить ОС или весь стек?", "acceptedAnswer": { "@type": "Answer", "text": "Нет, и это самая частая самостоятельно устроенная причина провала миграции. Меняйте одну вещь за раз. Если после переключения сайт ведёт себя не так, вам нужно единственное объяснение-кандидат, а не выбор между новой машиной, новой версией PHP и новой мажорной версией базы данных. Повторите старое окружение версия в версию, завершите перенос, убедитесь в неделе чистых логов, а затем обновляйте стек отдельно, с возможностью откатиться." } }, { "@type": "Question", "name": "Испортит ли миграция позиции сайта в поиске?", "acceptedAnswer": { "@type": "Answer", "text": "Заметно — нет, при условии что домен, URL-адреса и контент остаются теми же: Google индексирует URL, а не IP-адреса, и сама по себе смена хостинга не является сигналом ранжирования. Сохраните структуру URL без изменений, возвращайте те же коды состояния и не совмещайте переезд с редизайном или сменой схемы URL. Если же вы переезжаете ещё и на новый домен, ждите временной просадки даже при корректных редиректах 301, и учтите, что эти редиректы заодно публично свяжут два имени между собой." } }, { "@type": "Question", "name": "Нужно ли перевыпускать TLS-сертификаты?", "acceptedAnswer": { "@type": "Answer", "text": "Да — новому серверу нужны собственные сертификат и приватный ключ, а перенос старого ключа на новый сервер — плохая привычка, даже если технически она работает. Выпустите сертификат до переключения через проверку DNS-01: она проходит через TXT-запись и потому срабатывает, пока запись A ещё указывает на старый хост. Если дожидаться проверки HTTP-01 после смены DNS, вы гарантированно получите полосу предупреждений о сертификате ровно в том окне, которое пытались защитить." } }, { "@type": "Question", "name": "Когда старый сервер безопасно отменять?", "acceptedAnswer": { "@type": "Answer", "text": "После недели-двух тишины в логах старой машины и чистых логов на новой — эта задержка и есть ваш путь отката, а стоит она несколько долларов. Прежде чем отменять, проверьте, что ничто внешнее больше не указывает на старый IP, смените все секреты, когда-либо жившие на этом сервере, затем удалите данные и перезапишите свободное место. Отмену — в самом конце. Если сначала нажать «завершить», ваша база данных останется на диске, который вы больше не контролируете." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Главная", "item": "https://servhidden.com/ru/" }, { "@type": "ListItem", "position": 2, "name": "Руководства по приватному хостингу", "item": "https://servhidden.com/ru/guides" }, { "@type": "ListItem", "position": 3, "name": "Как перенести сайт на офшорный хостинг без простоя", "item": "https://servhidden.com/ru/guides/migrate-website-to-offshore-hosting" } ] } ```