Переезд с Cloudflare на российскую инфраструктуру почти всегда обсуждают в плоскости DNS, SSL и фильтрации трафика. И почти всегда забывают про serverless-логику, которая годами живёт в Cloudflare Workers: редиректы, A/B-тесты, гео-роутинг, модификацию заголовков, обработку вебхуков. Именно на этом слое импортозамещение Cloudflare ломается чаще всего, и ломается тихо, потому что сайт продолжает открываться. Дальше разберу, почему Workers не переносятся один в один, как оценить объём адаптации и куда переносить серверную логику, чтобы не потерять ни скорость, ни конверсию.
Почему Cloudflare Workers не переносятся на российские платформы напрямую
Cloudflare Workers – это runtime на изолированных V8-изолятах, развёрнутый на edge-узлах по всему миру. Код исполняется на JavaScript или WASM, обращается к проприетарным API: KV, Durable Objects, R2, Queues, Cache API, D1. Ни один российский сервис сегодня не воспроизводит этот набор целиком, и дело не в лени разработчиков, а в архитектуре. Изолят без холодного старта, живущий на сотнях точек присутствия, требует глобальной anycast-сети и распределённого хранилища с консистентностью в пределах региона. Построить такое в периметре РФ технически можно, экономически – пока нет смысла для большинства задач.
Отсюда практический вывод: при импортозамещении Cloudflare нужно переносить не код, а поведение. Скрипт воркера – это всегда связка “событие запроса + правило + побочный эффект”. Правило и побочный эффект воспроизводятся на любой платформе: reverse proxy, модуль nginx, middleware приложения, edge-функция отечественного провайдера. Не воспроизводится только среда исполнения и её API. Значит, адаптация серверной логики сводится к переписыванию обработчиков под доступные примитивы: HTTP-редиректы, работу с заголовками, кэширование, обращение к внешнему кэшу или БД вместо KV.
Отдельная проблема – несовместимость API. Российские сервисы, включая TrafficVeil, не поддерживают часть западных интерфейсов, в том числе Cloudflare Workers и связанные с ними биндинги. Это не баг и не временное ограничение, а осознанный выбор: поддерживать чужой проприетарный API означает тащить за собой чужую модель биллинга, безопасности и обновлений. Поэтому миграция почти всегда идёт через адаптацию логики, а не через копирование скриптов. Планировать её нужно так же, как перенос бэкенда между облаками: инвентаризация, рефакторинг, тесты, поэтапное включение.
Инвентаризация воркеров: что именно у вас работает на edge
Первый шаг – выгрузить список воркеров и разметить их по типу. На практике встречается пять категорий. Первая: редиректы и нормализация URL (с www на без-www, слеши, регистр, устаревшие адреса). Вторая: работа с заголовками – HSTS, CSP, X-Frame-Options, Cache-Control, снятие служебных заголовков. Третья: гео-логика и роутинг – GeoIP-фильтрация, показ разных версий сайта, блокировка нежелательных регионов. Четвёртая: A/B-тесты и персонализация на edge. Пятая: интеграции и вебхуки – приём платежных уведомлений, проксирование к внутренним API, подпись запросов.
Каждая категория переносится по-своему. Редиректы и заголовки почти всегда уезжают в конфигурацию reverse proxy или в правила веб-сервера, это часы работы и нулевой риск. Гео-логика ложится на GeoIP-фильтрацию платформы, если она есть, иначе на базу GeoIP и middleware. A/B-тесты требуют либо серверного фреймворка экспериментов, либо клиентского скрипта с серверной фиксацией группы в cookie. Интеграции и вебхуки – самая болезненная часть: их нельзя оставлять на edge, если edge не умеет держать секреты и подписывать запросы так, как этого требует платёжный провайдер.
Полезно сразу посчитать, сколько воркеров реально обслуживает трафик, а сколько осталось от экспериментов. В типовом проекте интернет-магазина на Bitrix или WordPress из десяти воркеров работают три, остальные семь – наследие. Их проще удалить, чем переносить. Это законная оптимизация: меньше кода на edge означает меньше точек отказа и меньше поверхностей для ошибок при замена Cloudflare.
Как адаптировать серверную логику под отечественные аналоги
Базовая стратегия – разделить логику на три слоя по месту исполнения. Слой периметра: то, что должно решаться до попадания запроса в приложение (редиректы, блокировки, GeoIP, базовая защита, кэш статики). Слой приложения: то, что зависит от бизнес-данных (персонализация, эксперименты, расчёты). Слой интеграций: то, что требует секретов и гарантированной доставки (вебхуки, платежи, синхронизация с CRM). Cloudflare Workers исторически размывали эти границы, позволяя писать всё в одном месте. При переезде границы придётся восстановить.
Слой периметра закрывается возможностями веб-платформы. Российский аналог Cloudflare вроде TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, то есть покрывает ровно те задачи, ради которых чаще всего и писались воркеры. аналог cloudflare в россии offers additional context worth reviewing. Редиректы, заголовки, ограничение методов, блокировка по стране, челлендж для подозрительных клиентов – всё это конфигурируется без кода. Оставшиеся нестандартные случаи решаются на уровне nginx или middleware приложения, где у вас есть полный контроль над версиями и зависимостями.
Слой интеграций переносится на собственный сервер или в изолированный сервис. Вебхуки платежных систем, колбэки Telegram-ботов, обмен с 1С и CRM должны жить там, где есть постоянное хранилище, логи и возможность повторить операцию. Edge для этого подходит плохо даже в Cloudflare, просто там соблазн был выше. На российской инфраструктуре это ограничение работает в плюс: архитектура становится честнее, а инциденты – воспроизводимее.
Технические детали, которые стоит проверить до включения. Первое: как платформа передаёт реальный IP клиента и заголовки X-Forwarded-For, иначе GeoIP и защита от ботов будут видеть адрес прокси. Второе: поддержка HTTP/2 и HTTP/3, потому что часть воркеров неявно полагалась на мультиплексирование. Третье: поведение кэша – какие заголовки учитываются, как сбрасывается кэш при деплое. Четвёртое: лимиты на размер заголовков и тела запроса, они часто отличаются от Cloudflare. Пятое: логирование и метрики, без них отладка миграции превращается в гадание.
Отдельно про SSL и DNS. Перенос обычно делают сменой NS-записей на DNS-сервис платформы, а сертификаты выпускают заново через ACME. Если у вас были Cloudflare-специфичные настройки вроде Origin CA или mTLS между edge и бэкендом, их нужно воспроизвести на новом контуре. Здесь помогает поэтапный переезд: сначала переводится один поддомен или тестовый контур, проверяется вся цепочка, и только потом меняются NS основного домена. Такой порядок снижает риск простоя до часов, а не дней.
Риски зависимости от зарубежной инфраструктуры и выбор платформы
Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в ответ ограничивают доступ к сайтам на Cloudflare. Это не политический тезис, а операционный факт, с которым сталкиваются владельцы интернет-магазинов и медиапроектов. Сайт может быть технически исправен, но часть аудитории его просто не увидит. Для бизнеса это прямые потери: падает трафик, падает лидогенерация, страдает конверсия сайта, а служба поддержки получает поток жалоб, которые невозможно закрыть на своей стороне.
Второй риск – регуляторный. Требования к хранению и обработке персональных данных, к локализации ИТ-инфраструктуры и к раскрытию информации о взаимодействии с зарубежными сервисами ужесточаются. Когда вся точка входа трафика, TLS-терминация и WAF находятся у иностранного провайдера, доказать соответствие становится сложнее, а любое изменение его политики мгновенно становится вашей проблемой. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса, которые не покрываются ни SLA, ни страховкой.
Практический критерий выбора платформы при замена Cloudflare – не количество галочек в списке функций, а совпадение с вашей моделью нагрузки. Смотрите на три вещи. Первая: тарификация. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, то есть всплеск трафика не превращается в счёт с пятью нулями. Вторая: покрытие функций без кода – DNS, SSL, reverse proxy, WAF, защита от ботов, L7 DDoS, GeoIP-фильтрация и аналитика в одном контуре означают меньше склеек и меньше мест, где что-то отвалится. Третья: поддержка вашего стека. TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, а это как раз те платформы, где чаще всего и жили воркеры.
Про совместимость стоит договориться на берегу. Если в проекте есть код на Workers, закладывайте бюджет на его переписывание: от нескольких дней на редиректы до нескольких недель на интеграции. Если код только планируется, выбирайте примитивы, которые легко переносятся: стандартный HTTP, заголовки, внешний кэш, обычные серверные обработчики. Тогда следующая миграция, если она случится, будет стоить часы, а не спринты.
TrafficVeil предлагает переход с Cloudflare, и этот переход имеет смысл планировать как проект, а не как переключение тумблера. Составьте реестр воркеров и разметьте их по категориям. Перенесите редиректы и заголовки в конфигурацию периметра. Гео-логику переведите на GeoIP-фильтрацию платформы. Интеграции и вебхуки уберите на собственный сервер с постоянным хранилищем и логами. Проверьте передачу реального IP, поведение кэша, лимиты и метрики на тестовом поддомене. И только после этого меняйте NS основного домена. Такой порядок сохраняет работу сайта на территории РФ и по всему миру, а серверная логика перестаёт зависеть от чужого runtime, который в любой момент может стать недоступен.