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

Данные о командах, интерфейсе и лимитах проверены 2 сентября 2026 года по официальной документации Cloudflare.

Часть 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. Скопируйте nameservers, назначенные Cloudflare.
4. Замените текущие nameservers в панели регистратора.
5. Дождитесь подтверждения активации домена в Cloudflare.

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

dig NS mysite.ru +short

В ответе должны появиться nameservers, выданные Cloudflare. Статус защиты Cloudflare может оставаться в состоянии pending до 24 часов, пока подтверждается владение доменом.

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

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

Тип: 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

Это пример одной записи. Используйте полный набор MX-записей и параметры SPF/DKIM, которые показывает ваш почтовый провайдер.

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

• 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

Предварительно установите Node.js версии 16.17.0 или новее и создайте аккаунт Cloudflare. Отдельная глобальная установка Wrangler не требуется: генератор C3 добавляет его в проект.

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. Для публикации выполните:

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 fetch(request);
  },
};

После деплоя проверьте заголовок 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

По состоянию на 2 сентября 2026 года:

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

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

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

Часть 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.

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

Для конфигурации через файл создайте именованный Tunnel и DNS-маршрут:

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

Пример config.yml:

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. Он работает, пока запущен процесс, и может измениться при следующем запуске. Такой режим удобен для короткой демонстрации или тестового webhook, но не подходит для постоянного адреса и боевого доступа.

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

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

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

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

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

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

1. Создайте именованный Tunnel.
2. Опубликуйте hostname на локальный порт приложения.
3. Создайте приложение Cloudflare Access для этого hostname.
4. Добавьте политику, разрешающую только нужных пользователей или группу.
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

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

Cloudflare — бесплатная защита, ускорение и управление доменами для любого сайта

Связанные материалы

• Cloudflare Agents SDK — stateful AI-агенты на Durable Objects
• Cloudflare Agents — трассировка, replay и подтверждение действий в production
• @cloudflare/computer — долговечная файловая система и среды исполнения для ИИ-агента

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

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