Cloudflare DNS управляет доменными записями и проксированием веб-трафика, Workers запускает серверный код в сети Cloudflare, а Tunnel публикует локальные сервисы через исходящие соединения. Ниже — практический справочник по настройке и проверке этих трёх сервисов.

Справочник рассчитан на читателя, который умеет открыть настройки домена и запустить команду в терминале. Для DNS понадобится доступ к регистратору и рабочая зона, для Workers — Node.js, для постоянного Tunnel — компьютер или сервер с работающим приложением и доступ владельца Cloudflare.

Выбирайте раздел по задаче: DNS связывает домен с сервисом; Worker обрабатывает запрос; Tunnel даёт внешнему посетителю путь к приложению на вашем компьютере. Эти слои можно сочетать, но настройка одного не создаёт два остальных.

Команды, интерфейсы и лимиты сверены с официальными источниками 3 октября 2026 года. Подключение домена, публикация Worker и запуск внешнего Tunnel при подготовке текста не выполнялись.

Часть 1. Cloudflare DNS

Как работает Cloudflare DNS

DNS (Domain Name System) преобразует доменные имена, например mysite.ru, в адреса серверов. В наиболее распространённой схеме Cloudflare становится основным авторитетным DNS-провайдером: вы добавляете домен, проверяете импортированные записи и меняете nameservers у регистратора.

После подключения вы управляете DNS-записями через Cloudflare Dashboard или API. Для записей A, AAAA и CNAME можно отдельно выбрать, должен ли HTTP/HTTPS-трафик идти через сеть Cloudflare.

Основные типы DNS-записей

Proxied и DNS only

flowchart LR
    A[Посетитель] --> B{Запись Proxied?}
    B -->|Да| C[Сеть Cloudflare]
    C --> D[Origin-сервер]
    B -->|Нет| D

Proxied: оранжевое облако

Для A, AAAA или CNAME Cloudflare отвечает своими адресами anycast (общими адресами сети, направляющими запрос к ближайшему узлу) и принимает HTTP/HTTPS-запросы перед исходным сервером приложения (origin). Это позволяет применять CDN-кэш, DDoS-защиту, WAF, правила перенаправления и другие настройки Cloudflare. Реальный адрес origin не возвращается в DNS-ответе этой записи.

DNS only: серое облако

Cloudflare возвращает фактический адрес, к которому ведёт запись. Веб-трафик идёт напрямую, поэтому Cloudflare не может кэшировать, защищать или предоставлять HTTP/HTTPS-аналитику по этим запросам.

Проксирование поддерживают только A, AAAA и CNAME. MX, TXT и остальные типы всегда работают как DNS only.

Перенос домена на Cloudflare

1. Добавьте домен в Cloudflare Dashboard.
2. Проверьте импортированные A, AAAA, CNAME, MX и TXT-записи.
3. Если у регистратора включён прежний DNSSEC, отключите его по инструкции регистратора и дождитесь удаления старой DS-записи. Иначе после смены DNS-провайдера домен может перестать разрешаться. Порядок DNSSEC.
4. Скопируйте серверы имён (Nameservers), назначенные Cloudflare.
5. Замените текущие серверы имён в панели регистратора, а не добавляйте NS в обычную таблицу DNS.
6. Дождитесь статуса Active. Проверьте сайт, поддомены и почту по сохранённой рабочей конфигурации. Затем настройте DNSSEC для новой зоны и внесите новые DS-данные у регистратора.

Проверить назначенные NS можно командой:

dig NS mysite.ru +short

В ответе должны появиться nameservers, выданные Cloudflare. Смена серверов имён может занять до 24 часов. Pending означает незавершённое подключение DNS; это не оценка исправности HTTPS, формы или почты.

Практические конфигурации

Сайт на отдельном сервере

Тип: A
Имя: @
Значение: 203.0.113.50
Режим: Proxied

Тип: CNAME
Имя: www
Значение: mysite.ru
Режим: Proxied

Пример MX-записи в прежней схеме Google Workspace

Тип: MX
Имя: @
Значение: aspmx.l.google.com
Приоритет: 1

Тип: TXT
Имя: @
Значение: v=spf1 include:_spf.google.com ~all

Это одна запись из прежней схемы Google Workspace. Для нового подключения Google использует MX smtp.google.com; прежний набор MX продолжает поддерживаться. Берите значения из текущей инструкции своего аккаунта, а SPF, DKIM и DMARC проверяйте отдельно. Не заменяйте рабочую зону этим фрагментом. Инструкция Google.

Дополнительные настройки

• DNSSEC защищает DNS-ответы от подмены, если их подпись проверяется резолвером. После включения выполните инструкции Cloudflare для вашего регистратора.
• Always Use HTTPS перенаправляет HTTP-запросы на HTTPS и настраивается в параметрах SSL/TLS.
• Wildcard-запись вида *.mysite.ru охватывает поддомены, для которых нет более конкретной записи.

Часть 2. Cloudflare Workers

Что запускается в Workers

Cloudflare Workers выполняет JavaScript, TypeScript и поддерживаемые платформой приложения в распределённой среде Cloudflare. Worker принимает запрос через обработчик fetch, может обращаться к внешним API и использовать привязанные сервисы хранения.

Типичные задачи:

• API-прокси и CORS (правила доступа к запросам из браузера);
• обработка вебхуков;
• редиректы и маршрутизация;
• серверный рендеринг;
• A/B-тесты;
• обработка запросов с учётом географии;
• боты и небольшие API без отдельного сервера.

Создание первого Worker

Установите поддерживаемую LTS-версию Node.js не ниже 22. На дату проверки Wrangler 4.147.0 и генератор C3 (create-cloudflare) 2.73.2 требуют Node.js ≥22. Отдельная глобальная установка Wrangler не нужна: C3 добавляет его в проект. Для публикации нужен доступ владельца аккаунта Cloudflare; локальный пример ниже начинается без публикации.

npm create cloudflare@latest -- my-first-worker
cd my-first-worker

В мастере выберите пример Hello World, вариант Worker only и JavaScript. Для Git выберите Yes, а для вопроса о деплое — No. Основной файл будет находиться в src/index.js или src/index.ts, а конфигурация — в wrangler.jsonc.

Минимальный обработчик:

export default {
  async fetch(request, env, ctx) {
    return new Response("Привет из Cloudflare Workers!", {
      headers: { "Content-Type": "text/plain;charset=UTF-8" },
    });
  },
};

Запустите локальный сервер:

npx wrangler dev

Откройте http://localhost:8787: должен вернуться текст «Привет из Cloudflare Workers!». Если порт занят, остановите свой прежний dev-процесс или задайте свободный порт через npx wrangler dev --port 8790; проверьте именно этот адрес. Локальный ответ показывает работу проекта на вашем компьютере.

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

npx wrangler deploy

Worker будет опубликован на поддомене *.workers.dev или на заранее настроенном пользовательском домене.

API-прокси с секретом

Секретный ключ нельзя размещать во фронтенд-коде. Сохраните его как секрет Worker, а затем обращайтесь к значению через env.

npx wrangler secret put API_KEY

export default {
  async fetch(request, env) {
    const upstream = await fetch("https://api.example.com/data", {
      headers: {
        Authorization: `Bearer ${env.API_KEY}`,
        Accept: "application/json",
      },
    });

    const headers = new Headers(upstream.headers);
    headers.set("Access-Control-Allow-Origin", "https://mysite.ru");

    return new Response(upstream.body, {
      status: upstream.status,
      headers,
    });
  },
};

Редиректы с логикой

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const redirects = {
      "/old-page": "/new-page",
      "/blog/2024": "/archive/2024",
    };

    const target = redirects[url.pathname];
    if (target) {
      return Response.redirect(`${url.origin}${target}`, 301);
    }

    return new Response("Маршрут не найден", { status: 404 });
  },
};

После деплоя проверьте заголовок Location:

curl -I https://your-worker.workers.dev/old-page

Хранилища Workers

Workers можно связать с KV, R2, D1, Durable Objects и другими сервисами через привязки (bindings). Выбор зависит от модели данных:

• KV подходит для конфигурации, кэша и данных с преобладанием чтения;
• R2 хранит объекты и файлы;
• D1 предоставляет реляционную модель на основе SQLite;
• Durable Objects дают согласованное состояние и координацию по отдельным объектам.

Тарифы и квоты этих продуктов меняются независимо от общих лимитов Workers. Перед проектированием проверьте отдельную страницу limits выбранного хранилища.

Актуальные лимиты Workers

По состоянию на 3 октября 2026 года; источник — лимиты Workers:

CPU time учитывает активное выполнение кода, но не ожидание сетевого ответа или хранилища. Для входящего HTTP-запроса нет отдельного жёсткого лимита wall time, пока клиент остаётся подключённым; ограничения CPU, памяти и подзапросов продолжают действовать.

Проверить размер пакета до публикации:

npx wrangler deploy --outdir bundled/ --dry-run

Ориентируйтесь на Total Upload: это размер без сжатия. gzip в выводе показан для справки. Этот режим собирает пакет без публикации; успешная сборка ещё не подтверждает ответ облачного Worker.

Часть 3. Cloudflare Tunnel

Как работает Tunnel

Cloudflare Tunnel связывает cloudflared на вашем сервере с сетью Cloudflare через исходящие соединения. Публикуемому сервису не требуется входящий порт на роутере или публичный IP.

flowchart LR
    A[Посетитель] --> B[Сеть Cloudflare]
    B --> C[Cloudflare Tunnel]
    C --> D[cloudflared]
    D --> E[Локальный сервис]

Tunnel подходит для веб-приложений, staging-сред, webhook-разработки и self-hosted-инструментов. Публикация имени хоста (hostname) сама по себе делает приложение доступным из интернета; для приватного сервиса дополнительно настройте Cloudflare Access.

Создание Tunnel через Dashboard

Актуальный путь в интерфейсе:

1. Откройте Cloudflare Dashboard → Networking → Tunnels.
2. Нажмите Create a tunnel.
3. Задайте понятное имя и подтвердите создание.
4. Выберите операционную систему origin-сервера.
5. Скопируйте предложенную команду установки и запустите её на сервере.
6. Дождитесь подключения Tunnel и нажмите Continue.
7. Откройте созданный Tunnel → Routes → Add route → Published application.
8. Укажите поддомен, домен и Service URL, например http://localhost:3000.
9. Сохраните маршрут.

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

После сохранения Tunnel должен получить статус Healthy. Затем проверьте опубликованный адрес:

curl -i https://app.mysite.ru

Ожидаемый результат — HTTP-ответ приложения через Cloudflare. Статусы Inactive, Down или Degraded требуют проверки по документации Cloudflare для диагностики Tunnel.

Для следующих двух вариантов заранее установите cloudflared по инструкции Tunnel для своей ОС и проверьте cloudflared --version. Нужный локальный сервис должен уже отвечать на выбранном порту.

Локально управляемый Tunnel

Для конфигурации через файл создайте именованный Tunnel и DNS-маршруты для обоих hostname из примера. Если сервисы приватные, сначала создайте для них приложения и политики Access, как описано ниже:

cloudflared tunnel login
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel app.mysite.ru
cloudflared tunnel route dns my-tunnel grafana.mysite.ru

Сохраните следующий файл как ~/.cloudflared/config.yml. Вместо <tunnel-id> и пути к JSON укажите идентификатор и файл учётных данных, выданные командой create. Оба локальных сервиса должны быть запущены:

tunnel: <tunnel-id>
credentials-file: /path/to/.cloudflared/<tunnel-id>.json # Файл учётных данных Tunnel

ingress:
  # Каждый hostname направляет запросы в свой локальный сервис.
  - hostname: app.mysite.ru
    service: http://localhost:3000

  - hostname: grafana.mysite.ru
    service: http://localhost:3001

  # Правило по умолчанию для неизвестных hostname.
  - service: http_status:404

Запуск:

cloudflared tunnel run my-tunnel

Последнее правило http_status:404 должно завершать список ingress и не позволяет случайно направить неизвестный hostname в один из сервисов.

Quick Tunnel для временной демонстрации

cloudflared tunnel --url http://localhost:3000

Команда выдаёт временный URL на trycloudflare.com. Он работает, пока запущен процесс, и меняется при новом запуске. У Quick Tunnel нет гарантии доступности, допускается до 200 одновременных запросов; превышение даёт 429. Server-Sent Events (SSE), постоянный поток событий от сервера, не поддерживаются. Для стабильного адреса используйте именованный Tunnel. Ограничения временного режима.

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

Перенести DNS, сохранив сайт и почту

У вас есть работающая зона и доступ к регистратору. Сверьте записи, отдельно разберите прежний DNSSEC, смените NS и сравните сайт, поддомены и отправку/приём письма с исходным состоянием. Успех означает, что сервисы продолжают работать с новой DNS-зоной. Включение прокси проверяется отдельным шагом.

Обработать запрос без отдельного сервера

Нужен простой ответ HTTP или перенос старого URL. Запустите Worker локально, откройте его адрес и проверьте текст ответа; для перенаправления сравните код 301 и Location. При публикации повторите запрос к точному облачному адресу. Локальный ответ не подтверждает тариф, доступность из РФ или права аккаунта.

Webhook во время разработки

1. Запустите локальное приложение, например на порту 8080.
2. Создайте Quick Tunnel.
3. Укажите выданный HTTPS-адрес в настройках webhook.
4. Отправьте тестовое событие.
5. Проверьте журнал локального приложения и HTTP-ответ поставщику webhook.

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

Ограничение: временный URL меняется после перезапуска. Для стабильной интеграции используйте именованный Tunnel.

Внутренняя панель или Grafana

1. Создайте именованный Tunnel.
2. Создайте приложение Cloudflare Access для будущего hostname.
3. Добавьте политику, разрешающую только нужных пользователей или группу.
4. После сохранения приложения и политики Access опубликуйте hostname на локальный порт приложения.
5. Откройте адрес в приватном окне: до приложения должен появиться экран авторизации Access. Проверьте, что разрешённый пользователь получает доступ, а пользователь вне политики — отказ.

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

Сервис с самоподписанным сертификатом

Параметр noTLSVerify: true отключает проверку сертификата между cloudflared и origin. Используйте его только как временную меру для контролируемого локального сервиса. Предпочтительный вариант — доверенный origin-сертификат или HTTP на защищённом локальном соединении.

Чеклист настройки

DNS

Workers

Tunnels

Официальные источники

DNS

• Начало работы с Cloudflare DNS
• Режимы Proxied и DNS only
• Типы DNS-записей

Workers

• Создание первого Worker через CLI
• Лимиты Workers
• Примеры Workers

Tunnels

• Создание Tunnel через Dashboard
• Документация Cloudflare Tunnel
• Cloudflare Access

Следующий шаг

Для небольшого сайта со скачиваемыми файлами переходите к Workers и R2 на практике.

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov