Миграция сайта между странами: что ломается и почему

MAATRIX

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

Чем межстрановой переезд отличается от обычной миграции

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

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

Дальше — пять мест, которые ломаются именно из-за смены страны, и что с ними делать до переезда, а не после.

Задержка для аудитории: мощнее сервер — не значит быстрее сайт

Самая частая ошибка при выборе новой локации — сравнивать серверы по характеристикам (CPU, RAM, NVMe) и игнорировать физическое расстояние до пользователей. Если раньше сервер стоял близко к основной аудитории, а новый — в другой части света, то каждый запрос будет идти на условные 80–150 мс дольше просто потому, что свет и электричество не мгновенны, и это никак не компенсируется более быстрым процессором.

Для статического контента это не критично — CDN сгладит разницу. Но для динамики (авторизация, формы, API-запросы, сайты на PHP/Node с серверным рендерингом) каждый round-trip до сервера складывается: TCP-хендшейк, TLS, сам HTTP-запрос — если это 3-4 последовательных запроса на загрузку страницы, разница в задержке умножается.

Порядок действий до переезда:

1. Определить, где физически находится основная масса вашей аудитории (Яндекс.Метрика / Google Analytics → география).
2. Оценить ориентировочную задержку между этой географией и новой локацией сервера — конкретные цифры зависят от маршрута и провайдера, но общий порядок величины можно прикинуть по таблице в статье «Latency между локациями: таблица ориентиров». Это именно ориентиры, а не гарантированные цифры — реальная задержка на вашем маршруте может отличаться.
3. Если рост задержки для основной аудитории неизбежен — заложить компенсацию: CDN перед сервером, кеширование на уровне Nginx/Varnish, перенос статики на edge-сеть.
4. Проверить реальную цифру уже после переезда, а не полагаться на прогноз — измерить mtr или ping с точки, географически близкой к аудитории (например, через VPS в нужном регионе или сервис вроде globalping).

Если аудитория смешанная (часть в России, часть в Европе или США), тут нет универсального ответа — выбор локации всегда компромисс, и стоит явно решить, для какой доли аудитории вы жертвуете скоростью ради других преимуществ (юрисдикция, цена, доступность оплаты).

Часовой пояс по умолчанию: тихая причина сбоев cron

Это одна из самых незаметных проблем, потому что она не мешает сайту работать — она портит расписание фоновых задач. Новый сервер у нового провайдера почти всегда разворачивается с часовым поясом по умолчанию — обычно UTC, но не всегда. Если ваши cron-задачи были написаны с расчётом на локальное время старого сервера («бэкап в 3 ночи, когда нагрузка минимальна»), то после переезда та же строчка в crontab выполнится в совершенно другое время суток.

Пример: сервер стоял в России с Europe/Moscow (UTC+3), бэкап был настроен на 03:00 — то есть фактически на 00:00 UTC. Переехали на сервер с UTC по умолчанию — та же запись 0 3 * * * теперь означает 03:00 UTC, то есть 06:00 по Москве, в самый разгар утреннего трафика. Бэкап, рассчитанный на тихие часы, теперь снимает нагрузку с диска и I/O ровно тогда, когда сайтом активно пользуются.

Проверить и синхронизировать часовой пояс:

# посмотреть текущий часовой пояс и статус синхронизации времени
timedatectl status

# список доступных зон, если нужно найти нужную
timedatectl list-timezones | grep -i moscow

# установить нужный часовой пояс явно
sudo timedatectl set-timezone Europe/Moscow

# убедиться, что NTP-синхронизация включена и работает
timedatectl set-ntp true

После смены зоны обязательно перепроверьте реальные cron-задачи — недостаточно поправить только /etc/timezone, если задачи писались с явным расчётом на конкретный локальный час:

crontab -l
sudo crontab -l -u www-data
cat /etc/cron.d/*

Универсальный совет на будущее — там, где это возможно, писать расписание в UTC явно и держать в голове смещение, а не полагаться на локальный часовой пояс сервера. Это не спасает от разового переезда, но снижает риск при следующем. Если после переезда что-то стало срабатывать не вовремя или вообще перестало — механика диагностики подробно разобрана в статье «Cron не отработал ночью: разбор тихого сбоя».

Локализация ПДн: 152-ФЗ не остаётся в прошлой стране

Если среди пользователей сайта есть граждане РФ и вы обрабатываете их персональные данные (имя, email, телефон, адрес — список широкий, см. отдельный разбор, что именно считается ПДн), то переезд сервера за рубеж не отменяет требований 152-ФЗ — он их усложняет. Закон требует, чтобы первичный сбор и запись таких данных происходили на сервере, физически находящемся в России. Если раньше сервер и так стоял в РФ, вопрос решался сам собой. После переезда за границу эта обязанность никуда не девается — просто теперь для её выполнения нужен отдельный сервер в России, на который льётся первичная запись, а зарубежный сервер может обрабатывать данные уже вторично.

Практически это означает один из вариантов:

• Держать легковесный сервер в РФ, который принимает и записывает ПДн первым (например, отдельный инстанс БД или прокси-слой перед основным приложением), и уже оттуда реплицировать/синхронизировать на зарубежный сервер.
• Оставить весь контур с ПДн в России, а за рубеж вынести только то, что персональных данных не касается (статика, кеш, аналитика в обезличенном виде).
• Если аудитория не включает граждан РФ или вы принципиально не собираете ПДн (визитка, блог без форм регистрации) — этот пункт можно не рассматривать, но стоит явно проверить, что это действительно так, а не предполагать.

Это не абстрактный риск «на будущее» — контролирующий орган смотрит именно на физическое расположение сервера первичной записи, а не на то, где физически сидит компания или где зарегистрирован домен. Подробный разбор требования и вариантов размещения — в статье «152-ФЗ: где законно держать сервер с персональными данными», а суть самого термина «локализация» — в материале «Локализация баз ПДн: что это означает».

Отдельно: если из России сервер переезжает не просто «за границу», а в конкретно ЕС/Великобританию, добавляется вторая сторона медали — уже не российское, а европейское регулирование (GDPR и аналоги) в отношении данных пользователей из ЕС. Это отдельная тема, которую тут разбирать не будем, но если ваша аудитория трансграничная — держите в уме, что требований может быть два комплекта одновременно, а не один.

Новый IP-адрес: антифрод, платёжные шлюзы и репутация

Смена сервера почти всегда означает смену IP-адреса, а IP-адрес — это не просто число в DNS-записи, это ещё и объект геолокационных и репутационных баз данных, на которые опираются внешние сервисы. Для внешнего наблюдателя (платёжного шлюза, антифрод-системы, некоторых API) ваш сайт «переехал в другую страну» будет выглядеть как всплеск подозрительной активности с нового, ранее не встречавшегося адреса — даже если содержимое сайта не изменилось ни на байт.

Конкретные проявления:

• Платёжный шлюз или банк-эквайер начинает чаще запрашивать дополнительную верификацию (3-D Secure) или прямо отклонять транзакции, потому что запрос теперь приходит с сервера в другой стране — антифрод-эвристики многих систем учитывают геолокацию источника запроса.
• Если сайт делает исходящие запросы к сторонним API (платёжным, картографическим, почтовым) — некоторые из них ограничивают доступ или тарификацию по географии исходящего IP, и лимиты могут внезапно не совпасть с ожидаемыми.
• Новый IP может оказаться «грязным» по репутации — если он раньше принадлежал другому клиенту хостинга и использовался для спама или атак, часть спам-фильтров и антифрод-баз может помнить эту историю ещё какое-то время после переезда.

Что стоит сделать заранее:

# проверить репутацию и геолокацию будущего IP до переезда
curl -s https://ipinfo.io/203.0.113.10/json

# то же самое, если нужен ответ от нескольких источников —
# geoip-базы иногда расходятся в стране/городе

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

SSL и firewall на новом провайдере: перепроверить, а не предполагать

SSL-сертификаты обычно переносятся без сюрпризов — если используется Let's Encrypt с автопродлением, сертификат просто перевыпустится на новом домене/IP при следующем цикле, а сертификат, привязанный к домену (не к IP), можно скопировать вместе с приватным ключом. Проблемы здесь редкость, но одну вещь стоит проверить: правильно ли настроен ACME-challenge (HTTP-01 или DNS-01) на новом сервере, особенно если между переключением DNS и полным пропагейтом проходит время — в этом окне продление сертификата может не пройти.

Куда чаще ломается не SSL, а firewall — просто потому, что дефолтные правила security group у разных провайдеров отличаются, и это отличие незаметно ровно до первой попытки подключиться по нужному порту:

Не полагайтесь на то, что «раз это тот же Ubuntu, то и правила такие же» — security group облачного провайдера и ufw/iptables внутри ОС — это два разных слоя, и на новом провайдере может отличаться именно внешний слой, который вы не видите, пока не попробуете подключиться. Проверьте явно:

# проверить, что реально слушает сервер
sudo ss -tulpn

# проверить локальные правила firewall
sudo ufw status verbose
sudo iptables -L -n -v

# и отдельно — правила security group / cloud firewall
# в панели управления нового провайдера, а не только на уровне ОС

Частая ошибка при спешке — открыть в security group «всё для всех», чтобы сайт заработал прямо сейчас, и забыть закрутить обратно. Как это аукается — в статье «Антипаттерн: firewall разрешить всё».

Чек-лист подготовки к межстрановому переезду

Помимо стандартного чек-листа миграции (бэкап данных, тестовый прогон на новом сервере, план отката, низкий TTL у DNS перед переключением — подробнее в «Миграция базы данных между серверами»), для переезда через границу добавьте отдельно:

• [ ] Замерить и учесть ожидаемую разницу в задержке до основной аудитории — заранее решить, нужен ли CDN или дополнительное кеширование.
• [ ] Проверить timedatectl status на новом сервере до переноса cron-задач и явно установить нужный часовой пояс, а не полагаться на дефолт.
• [ ] Выгрузить и заново проверить все cron-задачи и системные таймеры (systemd timers) на предмет привязки к конкретному локальному часу.
• [ ] Если есть пользователи-граждане РФ и обрабатываются ПДн — решить вопрос локализации первичной записи данных до переезда, а не после проверки.
• [ ] Проверить репутацию и геолокацию нового IP-адреса заранее, до переключения DNS.
• [ ] Уведомить платёжный шлюз / эквайера о смене IP-адреса источника запросов, если сайт принимает платежи.
• [ ] Сверить правила ACME-challenge для SSL на новом сервере до истечения текущего сертификата.
• [ ] Явно проверить security group / cloud firewall нового провайдера — не полагаться на то, что дефолтные правила совпадают со старым провайдером.
• [ ] После переезда — перепроверить DNS-резолвинг со стороны разных регионов: типичные грабли разобраны в статье «Проблемы с DNS после переезда».

Этот список не заменяет общий чек-лист миграции — он его дополняет теми пунктами, которые специфичны именно для смены страны.

Частые вопросы