Cloudflare для своего сайта: домен, почта, редиректы и обновления без ошибок

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

Основные действия выполняются в панели Cloudflare. Программировать не потребуется; команды для дополнительной диагностики можно пропустить.

Документация проверена 26 сентября 2026 года. Руководство подготовлено по официальным источникам; настройки на реальном домене и доставку почты в рамках подготовки не проверяли. Названия разделов панели со временем могут измениться.

Что подготовить перед настройкой

Для примеров нужен домен, DNS которого уже обслуживает Cloudflare, и доступ к его настройкам. Если домен ещё не подключён, сначала выполните его первичную настройку по базовому руководству для новичков.

В примерах используется example.com. Подставляйте свой домен. Все адреса и названия страниц ниже учебные.

Заранее соберите:

• доступ к Cloudflare и панели хостинга;
• требования подключаемого сервиса к DNS;
• список действующих адресов сайта и почты;
• снимок текущих DNS-записей и правил перенаправления;
• второй почтовый ящик для проверки писем.

Не меняйте одновременно DNS, почту и редиректы. После каждого отдельного изменения проверяйте результат: так проще найти причину ошибки.

Доступность для читателей из России

Cloudflare сообщает об ограничении трафика со стороны российских провайдеров, из-за которого сайты могут открываться частично или становиться недоступными. В официальной справке это описано как проблема на стороне сетей операторов. Из неё нельзя сделать вывод, что каждый сервис Cloudflare одинаково работает или не работает во всех российских сетях.

До настройки рабочего проекта проверьте нужный сценарий у своей аудитории. Открытие панели, загрузка сайта, скачивание документа и доставка письма — отдельные проверки. Доступность панели сама по себе ничего не говорит о доступности сайта для посетителей.

Для сайта проверьте домашний и мобильный интернет: загрузите страницу с изображениями, откройте внутреннюю ссылку, скачайте файл целиком. Запишите дату, оператора и результат. Эти проверки показывают состояние на момент теста и не гарантируют дальнейшую доступность.

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

Полезные сценарии

У каждого инструмента здесь своя задача. Можно выбрать один нужный блок и выполнить его отдельно.

DNS хранит записи об адресах и сервисах домена. Email Routing пересылает входящие письма. Redirect Rules возвращает браузеру новый адрес. Кеш Cloudflare хранит копии подходящих ответов сайта и файлов. Эти механизмы настраиваются независимо; включение одного не заменяет остальные.

Подключение дополнительного сервиса к домену

Допустим, основной сайт работает на example.com, а вы хотите открыть документацию или отдельный проект на docs.example.com. Для этого потребуется настройка в двух местах: у сервиса, который отдаёт сайт, и в DNS.

Получите настройки у сервиса

Сначала добавьте docs.example.com в раздел подключения собственного домена у выбранного сервиса. Он должен показать, какую запись создать, и объяснить условия выпуска HTTPS-сертификата.

Обычно сервис просит адрес сервера для записи A или AAAA, либо имя узла для CNAME. Иногда дополнительно нужен TXT для подтверждения владения доменом. Используйте именно выданные значения: универсального адреса для всех платформ нет.

Создайте запись в Cloudflare

1. Выберите нужный домен и откройте DNS → Records.
2. Убедитесь, что имя docs ещё не занято работающим сервисом.
3. Нажмите Add record и выберите тип из инструкции платформы.
4. В поле имени (Name) укажите docs.
5. В поле назначения внесите значение, выданное платформой. Для CNAME это имя узла без https:// и пути страницы.
6. Установите режим проксирования по требованиям платформы, проверьте остальные поля и сохраните запись.

Время хранения DNS-ответа задаёт поле TTL. Если платформа не требует другого значения, можно оставить Auto.

Как выбрать режим облачка

В режиме DNS only Cloudflare отвечает на DNS-запросы, а веб-соединение идёт к целевому серверу. В режиме Proxied HTTP/HTTPS-трафик проходит через Cloudflare; для него могут применяться функции кеша, защиты и перенаправления. Проксирование доступно для подходящих записей A, AAAA и CNAME.

Следуйте требованиям подключаемого сервиса. Если ему нужен DNS only для подключения или проверки домена, не включайте проксирование автоматически после появления зелёного статуса: сначала проверьте совместимость.

Проверьте результат

Откройте https://docs.example.com в отдельном окне браузера. Должен загрузиться нужный проект без предупреждения о сертификате. Затем откройте внутреннюю страницу и убедитесь, что основной сайт по-прежнему доступен.

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

Для отмены удалите только новую запись и отключите новую привязку у сервиса. Если редактировали существующую запись, восстановите её прежнее значение. Из-за DNS-кеша возврат может стать виден не сразу.

Адрес для входящей почты на своём домене

Задача: опубликовать hello@example.com на сайте и получать письма в уже существующий ящик. Для этого подходит Email Routing.

Сначала проверьте, где сейчас работает почта

Откройте DNS-записи типа MX. Они определяют серверы, принимающие почту для домена.

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

Сценарий ниже рассчитан на домен без действующей почты либо на заранее спланированный перенос.

Подключите домен к Email Routing

В текущей документации путь к сервису: Compute → Email Service → Email Routing. Нажмите Onboard Domain и выберите домен.

Перед подтверждением проверьте предлагаемые DNS-записи. Для маршрутизации используются MX, а для аутентификации пересылаемых писем — записи SPF и DKIM. Копируйте значения из своей панели, а не из случайного примера. Завершите подключение кнопкой Done и проверьте состояние DNS в настройках Email Routing.

Если SPF уже настроен для другого отправителя, не добавляйте вторую отдельную SPF-политику для того же имени: существующие требования нужно согласовать в одной записи. Не заменяйте её вслепую.

Добавьте получателя и правило

1. В Destination Addresses добавьте существующий ящик, куда будут приходить обращения.
2. Откройте письмо Cloudflare и подтвердите адрес.
3. Вернитесь к своему домену в Email Routing, откройте Routing Rules → Create routing rule.
4. В Email pattern укажите hello и выберите свой домен.
5. В Action выберите Send to an email, а в Destination — подтверждённый ящик.
6. Сохраните правило и проверьте, что оно активно.

Для начала достаточно одного явно заданного адреса. Приём на любые имена (Catch-all) подключайте только при понятной необходимости: он направляет в ящик и письма с ошибкой в адресе, и обращения к незапланированным именам.

Проверьте письмо и ответ

Отправьте письмо на hello@example.com из другого ящика, который не является получателем пересылки. Проверьте входящие и спам. Cloudflare отдельно рекомендует такой тест: некоторые провайдеры отбрасывают сообщения, которые возвращаются в тот же аккаунт отправителя.

Затем ответьте на полученное письмо и посмотрите с другого ящика, какой адрес указан в поле «От». Простая пересылка не настраивает отправку от имени hello@example.com.

Для постоянной переписки от имени домена нужен почтовый сервис с соответствующей возможностью отправки. У Cloudflare также есть отдельный Email Sending для отправки из приложений; его подключение не превращает правило пересылки в пользовательский почтовый ящик.

Если ошиблись получателем, исправьте назначение одного правила. Отключение всего Email Routing прекращает обработку входящей почты и удаляет созданные им почтовые записи. Возврат к другому провайдеру требует отдельного плана переключения MX; это не способ отменить опечатку в адресе.

Перенаправление старых ссылок и адреса с www

Редирект сообщает браузеру, куда перейти вместо запрошенного адреса. Это полезно после переименования страницы или при выборе единого основного адреса сайта.

Для Single Redirects запрос должен приходить через прокси Cloudflare. При DNS only правило Cloudflare не обработает запрос. Для исходного HTTPS-адреса также нужен действующий сертификат: браузер устанавливает защищённое соединение до получения перенаправления.

Сохраните старый адрес страницы

Допустим, страница переехала с /old-guide/ на /guides/start/.

Сначала откройте новый адрес напрямую. Настраивать редирект на ещё не опубликованную страницу бессмысленно: посетитель просто попадёт на другую ошибку.

В панели выберите Rules → Overview → Create rule → Redirect Rule. Назовите правило, например «Старое руководство → новое». В условиях выберите Custom filter expression и задайте:

(http.host eq "example.com" and http.request.uri.path eq "/old-guide/")

Условие ограничивает правило конкретным доменным именем и путём. В действии выберите фиксированный адрес назначения (Static):

https://example.com/guides/start/

Для первоначальной проверки выберите временное перенаправление 302. Если параметры после ? должны сохраниться, включите Preserve query string. После проверки постоянного переезда смените код на 301.

Нажмите Deploy, чтобы включить правило. Save as Draft только сохраняет его для дальнейшей настройки. Это правило рассчитано на обычную страницу. Перенаправления API, отправки форм и других запросов с данными требуют отдельной проверки поведения HTTP-методов.

Проверьте старый URL, новый URL напрямую и соседнюю страницу. Адрес /old-guide без завершающего слеша не совпадает с /old-guide/: если обе формы использовались, добавьте вторую в условия или отдельное правило. Сначала более узкие правила, затем общие: применяется первое подходящее перенаправление.

Приведите www к основному адресу

Если основной адрес сайта — https://example.com, можно направить на него запросы к https://www.example.com с сохранением пути. Этот рецепт предполагает, что для www уже существует корректная DNS-запись с режимом Proxied, а сертификат Cloudflare покрывает это имя. Если записи нет, сначала подключите www по требованиям хостинга, как описано в разделе о DNS.

Создайте отдельное правило с режимом Wildcard pattern:

Здесь * захватывает часть адреса после домена, а ${1} переносит её в назначение. Например, /about/?from=profile сохраняется при переходе. Включите правило кнопкой Deploy.

Правило охватывает только HTTPS. Если нужны и HTTP-ссылки, создайте второе с исходным шаблоном http://www.example.com/* и тем же HTTPS-назначением. Проверьте оба протокола отдельно. Уже существующие правила HTTPS и редиректы хостинга тоже могут участвовать в цепочке.

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

Необязательная команда показывает заголовки ответа без перехода по редиректу:

curl -sS -D - -o /dev/null 'https://www.example.com/about/?from=profile'

После замены домена на свой ожидайте выбранный код 302 или 301 и заголовок Location с правильным адресом, путём и параметрами.

Проверка обновлений и очистка кеша

Вы заменили документ или изменили страницу, но посетитель видит прежнюю версию. Сначала определите, на каком этапе осталось старое содержимое.

Проверьте публикацию на хостинге

Убедитесь, что изменение действительно опубликовано: завершилась сборка сайта, обновлён файл или выполнена публикация в CMS. Изменение черновика в редакторе не всегда меняет публичную страницу.

Для проверки выберите заметный признак: новый заголовок, номер версии документа или исправленную строку. Открытие страницы без ошибки ещё не доказывает, что вы получили свежий вариант.

Отделите кеш браузера от кеша Cloudflare

Откройте страницу в другом браузере или чистом сеансе. Если версии отличаются, проверьте локально сохранённые данные сайта. В Chrome для более точной диагностики можно открыть инструменты разработчика, вкладку Network, включить Disable cache и перезагрузить страницу, оставив инструменты открытыми.

Эта настройка отключает обычный кеш браузера на время проверки. Она не очищает CDN и не исключает отдельный кеш приложения, например service worker.

У Cloudflare есть свой кеш, но стандартный CDN не кеширует HTML и JSON по умолчанию. Дополнительные Cache Rules и логика Workers могут менять поведение. Поэтому старый текст страницы не всегда связан с кешем Cloudflare.

Очистите конкретный изменённый ресурс

Если обновился файл, который кешируется Cloudflare, начните с его точного публичного URL.

1. Откройте Caching → Configuration.
2. В блоке Purge Cache выберите Custom Purge.
3. В поле Purge by выберите URL.
4. Вставьте полный адрес ресурса, например https://example.com/files/guide.pdf.
5. Проверьте список и нажмите Purge.

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

Cloudflare рекомендует начинать с очистки по URL. Purge Everything удаляет кеш всей зоны, поэтому для одного обновлённого документа такая операция обычно избыточна. Очистка кеша не удаляет исходные файлы сайта.

Проверьте содержимое после очистки

Снова скачайте файл и найдите выбранный признак новой версии. Для диагностики посмотрите заголовок CF-Cache-Status в Network → Headers либо выполните:

curl -sS -D - -o /dev/null 'https://example.com/files/guide.pdf'

Эти статусы помогают найти источник ответа, но не подтверждают актуальность содержимого. HIT может содержать уже новую версию, а MISS — старый файл с хостинга.

Если регулярно обновляете PDF или другие материалы, используйте имена с версией, например guide-2026-09.pdf. Затем обновляйте ссылку на странице. Так старый и новый документы имеют разные адреса; сама страница со ссылкой тоже должна быть опубликована и проверена.

Итоговая проверка и отмена изменений

После настройки пройдите короткий список:

• основной сайт и новый поддомен открываются по HTTPS;
• нужная внутренняя страница загружается, сертификат не вызывает предупреждений;
• старая почта, если она существовала, продолжает принимать письма;
• тест на новый адрес приходит из стороннего ящика;
• адрес отправителя при ответе соответствует вашим ожиданиям;
• редиректы ведут на нужные страницы, сохраняют необходимые параметры и не образуют петлю;
• соседние страницы не попали под слишком широкое правило;
• по публичной ссылке доступна нужная версия обновлённого файла;
• сценарии проверены из сетей предполагаемых посетителей;
• сохранены прежние настройки и понятно, как вернуть каждое изменение.

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

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

Основные источники

• Cloudflare DNS: управление записями и подключение сервисов.
• Email Routing: подключение входящей почты.
• Email Service: DNS-настройки почтового домена.
• Single Redirects: создание правил перенаправления.
• Cloudflare Cache: очистка кеша.
• Cloudflare: перебои в доступности для пользователей из России.