Как подключить сайт к Cloudflare

Как подключить сайт к Cloudflare

Cloudflare может работать перед сайтом двумя очень разными способами. Можно перенести весь домен на DNS и проксирование Cloudflare, а можно оставить узкую настройку и включать по одной функции за раз. От этого выбора зависят шаги, риски и план отката, а также то, насколько глубокой будет настройка DNS в Cloudflare.

Начните с этого. У маркетингового сайта с несколькими страницами и у корпоративного домена с активной почтой разные потребности, а для домена, который уже обслуживает сайт компании, обработка записей требует большей осторожности, чем для совершенно нового запуска. Если вы также думаете о безопасности сайта, Cloudflare часто становится частью разговора именно по этой причине, и вопрос о том, как перенести домен на Cloudflare, обычно встаёт одним из первых.

1. Определите, нужен ли вам полный контроль DNS или только одна функция Cloudflare

Cloudflare — это не одна кнопка. Он может управлять DNS, проксировать веб-трафик, кэшировать контент, фильтровать запросы и стоять между посетителями и вашим исходным сервером. Если вам нужна только одна функция, например управление DNS или слой защиты, всё равно важно понимать, что обычно именно смена nameserver'ов переводит домен под контроль Cloudflare.

Для простого сайта-визитки полный контроль часто подходит. Для конфигурации с почтовой маршрутизацией, сервисами подтверждения и несколькими поддоменами решение уже гораздо более чувствительное. Например, частной сетевой инфраструктуре может потребоваться, чтобы некоторые имена хостов не попадали в путь проксирования, тогда как веб-страницы могут спокойно проходить через Cloudflare.

Задайте один практический вопрос: что должно обязательно работать в первый день? Если среди этого есть почта, API-колбэки или платёжный поток, вы не просто «подключаете сайт к Cloudflare»; вы меняете способ разрешения домена. Это важно.

Короткое правило: не гадайте. Если сайт зависит от чего-то помимо веб-сервера, перечислите это до того, как трогать nameserver'ы. Этот список станет вашей страховкой.

2. Проверьте текущую настройку домена перед сменой nameserver'ов

Прежде чем что-либо переносить, проверьте, где DNS управляется сейчас. Регистратор и DNS-хостинг не всегда находятся у одной и той же компании, и именно из-за этого возникают лишние ошибки. Посмотрите текущие nameserver'ы, затем изучите записи зоны, которые там уже есть.

Вам нужна полная картина: A и AAAA-записи для сайта, CNAME-записи для поддоменов, MX-записи для почты, TXT-записи для подтверждения и любые нестандартные записи, которые используются сторонними инструментами. Пропущенная TXT-запись может сломать вход в систему. Неверная MX-запись может остановить почту.

Не полагайтесь на память. Домен, который работает уже много лет, может содержать записи, добавленные разными людьми в разное время, и часть из них уже нигде не документирована. Если владелец сайта не может объяснить запись, это повод сохранить её до тех пор, пока вы не поймёте, что она делает.

Это также момент, чтобы перечислить редиректы и старые имена хостов. Если трафик всё ещё приходит на старый поддомен, отметьте это сейчас. Редирект, который работает на исходном сервере, позже может перестать работать, если имя хоста не было перенесено в Cloudflare.

Сохраните копию текущей зоны вне аккаунта регистратора. Достаточно обычного текстового файла. Подойдёт и таблица. Смысл — в возможности восстановить всё при необходимости.

3. Создайте сайт в Cloudflare и импортируйте существующие DNS-записи

После аудита добавьте домен в Cloudflare. Cloudflare просканирует существующие DNS-записи и попытается импортировать их в свою зону. Это экономит время, но не означает, что всё перенеслось безупречно.

Проверьте импортированные записи построчно. Какая-то запись может отсутствовать, поддомен может быть продублирован, а значение — устареть. Первый проход нужен для точности, а не для скорости. Если вы видите имя хоста, которое должно указывать на ваш веб-сервер, но теперь указывает в другое место, исправьте это до смены регистратора.

Две простые проверки помогают поймать многие ошибки. Во-первых, сравните импортированные записи со списком из аудита. Во-вторых, убедитесь, что корневой домен и привычный хостнейм «www» оба ведут туда, куда нужно. Именно к этим записям пользователи обратятся первыми.

Если вы управляете сайтом, который ведёт себя как корпоративный сайт, особенно внимательно следите за поддоменами. Портал поддержки, staging-хост и файловый хост часто находятся рядом с основным сайтом, и одной пропущенной записи может хватить для трудно диагностируемого сбоя.

Небольшое практическое замечание: импорт Cloudflare полезен, но не заменяет вашу собственную проверку. Скан — это отправная точка. Ваш аудит — финальная верификация.

4. Выберите, какие записи должны оставаться под проксированием, а какие — только DNS

Cloudflare даёт выбор для многих записей. Оранжевая тучка означает, что трафик проходит через прокси Cloudflare. Серая тучка — это только DNS. Этот выбор не декоративный. Он меняет путь запросов.

Веб-трафик для публичного сайта часто проксируют. Почтовые записи — нет. Записи подтверждения — тоже нет. Некоторые поддомены, которые обслуживают API или специализированные инструменты, также должны оставаться только DNS, если вы не тестировали весь путь тщательно. Если нужен простой ориентир, проксируйте сайт, а все не-веб-сервисы оставляйте как есть, если нет причины это менять.

Распространённая ошибка — проксировать всё подряд, потому что так выглядит аккуратно. Долго аккуратно это не выглядит. MX-запись за прокси не будет работать. Хостнейм подтверждения может перестать распознаваться другим сервисом. Конечная точка для передачи файлов может начать вести себя странно, потому что изначально не предназначалась для прохождения через веб-прокси.

Думайте о функции, а не о внешнем виде. Сайт можно проксировать ради производительности и безопасности. Почта обычно должна оставаться только DNS. Если в вашей схеме есть трекеры, webhook-эндпоинты или сторонние хосты подтверждения, тестируйте каждый из них отдельно.

Трафик, который должен оставаться обычным DNS, часто как раз тот трафик, который вам меньше всего хочется сломать. Помните об этом, прежде чем слишком много раз нажать на оранжевую тучку.

5. Обновите nameserver'ы домена у регистратора

Cloudflare назначит для домена два nameserver'а. Вы заменяете текущие nameserver'ы у регистратора на эти два значения. Это шаг, который передаёт полномочия по DNS Cloudflare, поэтому копируйте их точно, так как указано, чтобы настройка DNS в Cloudflare прошла без лишних ошибок.

У регистратора найдите раздел nameserver'ов и удалите старую пару. Затем введите назначенную Cloudflare пару. Сохраните изменения.

Не паникуйте, если сайт не переключится мгновенно. DNS-изменения не синхронизируются по единому часовому механизму. Посетитель ещё какое-то время может попадать по старому пути, и это нормально. Если прежний DNS-хост остаётся доступным во время перехода, вы снижаете риск неудачных запросов.

Одна короткая мысль: будьте точны. Одна лишняя или пропущенная буква в nameserver-записи может нарушить делегирование.

Также не меняйте слишком много одновременно. Если вы переименовываете записи, переключаете хосты и редактируете nameserver'ы за один раз, отладка становится намного сложнее, чем должна быть.

6. Проверьте, что домен активен в Cloudflare, и протестируйте реальные пути трафика

После смены nameserver'ов Cloudflare должен показать домен как активный. Если этого не произошло, обычно причина одна из трёх: изменение у регистратора не было сохранено, nameserver'ы введены неверно, либо у регистратора ещё кэшированные данные. Проверьте это, прежде чем обвинять исходный сервер.

Затем тестируйте реальные пути, а не только главную страницу. Откройте основной домен, версию «www», ключевую внутреннюю страницу и все важные поддомены. Если на сайте есть страница входа, проверьте и её. Если есть загрузка файлов или отправка формы, протестируйте и эти действия. Страницы могут открываться, пока скрытая конечная точка уже сломана.

Здесь помогает инструмент мониторинга. Если вы используете платформу аналитики и мониторинга сайта, сравните первые живые запросы после переключения с обычным шаблоном. Резкий рост ошибок на одном имени хоста часто становится первым признаком того, что DNS-запись или настройка прокси требуют внимания.

Для чистой проверки используйте другой браузер или приватное окно. Кэшированные данные могут скрывать проблемы. Как и старая сессия входа.

Если что-то не работает, проверяйте путь от домена наружу: DNS, ответ edge-слоя, ответ исходного сервера, затем логику приложения. Такой порядок экономит время.

7. Настройте первые безопасные параметры Cloudflare для нового подключения

Когда домен станет активным, первые настройки лучше оставить консервативными. Выберите режим SSL/TLS, который действительно поддерживает ваш исходный сервер, и не угадывайте. Если сертификат на стороне origin ещё не готов, браузер может показать ошибки или Cloudflare может отклонить соединение. На запуске это очень неприятный сюрприз.

Следующим шагом должны быть базовые настройки безопасности. Если для вас уже важна безопасность сайта, именно здесь Cloudflare начинает помогать не только на уровне DNS. Начните с очевидных контролей, а затем снова протестируйте сайт. Агрессивные изменения могут подождать, пока вы не убедитесь, что базовая конфигурация работает правильно.

Поведение кэша тоже заслуживает внимательного первого взгляда. Страницу, которая часто меняется, нельзя обрабатывать так же, как страницу, которая меняется редко. Если вы не уверены, сначала оставьте поведение по умолчанию, понаблюдайте, как отвечает сайт, а затем вносите изменения по одному.

Полезная привычка — разделять «безопасно сейчас» и «хорошо бы потом». К «безопасно сейчас» относится правильная настройка пути SSL и проверка, что сайт по-прежнему открывается. К «хорошо бы потом» — тонкая настройка заголовков кэша или ужесточение правил после того, как у вас появятся логи для анализа. Такой порядок предотвращает ошибки, которые вы создаёте сами себе.

Держите этот этап небольшим. Небольшие изменения легче откатить.

8. Проверьте крайние случаи: почту, поддомены, редиректы и проблемы с mixed content

Именно здесь многие сайты спотыкаются. Почта обычно зависит от DNS-записей, которые должны оставаться только DNS. Проверьте, что MX-записи по-прежнему указывают на правильный почтовый хост, а TXT-записи SPF, DKIM или DMARC сохранились. Если почта перестанет работать, сайт может выглядеть нормально, пока рабочие письма исчезают.

Поддомены заслуживают собственного чек-листа. Staging-хост, хост изображений и конечная точка загрузки файлов могут требовать разного обращения. Если один из них был случайно переведён под проксирование, странное поведение вы увидите только на одном этом имени хоста. Такие ошибки отнимают время, потому что главная страница работает.

Редиректы тоже могут выявить ошибки. Если старый сайт перенаправлял посетителей с одного имени хоста на другое, после переключения проверьте этот путь снова. Цепочка перенаправлений, которая раньше работала, теперь может вести на имя хоста, которое так и не добавили в Cloudflare. Одной пропущенной записи достаточно, чтобы сломать весь путь.

Проблемы mixed content возникают, когда сайт загружает часть ресурсов по HTTP, а сама страница отдаётся по HTTPS. Браузеры не любят такую комбинацию. Изображения могут исчезать, скрипты — сбоить, а форма — перестать отправляться. Исправляйте исходные URL на уровне приложения, а не только в браузере.

Если ваш домен обслуживает рабочий процесс поддержки сайта после запуска, держите короткий список самых уязвимых хостов: почта, staging, загрузки, редиректы и стороннее подтверждение. Именно по этим пяти зонам обычно приходят первые обращения.

Ещё одна практическая проверка: откройте сайт из сети, которой вы обычно не пользуетесь. Мобильное подключение может выявить проблему с кэшем или задержку DNS, которую офисная сеть скрывает. Разные пути показывают разные проблемы.

И если вы подключаете сайт, у которого уже есть жёсткие эксплуатационные требования, документируйте каждую DNS-запись, которую вы изменили. Не потом. Сейчас.