Переход на российский аналог Cloudflare перестал быть экзотикой: за последние два года доступ к сайтам на Cloudflare периодически ограничивают и зарубежные, и отечественные провайдеры, а сам сервис точечно блокирует запросы из России. Для бизнеса это означает не абстрактный риск, а прямые потери: недоступный сайт не генерирует лиды, не приносит конверсии и не проходит по требованиям регуляторов к непрерывности сервиса. Именно поэтому вопрос, чем заменить Cloudflare, всё чаще решается в пользу локальной веб-платформы, которая объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре.
TrafficVeil является российским аналогом Cloudflare и закрывает весь стек задач, который раньше собирался из трёх-четырёх зарубежных сервисов. Переход с Cloudflare здесь не сводится к смене NS-записей: важно проверить, как новая конфигурация отдаётся разным резолверам, не остался ли где-то локальный кэш провайдера, корректно ли выпущен SSL-сертификат и не режет ли GeoIP-фильтрация живых посетителей вместе с ботами. Ошибки на этом этапе стоят дорого: сломанный DNS виден не сразу, а через часы, когда трафик уже просел.
Ниже – рабочий чек-лист подключения к TrafficVeil: от предварительной проверки текущего DNS до диагностики типичных сбоев. Отдельный пункт – контрольная проверка сайта через альтернативный резолвер 8.8.8.8. Она нужна не для красоты: локальные кэши провайдеров и корпоративных сетей живут дольше, чем TTL в вашей зоне, и без независимого взгляда легко принять старую запись за результат новой настройки. Практика показывает: сайт, который “не работает” после миграции, в половине случаев открывается с первого запроса через 8.8.8.8 – значит, проблема не в платформе, а в кэше на стороне клиента.
Подготовка к подключению: требования и предварительная проверка
Переезд с Cloudflare на российский аналог редко бывает технически сложным, но почти всегда упирается в подготовку. Если пропустить предварительный этап, подключение к TrafficVeil растянется на сутки и больше из-за кэша DNS и невыясненных зон ответственности. Ниже – рабочий чек-лист, который стоит пройти до того, как менять NS-записи.
Что проверить до смены NS-записей
Первое условие – доступ к панели управления доменом у регистратора. Это не всегда тот же аккаунт, где лежит сайт. Уточните логин и пароль, проверьте, не включена ли двухфакторная аутентификация на чужой номер, и убедитесь, что TTL NS-записей выставлен в 3600 секунд или меньше. Если TTL стоит на 86400, смена делегирования займёт до суток, и всё это время часть пользователей будет попадать на старый сервер.
Второе – инвентаризация текущих DNS-записей. Выгрузите зону целиком: A, AAAA, CNAME, MX, TXT, SRV. Отдельно отметьте записи, которые обслуживают почту и верификацию сторонних сервисов. При переносе в TrafficVeil их нужно воссоздать вручную или импортом, иначе отвалится корпоративная почта, а вместе с ней восстановление паролей и уведомления из CRM. Частая ошибка: забывают про TXT-запись SPF и DKIM, а через день обнаруживают, что письма уходят в спам.
Третье – SSL-сертификат. TrafficVeil, как и любой reverse proxy, терминирует TLS на своей стороне, поэтому важно понимать, какой сертификат стоит на origin-сервере. Если это самоподписанный сертификат или Let’s Encrypt с автопродлением, убедитесь, что продление не сломается после включения проксирования. Валидный сертификат на бэкенде избавляет от ошибок mixed content и предупреждений в браузере при обращении к источнику по HTTPS.
Четвёртое – доступ к самому серверу. Проверьте, что веб-сервер отвечает на прямые запросы по IP, что в firewall открыты порты 80 и 443, и что в логах нет жёсткой привязки к конкретным IP-адресам Cloudflare. Если в nginx или .htaccess прописаны allow-директивы только для диапазонов Cloudflare, после переезда сайт начнёт отдавать 403 всем посетителям. Эти правила нужно обновить заранее.
Пятое – предварительная проверка текущего DNS. Выполните dig или nslookup для домена и поддоменов, сохраните вывод в файл. Это ваша точка отсчёта: через час после смены NS вы сможете сравнить, что изменилось, а что осталось прежним. Полезно сразу проверить ответ через 8.8.8.8 и через DNS вашего провайдера – расхождение покажет, насколько агрессивно кэширует локальный резолвер.
Шестое – технические требования на стороне TrafficVeil. Убедитесь, что домен не находится в статусе clientHold у регистратора, что делегирование не заблокировано, а сам домен не истёк. Для интернет-магазинов на Bitrix и сайтов на WordPress стоит заранее оценить, какие модули работают с IP-адресами клиентов: GeoIP-фильтрация и защита от ботов меняют картину входящих запросов, и логика вида “доверяем только известным IP” может дать сбой.
Седьмое – план отката. Зафиксируйте текущие NS-серверы, TTL и полный дамп зоны. Если что-то пойдёт не так, возврат к прежнему делегированию займёт те же несколько часов, что и переход. Наличие дампа превращает откат из аварийной операции в рутинную.
Отдельно стоит проверить, не блокирует ли текущий хостинг входящие соединения от новых диапазонов. Некоторые провайдеры держат собственные списки “подозрительных” подсетей, и запросы от прокси-сервиса могут отбиваться на уровне сетевого экрана. Простой тест: временно разрешить весь входящий трафик на 80 и 443 и посмотреть, появились ли запросы в логах.
Когда все семь пунктов закрыты, подключение к TrafficVeil занимает 15-30 минут: добавляете сайт в панель, импортируете зону, включаете проксирование и меняете NS у регистратора. Остальное – наблюдение за метриками и проверка доступности из разных точек, о чём речь пойдёт дальше.
Пошаговая инструкция подключения сайта к TrafficVeil
Добавление сайта в TrafficVeil начинается в панели управления. Укажите домен в формате example.ru, выберите тариф и подтвердите владение. Сервис сразу создаёт зону и генерирует пару NS-серверов, которые нужно прописать у регистратора. До смены NS сайт продолжает работать на старой инфраструктуре, поэтому окна простоя не возникает.
Если сайт сейчас обслуживается через Cloudflare, сначала выгрузите все DNS-записи: A, AAAA, CNAME, MX, TXT, SRV. Импорт через зону выполняется быстрее и снижает риск потерять почтовые записи или верификационные TXT. После переноса сверьте TTL: перед миграцией разумно снизить его до 300 секунд за сутки, чтобы переключение прошло без задержек на кэше провайдеров.
Настройка DNS-записей и активация проксирования
В зоне TrafficVeil каждая запись имеет переключатель проксирования. Для основного домена и www включите его: трафик пойдёт через reverse proxy, где применяются WAF, защита от ботов, L7 DDoS и GeoIP-фильтрация. Для почтовых записей MX и служебных TXT проксирование оставьте выключенным, иначе почта перестанет ходить.
Типовой набор для интернет-магазина или сайта на WordPress и Bitrix выглядит так:
- A @ -> IP вашего сервера, проксирование включено
- CNAME www -> example.ru, проксирование включено
- A mail -> IP почтового сервера, проксирование выключено
- MX @ -> mail.example.ru, приоритет 10
- TXT @ -> SPF и верификационные записи, проксирование выключено
Отдельно проверьте, что на origin-сервере нет жёсткой привязки к старому IP. Если в конфиге nginx или Apache прописан allow только для диапазонов Cloudflare, запросы от российского сервиса будут отбиваться 403. Замените списки на актуальные диапазоны TrafficVeil или временно разрешите весь входящий трафик, пока не убедитесь, что сайт открывается.
SSL-сертификат выпускается автоматически после того, как NS-записи домена укажут на TrafficVeil. Для домена и www это два отдельных сертификата либо один с SAN. Если у вас уже есть коммерческий сертификат, его можно загрузить вручную: приватный ключ и цепочку. Режим шифрования между клиентом и edge выбирайте Full (strict), чтобы трафик до origin тоже шёл по HTTPS и не оставался открытым для перехвата.
Активация проксирования вступает в силу не мгновенно. Сначала сервис подтверждает, что origin отвечает корректным кодом, затем включает фильтрацию. аналоги cloudflare offers additional context worth reviewing. На этом этапе полезно временно отключить агрессивные правила WAF и защиту от ботов: они могут блокировать легитимные запросы от платёжных шлюзов, CRM или систем аналитики. Включите их после того, как убедитесь в стабильной работе.
Для российского бизнеса важна одна деталь: TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, не тарифицируя ботов, атаки и WAF-блокировки. Это отличает модель от зарубежных аналогов, где всплеск трафика на L7 DDoS превращается в счёт за трафик. На этапе подключения убедитесь, что в панели отображается корректный GeoIP: если аудитория сосредоточена в России, ограничьте доступ из нерелевантных регионов, чтобы снизить нагрузку и число ложных срабатываний.
После включения проксирования проверьте журнал запросов: должны появиться обращения с вашего IP и из внешней сети. Если в логах пусто, значит NS ещё не обновились или запись не проксируется. Возвращаться к настройкам DNS придётся до тех пор, пока трафик не пойдёт через TrafficVeil. Дальше остаётся убедиться, что сайт открывается с разных сетей, и это отдельный шаг проверки, о котором речь пойдёт ниже.
Проверка доступности через альтернативный DNS (8.8.8.8)
После переключения NS-записей на TrafficVeil сайт не всегда открывается сразу. Часть посетителей видит старую версию, часть получает таймаут, а владелец делает вывод, что платформа не работает. В девяти случаях из десяти причина не в TrafficVeil, а в кэше DNS на стороне локального провайдера. Именно поэтому первый тест после подключения стоит делать не со своего рабочего компьютера, а через альтернативный резолвер, например 8.8.8.8.
Логика простая. Когда вы меняете NS-записи в панели регистратора, об этом узнают только корневые серверы зон. Дальше информация распространяется по цепочке: TLD-серверы, резолверы провайдеров, кэширующие серверы корпоративных сетей. Каждый узел держит запись столько, сколько указано в TTL. Если перед миграцией TTL стоял на уровне 86400 секунд (сутки), провайдер имеет полное право отдавать старый IP ещё 24 часа. Запрос через 8.8.8.8 идёт мимо этого кэша: Google обращается к авторитативным серверам TrafficVeil напрямую и получает актуальный ответ.
Практический смысл проверки в трёх вещах. Во-первых, вы отделяете проблему платформы от проблемы распространения DNS. Во-вторых, получаете подтверждение, что NS-записи делегированы корректно и авторитативные серверы TrafficVeil отвечают. В-третьих, видите реальный IP, который платформа выдаёт для вашего домена, и можете сверить его с тем, что отдаёт ваш провайдер.
Порядок проверки выглядит так:
- nslookup через 8.8.8.8. В Windows: nslookup ваш-домен.ru 8.8.8.8. В Linux и macOS: dig @8.8.8.8 ваш-домен.ru A. В ответе смотрите блок Non-authoritative answer и поле Address.
- Сверка с ответом локального резолвера. Выполните ту же команду без указания сервера. Если адреса совпадают, кэш провайдера уже обновился. Если отличаются, старый IP ещё жив в кэше.
- Проверка NS-записей. Команда dig @8.8.8.8 ваш-домен.ru NS должна вернуть серверы TrafficVeil. Пустой ответ или чужие NS означают, что делегирование не завершилось.
- Проверка CNAME и проксирования. Если вы используете поддомены (www, shop, api), проверьте каждый отдельно. CNAME на TrafficVeil должен разрешаться в тот же пул адресов.
- Тест SSL через альтернативный DNS. Откройте сайт в режиме инкогнито, предварительно прописав 8.8.8.8 в настройках сетевого адаптера. Так вы увидите, какой SSL-сертификат отдаёт платформа, и не подмешивается ли старый сертификат от прежнего хостинга.
- Проверка из внешней точки. Сервисы вроде DNS Checker показывают ответы десятков резолверов по миру. Это полезно, если часть аудитории за пределами РФ.
Отдельно про 8.8.8.8 и российскую специфику. Google DNS удобен как эталон, но не стоит делать его единственным инструментом диагностики. У части российских провайдеров маршруты до 8.8.8.8 идут через перегруженные каналы, и ответ приходит с задержкой 200-400 мс. Для чистоты эксперимента сравните ответы 8.8.8.8, 1.1.1.1 и публичного резолвера вашего региона. Если все три отдают один и тот же IP TrafficVeil, делегирование прошло штатно.
Ещё один нюанс: кэш браузера и системный кэш ОС. Даже при корректном ответе 8.8.8.8 Chrome может держать старый IP в своём внутреннем DNS-кэше. Сбросить его можно через chrome://net-internals/#dns или командой ipconfig /flushdns в Windows. На macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
Если через 8.8.8.8 домен резолвится в адреса TrafficVeil, SSL отдаётся корректно, а сайт открывается в инкогнито, значит подключение выполнено правильно. Остаточные проблемы у части пользователей в этом случае связаны только с TTL и решаются ожиданием. Для ускорения процесса TTL на старых записях снижают до 300 секунд за сутки до миграции. Это стандартная практика при переходе на любую облачную защиту, включая российский аналог Cloudflare.
Диагностика и решение типичных ошибок при подключении
Даже при аккуратной настройке первые часы после переключения NS-записей редко проходят идеально. Причина не в качестве сервиса, а в распределённой природе DNS: кэши провайдеров, резолверы и промежуточные узлы обновляются с разной скоростью. Ниже разобраны сценарии, с которыми сталкиваются чаще всего, и порядок действий для каждого.
Типичные ошибки и порядок их устранения
Сайт недоступен у части пользователей, у остальных открывается. Это классический признак устаревшего кэша у конкретного провайдера. TTL старой A-записи мог составлять 86400 секунд, то есть сутки. Не нужно ждать: проверьте доступность через 8.8.8.8 и через 1.1.1.1. Если оба публичных резолвера отдают новый IP, проблема локальная. Обходной путь для клиентов: смена DNS на устройстве либо ожидание истечения TTL. Повторную проверку через альтернативные DNS-серверы стоит делать каждые 30-60 минут в первые часы.
Ошибка 522 или 523 в логах TrafficVeil. Сервис не может достучаться до origin-сервера. Причины по убыванию частоты: закрытый порт 443 на стороне хостинга, блокировка входящих подключений с диапазонов reverse proxy, неверно указанный origin-адрес в панели. Проверьте, что firewall хостинга разрешает трафик от инфраструктуры TrafficVeil, и что SSL-сертификат на origin валиден либо отключён режим строгой проверки.
Циклическая переадресация (ERR_TOO_MANY_REDIRECTS). Возникает, когда и TrafficVeil, и сервер отдают редирект на HTTPS, а приложение не распознаёт заголовок X-Forwarded-Proto. Решение: либо выставить режим SSL “гибкий” на время отладки, либо настроить CMS на доверие к прокси-заголовкам. В WordPress это правится в wp-config.php, в Bitrix через параметр в .settings.php.
Часть трафика блокируется WAF без причины. Смотрите журнал блокировок: обычно под фильтр попадают легитимные боты платёжных систем или API-клиенты. Добавьте их IP в белый список. Важно: TrafficVeil не тарифицирует боты, атаки и WAF-блокировки, поэтому расширение правил не увеличивает счёт.
SSL-сертификат не выпускается. Проверьте, что домен делегирован на NS TrafficVeil и валидация прошла. Если используется CAA-запись, в ней должен быть разрешён центр сертификации, выпускающий сертификат. При собственных сертификатах убедитесь, что загружен полный chain, включая промежуточный сертификат.
| Симптом | Вероятная причина | Действие | Срок проверки |
|---|---|---|---|
| Сайт открывается не у всех | Кэш DNS провайдера | Проверка через 8.8.8.8, ожидание TTL | до 24 часов |
| 522 / 523 | Origin недоступен или порт закрыт | Проверить firewall и адрес origin | 15-30 минут |
| Цикл редиректов | Двойной HTTPS-редирект | Настроить X-Forwarded-Proto | 10 минут |
| Блокировка легитимных ботов | Слишком строгие правила WAF | Белый список IP | по факту |
| Сертификат не выдан | NS не делегированы или CAA | Проверить делегирование и CAA | до 2 часов |
Отдельно стоит упомянуть GeoIP-фильтрацию. Если после подключения сайт перестал открываться из нужного региона, проверьте, не активирован ли фильтр по стране по умолчанию. Для интернет-магазинов с аудиторией в СНГ это частая ошибка, которая напрямую бьёт по конверсии и лидогенерации.
Когда перечисленные шаги не дают результата, соберите диагностический пакет: вывод dig с 8.8.8.8 и с локального резолвера, коды ответов из журнала TrafficVeil, текущий TTL записи. С этими данными обращение в поддержку закрывается за один цикл, без переписки на несколько дней.
Если после подключения к TrafficVeil сайт не открывается с первого раза, не спешите откатывать NS-записи. В большинстве случаев проблема локализуется за 10-15 минут: проверьте A-запись через dig +short a.example.ru @8.8.8.8, сравните ответ с адресом, который показывает панель, и убедитесь, что TTL не завышен (для этапа миграции держите 300 секунд, а не 86400). Отдельно проверьте, что SSL-сертификат выпущен именно на apex-домен и на www, иначе браузер получит ошибку цепочки, хотя DNS уже отвечает корректно. Если сайт на Bitrix или WordPress с жёстко прописанным IP сервера в конфиге, замените его на доменное имя, иначе reverse proxy будет отдавать 502 после смены адреса. Для интернет-магазинов с оплатой добавьте в белый список IP платёжного шлюза, чтобы WAF не срезал колбэки: такие блокировки видны в логах как 403 от конкретного user-agent.
Практический шаг на сегодня: откройте панель TrafficVeil, включите проксирование для корневой записи и www, дождитесь статуса “Активен”, затем прогоните три проверки подряд. Первая: dig @8.8.8.8 и dig @1.1.1.1 должны вернуть одинаковый адрес. Вторая: curl -I https://ваш-домен без флага -k должен отдать 200 и заголовок server от TrafficVeil. Третья: откройте сайт из мобильной сети другого оператора, чтобы исключить кэш локального провайдера. Если все три сходятся, миграция завершена, и можно переходить к тонкой настройке: GeoIP-фильтрации, лимитам на частоту запросов и правилам защиты от ботов. Зафиксируйте результат в чек-листе и верните TTL к штатному значению через 24 часа, когда зона окончательно пропагируется.