Когда этот способ уместен
https://example.com/docs/start?ref=mailhttps://www.example.com/docs/start?ref=mailПуть берётся из wildcard-подстановки; query сохраняется отдельной настройкой.
Подходит, если домен уже подключён к Cloudflare или вы осознанно выбираете его DNS/proxy. Нужны права менять записи зоны, Redirect Rules и настройки сертификата. Single Redirects доступны на всех планах, но количество правил и возможности зависят от плана.
На уже используемом бесплатном плане этой настройки может быть достаточно без дополнительной платы за сервис редиректов. Это не обещание безлимитных правил или доступности сети из любой точки.
Все адреса example.com и example.org здесь демонстрационные. Замените их своими. Меняйте только исходный хост: рабочие DNS-записи назначения должны остаться на месте. Источник и назначение не должны перенаправлять друг на друга.
Для проверки нового правила можно сначала выбрать 302. После подтверждённого постоянного переезда переключите его на 301: браузер способен кешировать постоянный редирект, и откат серверной настройки не удаляет уже сохранённый ответ у посетителя.
1. Подготовьте DNS и сертификат источника
В DNS зоны проверьте запись example.com: входящий трафик должен идти через proxy Cloudflare. Режим DNS only не запускает Redirect Rules. Используйте поддерживаемую провайдером схему проксируемой записи для redirect-only источника; не подставляйте случайный origin IP из чужой инструкции.
Если подключаете новую зону, сначала перенесите в неё все действующие записи, включая почту и назначение www, и проверьте их перед сменой NS. В уже подключённой зоне не меняйте рабочую запись www ради редиректа корневого имени.
В SSL/TLS → Edge Certificates убедитесь, что активный edge-сертификат покрывает example.com. При использовании Universal SSL дождитесь готовности сертификата. Правило не может исправить TLS-ошибку, возникающую до получения HTTP-запроса. HTTPS целевого www должен работать отдельно.
2. Создайте два Single Redirects
Откройте Rules → Redirect Rules и создание Single Redirect. Выберите сопоставление wildcard pattern и внесите первую строку таблицы. Затем создайте второе правило. Это инструкция для Single Redirects, не для устаревшего сценария Page Rules.
| Source pattern | Target URL | Status | Preserve query string |
|---|---|---|---|
http://example.com/* | https://www.example.com/${1} | 301 | Enabled |
https://example.com/* | https://www.example.com/${1} | 301 | Enabled |
Дайте правилам различимые имена, например «Источник HTTP» и «Источник HTTPS», сохраните и включите их. ${1} подставляет совпавший путь после слеша: docs/start. Слеш после хоста в target уже указан. Для корня подстановка пустая.
Сохранение query включается отдельно — не рассчитывайте только на звёздочку. Официальный пример root-to-www с HTTPS-шаблоном не охватывает HTTP автоматически, поэтому здесь два правила. Для временной проверки выберите 302 в обоих, а после подтверждения постоянного перехода верните 301.
3. Исключите пересекающиеся правила
Проверьте порядок Single Redirects и другие механизмы перенаправления в зоне: Bulk Redirects, Page Rules, настройки HTTP → HTTPS и правила на origin. Более ранний ответ может изменить результат или добавить лишний переход.
Источник в этих правилах — только example.com. Не заменяйте его слишком широким wildcard, который захватит www и приведёт к циклу. Для обратного www → без www нужен другой фиксированный источник и target, а не два встречных правила одновременно.
4. Проверьте реальный edge-ответ
curl -sS -o /dev/null -D - 'http://example.com/'
curl -sS -o /dev/null -D - 'http://example.com/docs/start?tag=a&tag=b&utm_source=mail'
curl -sS -o /dev/null -D - 'https://example.com/'
curl -sS -o /dev/null -D - 'https://example.com/docs/start?tag=a&tag=b&utm_source=mail'Ожидайте код 301. Для корня заголовок Location должен быть https://www.example.com/, для вложенного адреса — https://www.example.com/docs/start?tag=a&tag=b&utm_source=mail. Версия HTTP и регистр имени заголовка в выводе могут отличаться. Если временно выбрали 302, ожидаемый код — 302.
curl -sS -I 'https://example.com/docs/start?tag=a&tag=b'
curl --path-as-is -sS -o /dev/null -D - 'https://example.com/files/report%20one.pdf?tag=a&tag=b&q=a%2Fb'Не добавляйте -L к первой проверке: важно увидеть ответ источника, а не скрыть его за переходом. Затем отдельно откройте адрес назначения и убедитесь, что там есть нужная страница. DNS не создаёт HTTP-ответ, а сертификат назначения не заменяет сертификат источника.
Оба исходных протокола должны вернуть назначение сразу на www. В повторяющихся query проверьте наличие обоих tag. Для закодированного пути сравните фактический Location: нормализация и другие правила зоны могут влиять на представление URL.
Если curl получает ответ, дополнительно проверьте переход из сетей, важных для ваших посетителей. Настройка правила сама по себе не подтверждает доступность Cloudflare во всех регионах.
Диагностика и отмена
| Симптом | Действие |
|---|---|
| Нет редиректа, отвечает origin | Проверьте, что исходная запись Proxied, правила включены, зона активна, а hostname совпадает с шаблоном. |
| HTTP работает, HTTPS выдаёт ошибку | Проверьте активность и покрытие edge-сертификата исходного домена, не только сертификат www. |
| Параметры запроса исчезли | В обоих правилах включите Preserve query string и исключите последующий редирект, который их удаляет. |
| Несколько переходов или цикл | Сравните каждый Location без -L, порядок правил и обработку назначения; исключите обратный переход. |
Для отката отключите именно эти два правила или восстановите их предыдущие настройки. Если возвращаете DNS only, заранее подготовьте прежний origin с нужным HTTPS: отключение proxy меняет не только место выполнения редиректа. Сохранённые браузером 301 могут действовать после отключения правил.
Что остаётся обслуживать
VPS и обновления веб-сервера здесь не нужны. Остаются регистрация домена, DNS/proxy, порядок правил, готовность edge-сертификата и соблюдение лимитов выбранного плана. Условия и возможности проверяйте в аккаунте, не по чужому обещанию «всегда бесплатно».
Если Cloudflare уже решает задачу, его можно оставить. Управляемый сервис полезен, когда хочется передать настройку и дальнейшее обслуживание редиректов. При DNS-подключении Redirect301 обслуживает весь исходный хост; выбранные страницы живого сайта требуют отдельной интеграции.