Cloudflare — сервис, который позволяет бесплатно управлять DNS домена, кэшировать страницы и защищаться от атак. Многие владельцы сайтов переходят на него с мыслью «сайт станет быстрее и защищённее» и часто действительно получают пользу. Но подключение домена к Cloudflare — это не просто одна кнопка: вы переносите всё управление DNS домена в другое место. Если делать это в спешке, может остановиться почта, сайт попадёт в бесконечный редирект или вовсе перестанет открываться. Ниже подробно разберём, как работает подключение, что вы выигрываете и к каким рискам нужно подготовиться заранее.
Что на самом деле меняет подключение
Подключая домен к Cloudflare, вы меняете у регистратора NS-серверы домена на два сервера, выданных Cloudflare. С этого момента на все DNS-вопросы о вашем домене отвечает Cloudflare. Записи в старой DNS-панели больше ни на что не влияют, даже если они там остались. Это главное, что нужно понять: после подключения записи A, MX, TXT и все остальные редактируются только в панели Cloudflare.
При добавлении сайта Cloudflare автоматически сканирует существующие записи и предлагает перенести их в новую зону. Это удобно, но сканер находит только те имена, которые может угадать. Обычные www, mail и записи основного домена он обычно находит, а TXT-записи с особыми именами, например ключи DKIM, или редкие поддомены могут потеряться.
Что вы получаете
Главное преимущество — быстрый и надёжный DNS. NS-серверы Cloudflare расположены во множестве точек мира, а изменения записей применяются за секунды. Второе — режим прокси: для записей с включённым оранжевым облаком посетители подключаются не напрямую к вашему серверу, а к Cloudflare. Это даёт кэширование статических файлов, смягчение DDoS-атак и частичное сокрытие IP-адреса сервера.
Третье — дополнительные инструменты: правила безопасности, фильтрация ботов, правила перенаправления и статистика трафика. Многие из них доступны и на бесплатном тарифе, но конкретные возможности и ограничения со временем меняются, поэтому сверяйтесь с официальной документацией Cloudflare.
Риск 1: часть записей не переносится
Самая частая проблема — записи, пропущенные автоматическим сканером. Как только NS-серверы сменены, старая зона перестаёт работать, и каждая запись, которая была в ней, но не попала в Cloudflare, исчезает. Чаще всего это почтовые записи SPF, DKIM и DMARC, после чего письма начинают попадать в спам или отклоняться. Поэтому перед сменой NS сверьте каждую запись старой зоны со списком в панели Cloudflare.
# запрос важных записей со старого DNS-сервера
dig @ns1.eski-dns.uz misol-markaz.uz MX +short
dig @ns1.eski-dns.uz misol-markaz.uz TXT +short
dig @ns1.eski-dns.uz default._domainkey.misol-markaz.uz TXT +short
dig @ns1.eski-dns.uz _dmarc.misol-markaz.uz TXT +shortРиск 2: невыключенный DNSSEC «роняет» сайт
Если у домена включён DNSSEC, в родительской зоне находится DS-запись, соответствующая ключу старых серверов. NS-серверы Cloudflare подписывают зону другим ключом, поэтому после смены NS валидирующие резолверы отвергают ответ и возвращают SERVFAIL. Правильный порядок: сначала удалить DS-запись у регистратора, дождаться истечения её кэша и только потом менять NS. Если DNSSEC нужен, после подключения включите его в панели Cloudflare и внесите выданную новую DS-запись у регистратора.
Риск 3: неверный режим SSL и бесконечный редирект
При включённом прокси возникают два соединения: между посетителем и Cloudflare и между Cloudflare и вашим сервером. В режиме «Flexible» второе соединение идёт по незашифрованному HTTP. Если сервер перенаправляет каждый HTTP-запрос на HTTPS, Cloudflare снова приходит по HTTP, и браузер показывает ошибку «ERR_TOO_MANY_REDIRECTS». Если на сервере есть настоящий сертификат, например Let's Encrypt, режим «Full (strict)» — и безопасное, и правильное решение.
Риск 4: IP сервера всё равно остаётся открытым
Прокси скрывает IP сервера только для проксируемых записей. Если поддомен mail или ftp указывает напрямую на тот же сервер, любой может увидеть его через dig и обойти Cloudflare. Почтовые записи проксировать нельзя, потому что прокси Cloudflare не пропускает почтовые протоколы. Если защита — главная цель, подумайте о том, чтобы сервер принимал веб-трафик только с IP-диапазонов Cloudflare.
Риск 5: в логах адреса Cloudflare вместо реальных IP
После включения прокси в логах сервера, плагинах статистики и средствах защиты все посетители выглядят так, будто приходят с IP-адресов Cloudflare. Это сбивает с толку средства блокировки вроде fail2ban и может привести к блокировке не того адреса. Настоящий IP приходит в заголовке CF-Connecting-IP, и его нужно восстановить на веб-сервере. Для Nginx настройка выглядит примерно так, а полный список диапазонов берётся с официальной страницы Cloudflare.
# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... все остальные диапазоны IPv4 и IPv6 из списка Cloudflare
real_ip_header CF-Connecting-IP;Скорость для местной аудитории
Сайт на хостинге в Узбекистане очень быстро доходит до местных пользователей через сеть Tas-IX. При включённом прокси трафик идёт через сеть Cloudflare, и то, к какой точке Cloudflare подключится пользователь, зависит от его провайдера. В некоторых случаях это может замедлить сайт для местной аудитории. Поэтому до и после включения прокси откройте сайт через нескольких местных провайдеров и сравните время ответа. Если вам нужно только управление DNS, записи можно оставить с серым облаком, то есть в режиме «DNS only».
Пример: безопасный переезд учебного центра
Учебный центр в Ташкенте решил подключить сайт к Cloudflare, чтобы защититься от атак ботов. Администратор сначала выписал в таблицу все записи старой зоны: основной домен, www, поддомен lms, MX, SPF, DKIM и DMARC. Сканер Cloudflare не нашёл запись DKIM, её добавили вручную. Затем проверили, что DNSSEC у домена не включён, выбрали режим SSL «Full (strict)» и только после этого сменили NS-серверы в кабинете регистратора. На следующий день почта, сайт и учебная платформа продолжали работать без единого перерыва.
Короткий чек-лист перед подключением
- Выпишите все записи старой зоны, особенно TXT и DKIM, и сверьте со списком в Cloudflare.
- Если включён DNSSEC, сначала удалите DS-запись.
- Убедитесь, что на сервере есть настоящий SSL-сертификат, и выберите «Full (strict)».
- Почтовые и служебные записи оставьте в режиме «DNS only».
- Включите двухфакторную аутентификацию в аккаунте Cloudflare: теперь от него зависит весь домен.
Смена NS-серверов выполняется у регистратора. Если домен в sayt.uz, это делается в настройках домена в личном кабинете. Если решите отказаться от Cloudflare, тот же порядок работает в обратную сторону: сначала перенесите записи на новое место, затем верните NS.