Cloudflare migration: DNS, SSL/TLS mode и реальный IP на origin-сервере

Инструкции
10 янв, 2026
Время на чтение: ~16 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Зачем вообще мигрировать в Cloudflare и где чаще всего ломается прод

Cloudflare подключают ради CDN/кеша, базовой защиты, удобного DNS и централизованного управления TLS. Но на практике «миграция» чаще ломается не на переключении NS, а на трёх местах: перенос DNS без потерь, правильный режим SSL/TLS mode между Cloudflare и origin, и восстановление реального IP клиента в логах/приложении.

Ниже — последовательный план, который помогает избежать классики: бесконечные редиректы, 525/526, смешанный контент, внезапно умершую почту и логи, где вместо пользователей только адреса Cloudflare.

Дальше по тексту: origin — ваш сервер (Nginx/Apache/приложение), edge — узлы Cloudflare.

Подготовка перед переносом DNS в Cloudflare

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

1) Соберите текущую зону как есть

Выгрузите записи из панели текущего DNS-провайдера. Особое внимание: MX, TXT (SPF/DKIM/DMARC), SRV, CAA, поддомены для почты и API, а также записи верификаций (поисковики, почтовые сервисы, CDN, платежные провайдеры).

Дополнительно полезно посмотреть «что реально отвечает сейчас» через dig — чтобы не перетащить устаревшие записи из панели:

dig +short A example.com

dig +short AAAA example.com

dig +short MX example.com

dig +short TXT example.com

dig +short CAA example.com

2) Снизьте TTL заранее (если возможно)

Если текущий DNS позволяет — за 12–24 часа уменьшите TTL ключевых записей (A/AAAA/CNAME для сайта и API) до 300–600 секунд. Это ускорит «сходимость» после смены NS и упростит отладку.

3) Проверьте, где почта и что нельзя проксировать

Cloudflare проксирует HTTP(S). Почтовые протоколы проксировать не нужно: в лучшем случае не будет эффекта, в худшем — поломаете доставку/подключения. Поэтому такие записи в Cloudflare должны быть DNS only (серые), а не proxied (оранжевые):

MX и хосты, на которые указывают MX
IMAP/POP3/SMTP хосты (если вынесены отдельными A/CNAME)
Autodiscover/Autoconfig (если используется почтовыми клиентами)

Практическое правило: всё, что не обслуживает браузер по HTTP(S), оставляйте как DNS only.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

DNS to Cloudflare: перенос зоны и безопасное переключение

Шаг 1: добавьте домен в Cloudflare и импортируйте записи

Cloudflare обычно предлагает автоматический импорт. Относитесь к нему как к черновику: после импорта вручную сравните с исходной зоной, особенно MX/TXT/CAA/SRV. Автоимпорт иногда пропускает специфические записи, а иногда «угадывает» лишнее.

Шаг 2: решите, что проксировать, а что оставить DNS only

Для сайта и API проксирование включают чаще всего: получаете кеш, WAF, скрытие IP origin. Но помните: когда включено проксирование, снаружи виден IP Cloudflare, а на origin потребуется настройка real IP (разберём ниже).

Рабочий подход для миграции: сначала включить Cloudflare как DNS (всё DNS only), убедиться, что резолв и сервисы в норме, и только затем включать proxied для нужных веб-хостов.

Шаг 3: смените NS у регистратора и дождитесь делегирования

После смены NS часть пользователей уже увидит новую зону, а часть ещё будет жить на старой (зависит от кеша резолверов). Поэтому:

не меняйте одновременно NS и критические записи на старом DNS; сначала подготовьте и проверьте зону в Cloudflare
на время миграции избегайте крупных изменений на сайте, чтобы быстрее локализовать проблемы

Проверка после переключения: что смотреть

После делегирования проверьте:

что A/AAAA/CNAME отдают ожидаемые значения
что MX и TXT на месте (почтовые эффекты часто проявляются спустя несколько часов)
что сайт открывается по HTTP и HTTPS так, как вы планировали

Если после смены NS появились ошибки TLS или редирект-петля — почти всегда причина в режиме SSL/TLS mode или конфликте редиректов между Cloudflare и origin.

Сверка DNS-записей перед переключением NS: A/AAAA/CNAME, MX, TXT, CAA

SSL/TLS mode (Flexible/Full/Strict): как выбрать и не попасть в редирект-ад

У Cloudflare два «плеча» TLS: пользователь ↔ Cloudflare и Cloudflare ↔ origin. Админу важнее второе плечо — именно там чаще ломается безопасность, редиректы и логика приложения.

Flexible: когда нельзя (почти всегда)

Flexible означает: снаружи у пользователя HTTPS до Cloudflare, но от Cloudflare до origin идёт HTTP. С точки зрения браузера «замок» есть, но трафик до вашего сервера не шифруется.

Проблемы Flexible в проде:

часто вызывает циклические редиректы, если origin сам делает 301 на HTTPS
ломает приложения, которым нужен HTTPS на origin (куки с Secure, OAuth callback, корректное определение схемы)
внутренне небезопасен, если origin не в приватном контуре

Flexible — временный костыль. Для нормальной схемы миграции целитесь минимум в Full, а в идеале — Full (Strict).

Full: шифрование есть, но сертификат на origin может быть «любой»

Full: Cloudflare подключается к origin по HTTPS, но не проверяет валидность сертификата. То есть канал шифруется, но проверка подлинности origin формальная.

Подходит как промежуточный этап (например, вы только подняли TLS на origin или используете самоподписанный сертификат). Для устойчивого продакшна лучше переключаться на Strict.

Full (Strict): рабочая и правильная схема

Full (Strict): Cloudflare подключается к origin по HTTPS и проверяет сертификат. Это лучший вариант для продакшна.

Типовая схема без сюрпризов: включить Full (Strict), на origin поставить валидный сертификат (публичный от УЦ или Origin Certificate), на origin настроить редирект HTTP→HTTPS. Опционально включайте в Cloudflare «Always Use HTTPS» только если понимаете, как он будет взаимодействовать с вашим редиректом.

Где возникает петля редиректов

Классика: Cloudflare в Flexible приходит на origin по HTTP, origin отвечает 301 на HTTPS, Cloudflare снова приходит по HTTP — и по кругу. Лечится переходом с Flexible на Full/Strict (предпочтительно), либо временным отключением редиректа на origin (обычно хуже и рискованнее).

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Origin Certificate: когда он нужен и как правильно использовать

Origin Certificate — сертификат, который выпускает Cloudflare для установки на origin. Он доверен Cloudflare, но не обязан быть доверенным браузерам. Это ключевой момент: сертификат не предназначен для прямого доступа пользователей к серверу в обход Cloudflare.

Когда Origin Certificate — отличный выбор

нужен Full (Strict), но не хочется зависеть от публичных УЦ на origin
origin скрыт и доступен только через Cloudflare (или вы ограничили вход на фаерволе)
у вас много хостов/SAN и удобнее выдать один сертификат под нужные имена

Ключевое ограничение

Если кто-то зайдёт напрямую на IP origin (мимо Cloudflare), браузер может ругаться на недоверенный сертификат. Это ожидаемо. Поэтому вместе с Origin Certificate обычно:

закрывают прямой доступ к origin по 80/443, оставляя только подсети Cloudflare и ваши админские адреса
или делают отдельный «прямой» административный хост/вход, не завязанный на Cloudflare

Быстрая диагностика TLS между Cloudflare и origin

Если видите ошибки 525 SSL handshake failed или 526 Invalid SSL certificate, обычно это означает: Cloudflare не смог договориться по TLS с origin или сертификат/цепочка не подходят под Strict. На origin проверяйте: доступность 443, соответствие имени сертификату, цепочку, поддержку SNI и версии протоколов.

Real IP logs: как вернуть реальный IP клиента за Cloudflare

При включенном проксировании ваш сервер видит соединение от IP Cloudflare. Для логов, антифрода, rate limit и аналитики нужно восстановить реальный IP посетителя.

Cloudflare передаёт IP клиента в заголовках CF-Connecting-IP и X-Forwarded-For. Правильная настройка всегда состоит из двух частей:

доверять заголовкам только от IP Cloudflare (иначе их можно подделать)
научить веб-сервер брать remote_addr из корректного заголовка

Nginx: модуль realip и доверенные подсети Cloudflare

В Nginx используйте real_ip_header и набор set_real_ip_from для подсетей Cloudflare. Подсети со временем меняются — заложите их обновление (конфигурационное управление/регламент).

http {
    real_ip_header CF-Connecting-IP;
    real_ip_recursive on;

    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 104.16.0.0/13;
    set_real_ip_from 104.24.0.0/14;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 131.0.72.0/22;

    access_log /var/log/nginx/access.log combined;
}

После этого $remote_addr станет реальным IP клиента (при условии, что запрос пришёл от Cloudflare). Проверьте, что формат логов действительно использует $remote_addr.

Apache: mod_remoteip

В Apache логика аналогична: подключаем mod_remoteip, указываем заголовок и доверенные подсети.

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22

И убедитесь, что формат логов берёт адрес клиента из скорректированного поля (обычно это происходит автоматически после включения модуля).

Отдельная проверка: приложение и rate limit

Если лимитируете запросы по IP на уровне приложения или origin-WAF, убедитесь, что приложение использует правильный источник IP. Частая ошибка: Nginx уже исправил remote_addr, а приложение продолжает читать X-Forwarded-For «как есть» и получает мусор. Выберите один источник истины: либо доверяйте remote_addr, либо корректно парсите цепочку X-Forwarded-For только при доверенном прокси.

IP-адрес origin: скрывать, ограничивать, диагностировать

Когда включаете Cloudflare proxy, IP origin не должен светиться в DNS. Но он всё равно может «утечь» через старые записи, прямые ссылки на IP в коде/письмах или через непроксируемые поддомены, указывающие на тот же адрес.

Хорошая практика: ограничить вход на 80/443 на origin только подсетями Cloudflare (и вашими административными адресами). Это снижает риск атак мимо Cloudflare и делает использование Origin Certificate логичным.

Если вы размещаете origin на отдельном сервере, часто удобнее делать это на VDS с явными правилами фаервола и предсказуемой сетевой схемой (отдельно веб, отдельно почта, отдельно админ-доступ).

Настройка real IP за Cloudflare: trusted proxies и заголовок CF-Connecting-IP

Cache Rules: как управлять кешем без сюрпризов

Раньше многие настраивали всё через Page Rules. Сейчас чаще используют Cache Rules и сопутствующие правила трансформаций/редиректов. Смысл один: явно описать, что кешируем, как долго и при каких условиях.

Типовые правила, которые реально нужны веб-мастерам

Не кешировать админку и личные кабинеты: URL с /admin, /wp-admin, /user, /account, корзина/checkout.
Кешировать статику долго: .css, .js, изображения, шрифты — при условии versioning (хэши в именах файлов или query string).
Осторожно с HTML: кеш HTML ускоряет, но легко ломает персонализацию и корзины. Если кешируете HTML — продумайте bypass по cookie, header, query и методу.

Кто главный: Cloudflare или origin

Если origin отдаёт Cache-Control и Set-Cookie, Cloudflare будет учитывать это поведение (в зависимости от настроек). Перед внедрением кеша полезно привести заголовки в порядок: приватный контент — Cache-Control: private, статика — длительные TTL и понятная стратегия инвалидации.

Чеклист: быстрый план миграции без простоя

Собрать текущие DNS-записи и снизить TTL для ключевых хостов.
Добавить домен в Cloudflare, импортировать зону, вручную сверить записи.
На первом этапе оставить записи DNS only, переключить NS, убедиться, что всё резолвится и сервисы живы.
Поднять TLS на origin и выбрать SSL/TLS mode: целиться в Full (Strict).
При необходимости выпустить и поставить Origin Certificate (если планируете закрыть прямой доступ к origin).
Включить проксирование для веб-хостов, настроить real IP (Nginx/Apache) и проверить логи.
Настроить Cache Rules для статики и исключения админки/личного контента.
После стабилизации поднять TTL обратно до нормальных значений (например, 3600).

Типовые симптомы и что проверять первым делом

Сайт уходит в бесконечные редиректы

Проверяйте: не стоит ли Flexible, нет ли дублирующего «Always Use HTTPS» и редиректа на origin, корректно ли приложение определяет HTTPS (часто требуется корректная обработка X-Forwarded-Proto и/или доверие к прокси).

525/526 ошибки

Проверяйте: доступность 443 на origin, сертификат и цепочку, соответствие имени, поддержку SNI, режим Full/Strict.

В логах только IP Cloudflare

Проверяйте: настроены ли set_real_ip_from/RemoteIPTrustedProxy, правильный ли заголовок (CF-Connecting-IP), и действительно ли включено проксирование (при DNS only заголовков может не быть).

Итог

Правильная миграция в Cloudflare — это не «перенести DNS и включить облачко», а выстроить предсказуемую связку DNS → проксирование → TLS между edge и origin → корректный real IP → управляемый кеш. Если делать это последовательно, вы получаете ускорение и защиту без поломки логики приложения и без потери наблюдаемости по логам.

Если хотите развить схему дальше, следующий уровень — закрыть origin от прямого доступа, выделить отдельный административный вход и формализовать политику кеша (bypass по cookie/заголовкам для динамики). По доменам и организационным вопросам полезно держать под рукой материал про перенос домена с EPP-кодом и нюансы DNS.

Поделиться статьей