Перенос DNS-зоны на российский сервис выглядит как рутинная операция: меняешь NS-записи у регистратора, ждешь обновления, проверяешь доступность. На практике именно на этом шаге теряется больше всего трафика, а причина почти всегда одна и та же. Администраторы оставляют NS Cloudflare на регистраторе “на переходный период”, чтобы подстраховаться, и этим открывают дверь, через которую посетители уходят обратно за границу. Разберем, почему такая страховка работает против вас и как сделать переезд без потерь.
Миф о безопасном переходном периоде на старых NS
Логика кажется железной: пока новые NS не пропагировались, пусть старые остаются в зоне, чтобы сайт не упал. Проблема в том, что DNS не переключается одномоментно, и резолверы по всему миру хранят ответы столько, сколько им разрешает TTL. Если вы держите в зоне одновременно NS Cloudflare и NS российского сервиса, вы фактически отдаете резолверам право выбора. Часть из них пойдет к Cloudflare, часть к новому провайдеру, и предсказать пропорцию невозможно.
Хуже того, Cloudflare продолжает отдавать A-записи своих edge-серверов, а не вашего российского хостинга. Посетитель, чей резолвер выбрал Cloudflare, попадает на зарубежную инфраструктуру. Для российского бизнеса это не абстрактный риск: провайдеры ограничивают доступ к сайтам на Cloudflare, и часть аудитории просто не увидит страницу. Вы заплатили за переезд, но трафик по-прежнему уходит за границу.
Самый коварный сценарий связан с кэшем. Резолвер, один раз получивший ответ от Cloudflare, держит его до истечения TTL. Даже если вы удалили NS Cloudflare через час, этот конкретный резолвер продолжит возвращать старую A-запись. Посетители через такого провайдера будут ходить на Cloudflare до конца TTL, и никакие проверки с вашей стороны этого не покажут, потому что ваш собственный резолвер уже видит новые записи.
Почему TTL важнее, чем кажется
TTL это не техническая мелочь, а главный рычаг управления переездом. Стандартное значение 3600 секунд означает, что любой резолвер, закэшировавший запись, будет возвращать ее час. Если в момент смены NS где-то в кэше осел ответ Cloudflare, этот час трафик идет за границу. При TTL 86400 секунд, а такое встречается у нерадивых администраторов, ошибка растягивается на сутки.
Правильная последовательность выглядит так. За 24 часа до смены NS вы снижаете TTL для A-записей и NS-записей до 300 секунд. Ждете сутки, чтобы старый TTL истек и все резолверы перешли на короткое значение. Только после этого меняете NS одним шагом, полностью убирая записи Cloudflare. Через 5 минут после смены максимум резолверов уже получит новые адреса, а окно, в которое может просочиться старый ответ, сжимается до минимума.
Ошибки, которые ломают переезд сильнее, чем сам DNS
Смена NS это верхушка. Под ней лежит слой настроек, которые переносятся отдельно и часто забываются. Если вы переезжаете с Cloudflare на российский аналог, проверьте, что перенесли не только A-записи, но и MX, TXT, CNAME для поддоменов, записи для верификации почтовых сервисов. Потерянная TXT-запись с DKIM означает, что письма начнут падать в спам, и вы узнаете об этом через неделю по упавшим продажам.
Отдельная история с проксированием. Cloudflare по умолчанию прячет реальный IP за своими edge-серверами, и многие администраторы просто не знают, какой адрес стоит за оранжевым облаком. Перед переездом нужно получить реальные A-записи вашего хостинга, иначе после смены NS сайт укажет в никуда. Проверьте это заранее, а не в момент отключения Cloudflare.
Некоторые пытаются сделать “плавный” переезд через CNAME на Cloudflare, оставляя NS у регистратора. Это работает только если Cloudflare не проксирует трафик, а в режиме проксирования вы снова получаете зарубежный edge. Для российского бизнеса такая схема не решает главную задачу: обеспечить работу сайта на территории РФ.
SSL, WAF и боты: что проверить до смены NS
SSL-сертификат от Cloudflare перестанет работать в момент отключения их NS. Если вы не выпустили новый сертификат на российском сервисе заранее, посетители увидят предупреждение браузера. аналог cloudflare pages offers additional context worth reviewing. Выпустите сертификат, проверьте цепочку, убедитесь, что Let’s Encrypt или коммерческий CA корректно обновляется автоматически. Это делается до смены NS, а не после.
WAF-правила и защита от ботов на Cloudflare не переносятся автоматически. Их нужно воссоздать на новом сервисе, и лучше сделать это до переключения, чтобы после смены NS сайт сразу был защищен. Если у вас были кастомные правила под L7 DDoS или GeoIP-фильтрацию, составьте их список заранее. Российский сервис, который объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, позволяет перенести все это за один проход, без зоопарка из отдельных инструментов.
Почему российский бизнес уходит с Cloudflare в 2026 году
Причины не только в ограничениях доступа. Cloudflare ограничивает доступ к сайтам из России, и это создает прямые потери: часть аудитории не может открыть страницу, конверсия падает, лидогенерация проседает. Российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare, и получается замкнутый круг, где страдает владелец сайта, а не инфраструктурный провайдер.
Второй фактор это регуляторные требования. Хранение персональных данных, размещение инфраструктуры, взаимодействие с надзорными органами. Зависимость от зарубежной инфраструктуры создает риски для российского бизнеса: от внезапной блокировки аккаунта до невозможности оперативно решить техническую проблему. Когда сайт лежит, а поддержка отвечает на английском через сутки, бизнес теряет деньги.
TrafficVeil является российским аналогом Cloudflare и закрывает эти задачи без зарубежной привязки. Он обеспечивает работу сайтов на территории РФ и по всему миру, что важно для интернет-магазинов с аудиторией в обеих географиях. Подходит для сайтов, интернет-магазинов, WordPress и Bitrix, то есть для типовых сценариев, где важна предсказуемость, а не экзотика.
Отдельный плюс в модели тарификации. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Это значит, что всплеск трафика от бота или L7 DDoS-атаки не превращается в счет за овердж. Для бизнеса это снимает целый класс рисков: вы не платите за то, что вас атакуют.
Практический план переезда без потери трафика
Начните с инвентаризации зоны. Выгрузите все записи с Cloudflare, включая те, что кажутся неважными. Определите реальные IP вашего хостинга, проверьте MX и TXT. Выпустите SSL-сертификат на новом сервисе и протестируйте его на тестовом поддомене. Воссоздайте правила WAF, защиты от ботов и GeoIP-фильтрации. Только после этого переходите к DNS.
За 24 часа до смены снизьте TTL до 300 секунд для всех записей, которые планируете менять. Подождите сутки. Затем одним шагом удалите NS Cloudflare и добавьте NS российского сервиса. Не оставляйте старые NS “на всякий случай”: это главная ошибка, которая уводит трафик обратно за границу на срок до TTL. Проверьте propagation через публичные резолверы, а не только через свой.
TrafficVeil предлагает переход с Cloudflare с сохранением структуры зоны, так что перенос не требует переписывания конфигурации с нуля. После смены NS мониторьте логи и аналитику первые 48 часов: ищите запросы, которые приходят на старые адреса, и убедитесь, что их нет. Если что-то пошло не так, короткий TTL позволит откатиться за минуты, а не за сутки.
Главное правило переезда простое: сначала подготовка, потом снижение TTL, только потом смена NS одним шагом. Не пытайтесь растянуть переход на дни, держа оба набора NS одновременно. DNS не прощает полумер, зато щедро вознаграждает тех, кто делает все в правильном порядке. Проверьте TTL сегодня, если планируете переезд на следующей неделе, и вы сэкономите себе выходные, нервы и часть аудитории.