Как перенести сайт с Cloudflare на российскую CDN: пошаговая инструкция без даунтайма

Переезд с Cloudflare на российского провайдера — это перенос четырёх независимых функций: DNS-зоны, CDN-кеширования, WAF с правилами файрвола и TLS-сертификатов. При правильном порядке действий сайт не уходит в даунтайм ни на секунду. Вы поднимаете конфигурацию у нового провайдера параллельно с работающей, проверяете её через файл hosts и только потом переключаете DNS.

Ниже — карта соответствия функций Cloudflare российским аналогам, пошаговый план переключения и разбор того, что вы всё-таки потеряете при переезде.

Что происходит с Cloudflare в России

С 9 июня 2025 года доступ российских пользователей к сайтам на Cloudflare ограничивается на уровне сетевой инфраструктуры операторов. Cloudflare публично подтвердила это в своём блоге 26 июня 2025 года.

Механика ограничения

По описанию самой Cloudflare, соединение не блокируется целиком. Передача данных обрывается после первых 16 КБ содержимого. Это примерно 10–14 пакетов, в зависимости от используемых технологий.

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

Ограничение затрагивает все протоколы: HTTP/1.1 и HTTP/2 поверх TCP и TLS, а также HTTP/3 поверх QUIC. Технически это реализуется двумя способами: инъекцией пакетов, обрывающих соединение, и блокировкой пакетов, из-за которой соединение уходит в таймаут.

Cloudflare называет операторов, у которых ограничение подтверждено: Ростелеком, Мегафон, Вымпелком, МТС и МГТС. То есть речь идёт о магистральных и мобильных сетях, через которые проходит подавляющая часть российского трафика.

Почему это нельзя обойти настройками

Ключевой момент, который часто пытаются оспорить: проблема не на стороне вашей конфигурации и не решается в панели Cloudflare.

• Это не блокировка по домену или IP — под ограничение попадает трафик к сетям Cloudflare как таковой, независимо от того, какой сайт за ними стоит.
• Смена тарифа, региона, настроек кеширования или отключение проксирования отдельных записей ситуацию не меняют.
• Переход на HTTP/3 не помогает, так как QUIC затронут наравне с TCP.

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

По оценкам, приводившимся в отраслевых публикациях, Cloudflare использовали более 40% сайтов рунета — порядка 300 тысяч ресурсов. Масштаб задачи миграции для рынка соответствующий.

Как проверить, затронут ли ваш сайт

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

Признак первый: обрыв на 16 КБ. Ключевой симптом — ответ приходит не целиком. Скачайте страницу и посмотрите, сколько байт реально дошло:

curl -sS -o /tmp/page.html -w "получено байт: %{size_download}\nкод: %{http_code}\nвремя: %{time_total}\n" https://example.ru/

Если size_download стабильно останавливается около 16 384 байт при том, что страница заведомо тяжелее, а код ответа при этом 200 — вы видите ровно то ограничение, о котором пишет Cloudflare. Повторите запрос несколько раз: обрыв на одной и той же границе при разных попытках отличает ограничение от случайной сетевой ошибки.

Признак второй: обрыв соединения или таймаут. Второй способ реализации — блокирующие пакеты, из-за которых соединение уходит в таймаут. В выводе curl -v это выглядит как остановка после установки TLS-сессии, без получения тела ответа.

Признак третий: расхождение между протоколами отсутствует. Проверьте отдельно HTTP/2 и HTTP/3 — если поведение одинаковое, это подтверждает сетевую природу ограничения, а не проблему конкретного протокола:

curl -sS --http2 -o /dev/null -w "h2: %{size_download} байт\n" https://example.ru/
curl -sS --http3 -o /dev/null -w "h3: %{size_download} байт\n" https://example.ru/

Признак четвёртый: проверка, что вы вообще на Cloudflare. Очевидный шаг, который часто пропускают, — убедиться, что домен проксируется, а не просто использует Cloudflare как DNS:

curl -sSI https://example.ru/ | grep -i -E "server|cf-ray"

Наличие заголовка cf-ray означает, что трафик идёт через сеть Cloudflare. Если его нет, а записи в панели помечены «серым облаком», ваш сайт отдаётся напрямую с origin, и ограничение вас не касается — но и защиты у вас нет.

Замер стоит зафиксировать письменно с датой, оператором и регионом — он понадобится как аргумент при согласовании бюджета на переезд и как база сравнения после миграции.

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

Другие причины перейти на российского провайдера

Даже если оставить вопрос связности за скобками, у переезда есть основания, которые никуда не денутся.

Локализация персональных данных. Требование 152-ФЗ обязывает хранить и обрабатывать персональные данные российских граждан на серверах в России. CDN хоть и не хранит данные, но видит содержимое запросов и логирует их. Юридическая оценка того, считается ли это обработкой, зависит от конкретной конфигурации, но однозначно проще, когда узлы и логи физически находятся в российской юрисдикции.

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

Техподдержка на русском и в вашем часовом поясе. На бесплатном и начальных тарифах Cloudflare поддержка сводится к базе знаний и форуму. Инцидент в 3 часа ночи по Москве вы разбираете сами.

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

Что вы потеряете при переезде

В этом рахделе разберём риски, чтобы вы могли принять решение, основываясь на полных данных.

Cloudflare Workers — Serverless-исполнение JavaScript на границе сети. Если у вас на Workers написаны редиректы, A/B-тесты, сборка ответов, проксирование к нескольким бэкендам, прямого аналога «один в один» на российском рынке нет. Часть сценариев можно закрыть правилами у российских провайдеров, но часть всё-таки придётся вернуть на бэкенд.

R2, KV, Durable Objects, D1 — Экосистема хранилищ и состояния вокруг Workers. Объектное хранилище с S3-совместимым API у российских провайдеров есть, а вто остального нет.

Zero Trust и WARP — корпоративный доступ, туннели, замена VPN. Это отдельный класс продуктов, и заменяется он не CDN-провайдером, а отдельными решениями.

Глобальная сеть. Если у вас значимая аудитория за пределами России и СНГ, покрытие российского провайдера будет уже. Здесь возможен вариант с двумя провайдерами: российский для российской аудитории, зарубежный для остальной.

Бесплатный тариф. У Cloudflare он щедрый. Российские провайдеры в основном работают по платным моделям, хотя стартовые тарифы для небольших проектов вполне подъёмные.

Если вы использовали Cloudflare как DNS плюс CDN плюс базовый WAF (а так его использует подавляющее большинство), вы легко сможете полностью мигрировать на отечественное решение. Если вы построили на Workers часть продуктовой логики, миграция превратится в проект с разработкой.

Карта соответствия: что чем заменить

Подготовка: что собрать до начала

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

1. Полный экспорт DNS-зоны. В панели Cloudflare выгрузите зону в формате BIND. Это единственный надёжный способ не потерять записи. Отдельно проверьте:

• MX-записи и почтовые TXT: SPF, DKIM, DMARC. Потеря любой из них означает, что почта перестанет доставляться или начнёт уходить в спам.
• TXT-записи верификации внешних сервисов: Яндекс.Вебмастер, Google Search Console, платёжные системы, почтовые провайдеры.
• Поддомены, о которых все забыли: old., test., mail., ftp., vpn..
• Записи, которые не проксируются («серое облако») — они указывают напрямую на IP, и эти адреса уже публичны.

2. Список правил. Page Rules, Configuration Rules, Cache Rules, Firewall Rules, Rate Limiting. Сохраните скриншотами или через API — после отключения аккаунта восстановить логику будет неоткуда.

3. Инвентаризация того, что реально используется. Частая находка: из 15 включённых функций фактически работают четыре. Не переносите то, что не нужно.

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

5. Определите, где сейчас сервер-источник и открыт ли он. Узнайте реальный IP своего сервера и проверьте, отвечает ли он на прямые запросы. После миграции его нужно будет закрыть.

Пошаговая миграция без даунтайма

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

Шаг 1. За 24–48 часов до переключения снизьте TTL DNS-записей до 300 секунд в панели Cloudflare. Это сократит окно, в течение которого часть пользователей будет ходить по старым адресам, и обеспечит быстрый откат.

Шаг 2. Создайте DNS-зону у нового провайдера и импортируйте выгруженный BIND-файл. На этом этапе не меняйте NS-серверы у регистратора. Зона будет просто существовать параллельно.

Шаг 3. Сверьте записи построчно. Импорт часто требует правки: проксируемые записи Cloudflare в экспорте указывают на его IP-адреса, а не на ваш origin. Замените их на реальные адреса сервера или на CNAME нового CDN-ресурса.

Шаг 4. Создайте CDN-ресурс у нового провайдера. Перенесите логику Page Rules и Cache Rules в правила кеширования.

Шаг 5. Выпустите TLS-сертификат на стороне нового провайдера. Убедитесь, что настроено автопродление.

Шаг 6. Настройте WAF в режиме мониторинга. Но только именно в мониторинге. Правила должны накопить статистику до того, как начнут что-то резать.

Шаг 7. Протестируйте через файл hosts. Пропишите у себя на машине соответствие домена IP-адресу нового CDN-ресурса и пройдите сайт целиком: главная, каталог, карточка товара, корзина, оформление заказа, личный кабинет, формы, загрузка файлов, платежи. Проверьте и мобильную версию. До этого шага в продакшене ничего не изменилось — откат бесплатный.

Шаг 8. Отключите DNSSEC, если он был включён в Cloudflare. Обязательный шаг: если DS-запись у регистратора останется от старого провайдера, а зону начнёт обслуживать новый, домен станет недоступен. Дождитесь распространения отключения, обычно это занимает несколько часов.

Шаг 9. Смените NS-серверы у регистратора на серверы нового провайдера. С этого момента начинается переходный период: часть резолверов ещё отдаёт старые данные, часть уже новые. Оба варианта должны работать — поэтому старую конфигурацию не трогаем.

Шаг 10. Наблюдайте 24–48 часов. Проверяйте доступность, ошибки в логах, доставку почты, работу форм.

Шаг 11. Закройте сервер-источник новым файрволом. Если IP уже засветился, смените его.

Шаг 12. Верните нормальный TTL (обычно 3600 секунд), включите DNSSEC у нового провайдера, переведите WAF из мониторинга в блокировку. Аккаунт Cloudflare отключайте последним, не раньше чем через две недели.

Как перенести правила WAF

Это часть миграции, которую нельзя автоматизировать, и главный источник инцидентов.

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

1. Разберите текущие правила на категории. Обычно набор сводится к блокировкам по странам и известным вредоносным IP, защите админки, ограничению частоты запросов к формам и API. Ещё могут быть антипарсинговые правила и правила под конкретные прошлые атаки.
2. Выкиньте то, что писалось под разовый инцидент двухлетней давности. Такие правила есть почти всегда и живут годами без причины.
3. Соберите всё заново на новом WAF, начиная с преднастроенного набора OWASP в режиме мониторинга.
4. Неделю смотрите на срабатывания. Ложные срабатывания на этом этапе видны, но никому не вредят.
5. Точечно исключайте легитимные сценарии, которые попали под правила: загрузка файлов, редактор контента, интеграции по API, вебхуки платёжных систем.
6. Включайте блокировку по одной категории, а не всё сразу.

Отдельно про бот-менеджмент: не включайте агрессивный режим одновременно с переездом. Иначе при падении конверсии вы не поймёте, дело в миграции или в фильтрации живых пользователей. Разнесите эти изменения хотя бы на неделю.

Что делать с Cloudflare Workers

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

Группа 1 — переносится на правила CDN. Редиректы, переписывание URL, добавление и удаление заголовков, блокировка по условиям, простая маршрутизация на разные источники — всё это есть в правилах у российских провайдеров.

Группа 2 — возвращается на бэкенд: сборка ответа из нескольких источников, работа с внешними API, обработка вебхуков, генерация контента. Технически это код, который когда-то вынесли на CDN ради скорости. Возврат на бэкенд добавит задержку, но работоспособность сохранит.

Группа 3 — требует отдельного решения. Логика, которая принципиально должна выполняться близко к пользователю и не может ждать обращения к серверу. Здесь нужна индивидуальная оценка: иногда задача решается serverless-функциями у российского облачного провайдера, иногда переосмысливается архитектурно.

Начните с инвентаризации Workers по этим трём группам до начала миграции. Это позволит точно понять трудозатраты и избавит от сюрпризов на середине проекта.

Чек-лист проверки после переезда

Пройдите по списку через сутки после смены NS и повторно через неделю.

Доступность и связность:

• Сайт открывается с мобильного интернета МТС, Мегафон, Билайн, Теле2
• Сайт открывается из нескольких регионов, не только из Москвы
• Страницы загружаются целиком, а не первые 16 КБ
• Работает HTTPS, сертификат валиден, автопродление настроено
• Нет смешанного контента, в консоли браузера чисто

DNS и почта:

• dig NS example.ru возвращает новые серверы
• MX-записи на месте, тестовое письмо доходит
• SPF, DKIM, DMARC перенесены, письма не помечаются как спам
• TXT-верификации Яндекс.Вебмастера и Search Console не слетели
• Все поддомены резолвятся
• DNSSEC либо корректно включён у нового провайдера, либо выключен целиком

CDN и кеш:

• curl -I показывает заголовки нового провайдера и признак попадания в кэш
• Cache hit ratio растёт и выходит на 85–90% по статике
• Личный кабинет и корзина не кэшируются
• Инвалидация кэша работает и встроена в процесс деплоя

Функциональность:

• Формы отправляются, вебхуки платёжной системы приходят
• Загрузка файлов работает
• Интеграции по API отвечают
• Админка доступна, редактор контента не блокируется WAF

Безопасность и SEO:

• Origin закрыт файрволом, прямой доступ по IP не проходит
• WAF в мониторинге, ложные срабатывания разобраны
• robots.txt и sitemap.xml отдаются корректно
• В Search Console и Вебмастере нет всплеска ошибок сканирования
• Время ответа сервера в отчётах поисковых систем не выросло

Типичные ошибки

1. Забыли отключить DNSSEC. Домен становится полностью недоступен после смены NS. Самая тяжёлая по последствиям ошибка и одна из самых частых.
2. Не перенесли почтовые записи. Сайт работает, а почта замолчала. Обнаруживается через день-два по жалобам.
3. Импортировали зону как есть. Проксируемые записи указывают на IP Cloudflare, которые после отключения перестанут отвечать.
4. Включили WAF сразу в режиме блокировки. Часть пользователей и поисковых роботов режется, падение трафика списывают на «переезд».
5. Оставили сервер-источник открытым. IP уже публичен, атака идёт мимо новой защиты.
6. Переключили DNS без предварительного снижения TTL. Откат при проблеме растягивается на сутки.
7. Отключили аккаунт Cloudflare сразу после переключения. Пути к отступлению не остаётся, а часть резолверов ещё ходит по старым данным.
8. Не проверили с мобильных сетей. С офисного проводного интернета всё открывается, у клиентов — нет.

Часто задаваемые вопросы

Заблокирован ли Cloudflare в России? Формально это не блокировка. С 9 июня 2025 года при обращении к сайтам за Cloudflare передаются только первые 16 КБ содержимого, после чего соединение обрывается. Сайт при этом выглядит недоступным для пользователя, хотя сам сервис не находится в реестре блокировок. Cloudflare подтвердила ограничения официально и заявила, что решить проблему на своей стороне не может.

Можно ли обойти ограничение настройками Cloudflare? Нет. Ограничение действует на уровне сетевой инфраструктуры операторов и затрагивает трафик к сетям Cloudflare независимо от домена, тарифа и настроек. Смена региона, отключение проксирования отдельных записей или переход на HTTP/3 результата не дают, QUIC затронут наравне с TCP.

Сколько времени занимает переезд с Cloudflare? Для типового сайта с DNS, CDN и базовым WAF — от одного до трёх рабочих дней подготовки плюс сутки-двое наблюдения после переключения. Если использовались Workers с продуктовой логикой, срок определяется объёмом переписывания кода и оценивается отдельно.

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

Что будет с SEO при смене CDN? При корректном переносе — ничего. URL не меняются, содержимое не меняется, редиректы не появляются. Риски возникают только при ошибках: недоступность во время переключения, слетевшая верификация в вебмастерах, блокировка поисковых роботов новым WAF. Всё это закрывается чек-листом проверки.

Нужно ли менять что-то в коде сайта? Нет, если вы переносите домен целиком. Меняются только DNS-записи и настройки на стороне провайдера. Правки в коде нужны в двух случаях: если статика была вынесена на отдельный поддомен и меняется его адрес, и если использовались Workers.

Как перенести правила WAF из Cloudflare? Автоматического переноса не существует, языки правил у вендоров разные. Правильный подход: выписать, что именно и зачем блокировалось, собрать эквивалент на новом WAF, начиная с преднастроенного набора OWASP, неделю подержать в режиме мониторинга, разобрать ложные срабатывания и только потом включить блокировку.

Есть ли аналог Cloudflare Workers? Прямого аналога Workers на российском рынке нет. Разберите свои Workers на три группы: простая логика (редиректы, заголовки, условная маршрутизация) переносится на правила edge у нового провайдера; сложная логика возвращается на бэкенд с некоторым проигрышем в задержке; оставшееся требует индивидуального решения через serverless-функции облачного провайдера.

Можно ли использовать российский CDN и Cloudflare одновременно? Да, это рабочая схема при значимой зарубежной аудитории: российские пользователи обслуживаются российским провайдером, остальные — зарубежным. Реализуется через геораспределение на уровне DNS. Схема сложнее в эксплуатации и требует поддержания двух конфигураций, но решает задачу глобального покрытия.

Нужно ли отключать DNSSEC перед переездом? Да, обязательно, если он был включён. DS-запись у регистратора привязана к ключам старого провайдера. Если сменить NS, не отключив DNSSEC, цепочка доверия разорвётся и домен станет недоступен. Порядок такой: отключить DNSSEC, дождаться распространения, сменить NS, затем включить DNSSEC у нового провайдера.