Переезд с Cloudflare на российский аналог почти никогда не проходит как обычная смена DNS-провайдера. Первое, с чем сталкивается администратор, это экспорт зоны в BIND-формате: файл выглядит корректным, зона импортируется без ошибок, а через час сайт отдаёт 522 или 523. Причина в том, что Cloudflare при экспорте подменяет проксируемые A-записи на IP-адреса своих edge-серверов. В дампе остаются адреса вида 104.21.x.x и 172.67.x.x, а реальные origin-IP, на которых крутится ваш сервер, в файл не попадают. Если импортировать такую зону как есть, новый DNS-сервис начнёт отдавать клиентам адреса чужой инфраструктуры, и трафик уйдёт в никуда.
Это не баг экспорта, а следствие архитектуры: пока запись проксируется, Cloudflare намеренно скрывает origin, и в BIND-представлении остаётся только то, что видно снаружи. Поэтому перед импортом в TrafficVeil или любой другой российский сервис зону приходится чинить руками: находить настоящие IP в панели, подменять edge-адреса в файле и только потом заливать его. Работа занимает от пятнадцати минут на десяток записей, но пропущенная строка стоит часа простоя интернет-магазина или корпоративного портала.
Ниже разобран весь путь по шагам: где в панели Cloudflare лежат origin-IP, как аккуратно заменить их в экспортированном файле и что проверить до переключения NS, чтобы после переноса не ловить ошибки 522, 523 и 526. Отдельно остановимся на типичных промахах, из-за которых зона импортируется, но сайт не открывается.
Почему экспорт зоны из Cloudflare в BIND-формате искажает проксируемые записи
Экспорт зоны из панели Cloudflare выглядит как рутинная операция: раздел DNS, кнопка Export, на выходе текстовый файл в формате BIND. Администраторы сохраняют его, открывают в редакторе и только потом замечают, что часть записей указывает на чужие IP-адреса. Сайт после импорта такой зоны на новую платформу отдаёт 522 или 523, хотя буквально вчера всё работало.
Причина в архитектуре Cloudflare. Компания работает как обратный прокси: трафик посетителя сначала попадает на её edge-серверы, проходит фильтрацию, кеширование и только затем уходит на ваш сервер. Включённый оранжевый переключатель Proxy status означает, что в публичной DNS-зоне не может лежать реальный IP вашего хостинга. Иначе весь смысл проксирования теряется: атакующий обошёл бы защиту, обратившись напрямую к origin.
Поэтому при экспорте Cloudflare подставляет в A-записи адреса собственных edge-узлов. Для домена с проксированием вы увидите что-то вроде 104.21.x.x или 172.67.x.x. Это легитимные адреса инфраструктуры Cloudflare, и до тех пор, пока зона живёт внутри их панели, они корректно маршрутизируют трафик. Но как только файл уезжает на другую платформу, например на российский аналог Cloudflare вроде TrafficVeil, эти адреса превращаются в мусор: новый сервис честно направит посетителей на edge-серверы Cloudflare, которые о вашем домене уже ничего не знают.
Что именно теряется в BIND-файле
Формат BIND описывает только DNS-записи: имя, тип, TTL, значение. В нём физически нет полей для статуса проксирования, режима кеширования, настроек SSL или правил WAF. Поэтому экспорт уничтожает сразу два слоя информации.
- Реальный origin-IP. Вместо адреса вашего сервера в файле стоит edge-IP Cloudflare. Восстановить исходное значение из BIND-файла невозможно, его нужно искать вручную в панели.
- Флаг Proxied. Запись, которая была проксируемой (оранжевое облако), и запись, которая шла напрямую (серое облако, DNS only), в экспортированном файле выглядят одинаково. Различить их по содержимому нельзя.
- Связанная конфигурация. Page Rules, настройки SSL/TLS, Cache Rules, списки IP-ограничений и WAF-блокировки в BIND-экспорт не попадают вообще. Их переносят отдельно или настраивают заново.
Отдельная проблема касается CNAME-записей. Если вы использовали CNAME flattening, Cloudflare при экспорте разворачивает такую запись в A-запись с edge-IP. Внешне это выглядит как обычная A-запись, и при импорте на новую платформу вы получите статический адрес там, где ожидался алиас на сторонний сервис. Для верификации доменов, почтовых сервисов и SaaS-платформ это ломает всю схему.
Есть и менее очевидный эффект. Если сайт обслуживался через Cloudflare годами, реальный origin-IP мог измениться, а панель хранит актуальное значение. Администратор, который попытается вспомнить адрес сервера по памяти или по старым заметкам, рискует прописать устаревший IP и получить ту же ошибку 522, только по другой причине.
Итог простой: BIND-экспорт из Cloudflare нельзя импортировать вслепую. Файл пригоден как черновик, но перед переносом на российский аналог Cloudflare каждую проксируемую A-запись нужно сверить с панелью и вернуть ей настоящий origin-IP. Иначе замена Cloudflare обернётся падением сайта в первые же минуты после смены NS-серверов.
Пошаговая инструкция: как найти реальные origin-IP в панели Cloudflare
Панель Cloudflare устроена так, что origin-IP не лежат на поверхности. В списке DNS → Records вы видите либо оранжевое облако с подписью Proxied, либо серый значок DNS only. И только во втором случае в колонке Content стоит настоящий адрес вашего сервера. Если запись проксируется, там подставлен edge-IP Cloudflare, и именно это значение попадает в BIND-экспорт. Задача на этом шаге простая по смыслу и муторная по исполнению: вытащить реальные адреса вручную, запись за записью.
Начните с инвентаризации. Откройте нужный домен в дашборде, перейдите в раздел DNS → Records. Отфильтруйте таблицу по типу A и AAAA: остальные типы (MX, TXT, CNAME) при переносе ведут себя предсказуемо и сейчас не важны. Выпишите в отдельный файл каждую запись: имя (Name), тип, текущее значение Content и статус проксирования. Для небольшой зоны это 10-20 строк, для крупного проекта с поддоменами под API, почту и стейджинг легко набирается 60-80.
Дальше раскрывайте записи по одной. Кликните на строку, нажмите Edit, и в открывшемся окне переключите Proxy status на DNS only. Панель сразу подменит edge-адрес на реальный origin-IP. Скопируйте его в свой файл. После этого верните переключатель в Proxied, иначе вы снимете защиту с работающего сайта, пока идёт миграция, и получите прямой трафик на бэкенд со всеми вытекающими.
Есть более быстрый путь для тех, у кого записей много. Через API Cloudflare одним запросом GET /zones/{zone_id}/dns_records?type=A&per_page=100 вы получаете JSON, где для каждой записи есть поля name, content и proxied. Если proxied: true, поле content содержит edge-IP, а реальный адрес придётся достать отдельно. Тут помогает связка: в том же ответе есть поле id, а в логах вашего веб-сервера сохранились обращения от Cloudflare с заголовком CF-Connecting-IP, который и несёт настоящий адрес клиента. Сопоставив время и частоту запросов, вы восстановите origin-IP без ручного клика по каждой строке.
Не забывайте про поддомены, которые указывают на тот же сервер. Часто mail.example.ru, api.example.ru и www.example.ru проксируются на одну и ту же машину, и в экспорте вы увидите три разных edge-адреса, хотя origin один. Сверяйте их между собой: совпадение edge-IP у нескольких записей почти всегда означает общий бэкенд. Это экономит время и снижает риск перепутать адреса при массовой замене.
Отдельно проверьте записи, которые вообще не должны были проксироваться. Если у вас есть поддомен для VPN, SSH или панели управления на нестандартном порту, он либо помечен DNS only, либо проксируется ошибочно. Для таких записей origin-IP уже виден в таблице, и его достаточно просто перенести. А вот записи с CNAME на сторонние сервисы (например, на хостинг лендингов) трогать не нужно: они разрешаются по цепочке и не содержат вашего сервера.
Когда список готов, проверьте его на полноту. Количество выписанных origin-IP должно совпадать с числом проксируемых A-записей. Если где-то остался адрес из диапазонов Cloudflare (104.16.0.0/13, 172.64.0.0/13, 173.245.48.0/20 и другие из их публичного списка), значит, вы пропустили запись и в BIND-файле она останется битой. Такой адрес после импорта в российский аналог Cloudflare укажет пользователей на чужой edge-сервер, и сайт отдаст ошибку 522 или 523.
Сохраните результат в формате, удобном для следующего шага: имя записи, тип, origin-IP. Дальше вы будете массово заменять значения в экспортированном файле, и таблица из трёх колонок окажется быстрее, чем повторное открытие дашборда. На этом ручная часть с панелью Cloudflare закончена, можно переходить к правке зоны.
Замена проксируемых A-записей перед импортом в TrafficVeil
Когда таблица с origin-IP собрана, наступает самая механическая часть работы. Экспортированный из Cloudflare BIND-файл выглядит как обычная зона: строки SOA, NS, десятки записей A, AAAA, CNAME, MX, TXT. Проблема в том, что все проксируемые записи A в этом файле указывают не на ваш сервер, а на адреса edge-узлов Cloudflare. Диапазоны известны: 104.16.0.0/13, 172.64.0.0/13, 188.114.96.0/20 и еще несколько подсетей. Если импортировать такую зону в российский аналог Cloudflare как есть, трафик пойдет на чужие IP, которые к вашему сайту отношения не имеют. Посетитель получит ошибку 522 (Connection timed out) или 523 (Origin is unreachable), а вы будете искать проблему в конфигурации nginx, хотя причина в одной строке DNS.
Порядок замены edge-IP на origin-IP
Работайте не с исходным экспортом, а с его копией. Исходный файл оставьте как эталон: если что-то пойдет не так, всегда можно вернуться к нему и не пересобирать зону заново. Копию назовите понятно, например example.com.zone.fixed, чтобы не перепутать при импорте.
Дальше действуйте по записям. Откройте BIND-файл в текстовом редакторе и найдите первую строку вида:
www 300 IN A 104.18.32.47
Сверьтесь со своей таблицей origin-IP. Если реальный адрес сервера 203.0.113.10, строка должна стать такой:
www 300 IN A 203.0.113.10
TTL в 300 секунд обычно оставляют без изменений, но перед миграцией разумно снизить его до 60: это ускорит откат, если после переноса обнаружится ошибка. аналог cloudflare pages offers additional context worth reviewing. Для записей с несколькими A-адресами (round-robin) заменяйте каждую строку отдельно, не пытайтесь уместить все origin-IP в одну строку через пробел, хотя синтаксис BIND это и допускает: часть панелей при импорте читает только первый адрес.
Записи, которые в Cloudflare были в статусе DNS only, трогать не нужно. Их адреса и так указывают на реальные серверы. А вот CNAME, ведущие на проксируемые A-записи, проверьте отдельно: если CNAME указывает на www.example.com, а сама www проксировалась, цепочка после замены разрешится корректно. Если же CNAME вел на сторонний домен, который тоже обслуживался через Cloudflare, придется выяснять его origin-IP у владельца сервиса.
Отдельная ловушка: поддомены, которые вы проксировали ради скрытия IP, а теперь хотите оставить за Cloudflare. Такие записи в зоне для импорта в TrafficVeil лучше не размещать вообще. Смешанная схема, когда часть домена живет на одном провайдере, а часть на другом, работает только при аккуратной настройке NS-делегирования поддоменов, и на этапе миграции это лишний риск.
После замены прогоните зону через named-checkzone или любой онлайн-валидатор BIND. Синтаксические ошибки вроде забытой точки в конце FQDN приводят к тому, что запись превращается в www.example.com.example.com, и панель импортирует ее молча, без предупреждений. Проверьте также, что в файле не осталось ни одного адреса из диапазонов Cloudflare. Простой поиск по подстрокам 104.16, 104.17, 104.18, 172.64, 188.114 займет минуту и убережет от ошибок 522 и 523, которые иначе проявятся уже после переключения NS.
TrafficVeil импортирует BIND-зону целиком, включая SOA и NS. Убедитесь, что в SOA-записи указан корректный первичный сервер имен, который выдаст панель после добавления домена, иначе зона загрузится, но отвечать на запросы не будет. Если сомневаетесь в какой-то записи, удалите ее из файла перед импортом и добавьте вручную через веб-интерфейс: ручное добавление исключает ошибки парсинга и сразу показывает, как запись будет выглядеть в панели.
Проверка зоны и типичные ошибки при переносе на российский аналог Cloudflare
После того как edge-IP Cloudflare в BIND-файле заменены на реальные origin-IP, зону нельзя заливать вслепую. Синтаксически корректный файл ещё не значит рабочую конфигурацию: ошибка в одной строке SOA или забытая точка в конце имени ломает разрешение имён для всего домена. Проверка занимает 15-20 минут и экономит часы разбирательств с поддержкой после переключения NS.
Начните с локальной валидации. Утилита named-checkzone из пакета bind9-utils разбирает файл до импорта:
named-checkzone example.ru example.ru.zone
Команда возвращает “zone example.ru/IN: loaded serial 2026021501” при успехе или указывает номер строки с ошибкой. Типичные претензии: отсутствующая точка в конце FQDN (mail.example.ru превращается в mail.example.ru.example.ru), неверный serial в SOA, дублирование CNAME. Отдельно проверьте, что TTL у всех записей одинаковый или хотя бы осмысленный: смесь 300 и 86400 секунд усложняет откат.
Дальше тестируйте разрешение имён до смены NS. Запрос напрямую к серверам TrafficVeil:
dig @ns1.trafficveil.ru www.example.ru A +short
Ответ должен содержать origin-IP вашего сервера, а не адрес из диапазонов Cloudflare (104.x, 172.67.x, 188.114.x). Если видите edge-адрес, значит замена прошла не везде: проверьте поддомены, которые часто проксируются отдельно от основного домена.
Следующий шаг – проверка через публичные резолверы с указанием источника. Запрос через Google DNS покажет, видят ли зону внешние клиенты:
dig @8.8.8.8 www.example.ru A +short
После смены NS у регистратора записи появляются не мгновенно. Старые NS Cloudflare продолжают отвечать, пока не истечёт TTL делегирования у родительской зоны, обычно от 24 до 48 часов. В этот период часть пользователей попадает на Cloudflare, часть на TrafficVeil. Поэтому origin-сервер должен принимать трафик с обоих направлений: не блокируйте IP-диапазоны edge-серверов Cloudflare в файрволе до полного завершения миграции.
Проверьте SSL-сертификат. Если сайт работал через Cloudflare в режиме Full (Strict), на origin стоял валидный сертификат, и TrafficVeil подхватит его без проблем. В режиме Flexible сертификата на сервере не было, и после переноса посетители увидят предупреждение браузера. Выпустите сертификат Let’s Encrypt заранее, до переключения NS.
Ниже – сводка типичных ошибок и способов их обнаружить.
| Ошибка | Симптом | Как проверить |
|---|---|---|
| Остались edge-IP Cloudflare | Ошибка 522 или 523 после переноса | dig @ns1.trafficveil.ru, сравнить с панелью Cloudflare |
| Нет точки в конце FQDN | NXDOMAIN для поддомена | named-checkzone, визуальный просмотр файла |
| Старый serial в SOA | Вторичные NS не обновляют зону | dig SOA example.ru @ns1.trafficveil.ru |
| Origin-сервер блокирует новые IP | Сайт открывается через раз | Логи nginx или Apache на предмет 403 |
| Отсутствует SSL на origin | Предупреждение браузера о сертификате | openssl s_client -connect origin-ip:443 |
Отдельно проверьте почтовые записи. MX, SPF, DKIM и DMARC при экспорте из Cloudflare переносятся корректно, но если вы вручную правили TXT-записи при замене A-записей, легко задеть лишнюю строку. Потеря SPF-записи означает, что письма начнут попадать в спам в течение суток. Проверка:
dig TXT example.ru +short
Убедитесь, что строка v=spf1 присутствует целиком и не обрезана. DKIM-ключи в TXT часто длиннее 255 символов и разбиваются на части в кавычках, при ручном редактировании их легко склеить неправильно.
После переключения NS отслеживайте логи обращений 24-48 часов. Резкий рост 4xx и 5xx в первые часы – норма: часть трафика идёт по старым маршрутам. Если ошибки не уходят через двое суток, вернитесь к таблице выше. Практика показывает, что 8 из 10 проблем после миграции связаны с пунктом про edge-IP, который не был заменён на всех поддоменах.
Если коротко, порядок действий после правки BIND-файла такой: сохраните копию исходного экспорта, замените edge-IP Cloudflare на origin-IP, уменьшите TTL до 300 секунд, импортируйте зону в TrafficVeil и только после успешной проверки переключайте NS-записи у регистратора. Между сменой NS и отключением старой зоны в Cloudflare выдержите паузу не меньше 24 часов: TTL в 300 секунд истекает быстро, но кэш рекурсивных резолверов у части провайдеров живёт дольше, и в этот период трафик будет идти на два сервиса одновременно. SSL-сертификат выпускайте уже после того, как зона отвечает из новой инфраструктуры, иначе валидация домена не пройдёт.
Что проверить в первые сутки. Откройте сайт из трёх разных сетей: домашнего провайдера, мобильного оператора и корпоративного канала. Прогоните формы заказа и корзину интернет-магазина, потому что именно на них чаще всего всплывают ошибки после переноса, а не на статичных страницах. Сравните логи обращений в TrafficVeil с тем, что вы видели в Cloudflare: если реальные посетители внезапно помечаются как боты, ослабьте правила защиты от ботов на первые дни и ужесточайте их постепенно, глядя на статистику. Отдельно проверьте GeoIP-фильтрацию, если она включена, чтобы не отрезать клиентов из нужных регионов. И держите старую зону в Cloudflare в режиме DNS-only хотя бы неделю: это дешёвая страховка, если часть записей всё же осталась с чужими IP. Когда всё стабильно, верните обычный TTL и удалите временные записи.