Перенаправления на Cloudflare Workers

Быстрые ссылки

Конфигурация Cloudflare Worker
Разработка кода перенаправления
Улучшение скрипта перенаправления
Развёртывание
Будущее и возможности
Резюме

Схема Cloudflare Workers и edge‑точек

Введение

Чем ближе к пользователю выполняется код или возвращаются данные, тем быстрее ощущение отклика. Cloudflare Workers — это платформа, позволяющая запускать JavaScript на edge‑сервере Cloudflare. Вы можете перехватить запрос, выполнить логику (включая перенаправления) и вернуть ответ, не затрагивая origin‑сервер.

Опции применения широки: от статических сайтов и API‑фильтров до A/B‑тестирования и безопасных проксей. В этой статье сосредоточимся на практическом и простом случае: реализации перенаправлений (redirects) на edge.

Определение: Cloudflare Worker — выполняемый на edge JavaScript‑скрипт, который обрабатывает входящие HTTP‑запросы до того, как они достигнут origin.

Важно: Worker применяется к домену через маршруты (routes). Как только маршрут назначен, изменения в скрипте вступают в силу мгновенно.

Конфигурация Cloudflare Worker

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

Войдите в панель Cloudflare и откройте раздел Workers.
Нажмите Create a Worker, чтобы сгенерировать рабочую среду, привязанную к тестовому подпроекту (worker sub‑domain).

Кнопка создания Worker в панели Cloudflare

В интерфейсе есть три зоны: редактор кода слева, справа — HTTP‑view для ручной отправки запросов и Preview для отображения результата.

Сгенерированное тестовое окружение с поддоменом для разработки

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

Разработка кода перенаправления

Ниже — минимальный шаблон, который перехватывает fetch‑событие и передаёт запрос в функцию обработки.

addEventListener('fetch', event => {  
  event.respondWith(handleRequest(event.request))  
})  
  
/**  
 * Respond to the request  
 * @param {Request} request  
 */  
async function handleRequest(request) {  
 // Redirect logic to go here   
}

Идея: прочитать pathname из URL запроса и на его основе решить, куда перенаправить. Пример с switch, возвращающим 301:

addEventListener('fetch', async event => {  
  event.respondWith(handleRequest(event.request))  
})  
  
async function handleRequest(request) {  
  let requestURL = new URL(request.url)  
  let path       = requestURL.pathname.split('/redirect')[1]  
  
switch (path) {  
'/test1' {  
let location = 'https://mysite.com/newlocation1'  
break  
    }  
'/test2' {  
let location = 'https://mysite.com/newlocation2'  
break  
    }  
    }  
  
  if (location) {  
    return Response.redirect(location, 301)  
  }  
   
  return fetch(request)  
}

Заметки по этому варианту:

Такой код работает, но плохо масштабируется при большом количестве правил.
switch приводит к множеству условных ветвей и труден в поддержке.

Улучшение скрипта перенаправления

Лучше использовать структуру данных для хранения соответствий. Ниже — вариант с Map, который проще читать и обновлять.

const redirectMap = new Map([  
  ['/test1', 'https://mysite.com/newlocation1'],  
  ['/test2', 'https://mysite.com/newlocation2'],  
  ['/test3', 'https://mysite.com/newlocation3'],  
  ['/test4', 'https://mysite.com/newlocation4'],  
])  
  
addEventListener('fetch', async event => {  
  event.respondWith(handleRequest(event.request))  
})  
  
async function handleRequest(request) {  
  let requestURL = new URL(request.url)  
  let path       = requestURL.pathname.split('/redirect')[1]  
let location   = redirectMap.get(path)  
  
  if (location) {  
    return Response.redirect(location, 301)  
  }  
   
  return fetch(request)  
}

Преимущества Map:

Быстрая и понятная структура для ключ→значение.
Легко обновлять и импортировать из JSON/конфигураций.
Можно расширить обход соответствий: поддержка wildcard, регулярных выражений или правило по priority.

Советы по улучшению:

Добавьте логирование (через console.log) для диагностики в режиме разработки.
Обрабатывайте query string и фрагменты (hash), если это важно для перенаправления.
Позволяйте настраивать код статически (в файле) или динамически (KV, см. ниже).

Развёртывание

Когда скрипт готов, нажмите Save and Deploy. Затем в Dashboard выберите домен и вкладку Workers. Нажмите Add Route и определите маршрут, на который будет применён ваш Worker.

Выбор домена и добавление маршрута для Worker

Обычно маршрут задают как:

*.mysite.com/*

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

Добавление маршрута для применения Worker

Предупреждение: будьте осторожны с развёртыванием в проде — ошибки в коде влияют на трафик сразу. Используйте staging‑поддомен для проверки.

Дальнейшие возможности

Cloudflare предоставляет дополнительные инструменты, полезные с Workers:

KV (Key‑Value) — eventually‑consistent хранилище для хранения правил редиректов или статических данных. Подходит для большого количества правил, когда не хочется вшивать их в код.
Wrangler — CLI‑инструмент для локальной разработки, тестирования и развёртывания.
Durable Objects — для сценариев, где нужно согласованное глобальное состояние.

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

Безопасность и приватность

Ограничьте доступ к KV и управляйте правами через Cloudflare аккаунт.
Не логируйте личные данные пользователей. Если логируете URL, убедитесь, что в них нет чувствительной информации.
Для прозрачных редиректов используйте корректные коды ответа: 301 для постоянных, 302/307 для временных.
При необходимости соблюдайте требования локального законодательства (например, GDPR) при обработке персональных данных — избегайте передачи PID без явного основания.

Когда подход с edge не подойдёт

Если логика перенаправления требует сильной консистентности между edge‑узлами (например, транзакционные блокировки), KV может быть недостаточно, и нужен origin.
Для сложной бизнес‑логики, завязанной на внутренние сервисы (большие базы данных, авторизация через внутренние API), лучше обрабатывать на origin.
Если нужно детальное аудирование каждого редиректа с низкой задержкой записи, edge может усложнить архитектуру.

Альтернативные подходы

Серверные редиректы на origin (веб‑сервер или приложение). Плюсы: простота и доступ к полной логике. Минусы: задержки и нагрузка.
CDN‑правила (если CDN поддерживает статические правила редиректов). Плюсы: быстрый тест и лёгкая настройка. Минусы: ограниченный набор возможностей.
Комбинация: критические, часто запрашиваемые редиректы — на edge; остальные — на origin.

Мини‑методология внедрения редиректов на edge

Инвентаризация правил: экспортируйте текущие редиректы из CMS/серверов в CSV/JSON.
Сегментация: разделите правила на «критические» и «редкие». Критические — на edge.
Тестирование: используйте рабочее поддоменное окружение и автоматические тесты (см. ниже).
Плавное развёртывание: сначала staging, затем production‑Route с канарейкой по поддоменам.
Мониторинг: отслеживайте 4xx/5xx и ключевые метрики производительности.

Роль‑ориентированные контрольные списки

Разработчик:

Написать и покрыть тестами базовые сценарии редиректов.
Добавить логирование при ошибках.
Проверить обработку edge‑кейсов (пустой путь, query string).

Оператор / DevOps:

Настроить маршруты в панели Cloudflare и выбрать правильный поддомен.
Настроить мониторинг и оповещения по ошибкам.
Обеспечить rollback‑процедуру (вернуть предыдущий рабочий скрипт).

Product Owner:

Подтвердить список правил и политику кодов ответов (301 vs 302).
Согласовать SLA и процедуру уведомлений при изменении правил.

Шпаргалка и примеры

Коды для использования:

301 — permanent redirect
302/307 — temporary redirect

Примеры расширений:

Поддержка wildcard: преобразовать ‘/old/‘ в ‘/new/‘ с подстановкой.
Редиректы с учётом геолокации: в handleRequest использовать request.cf.country для выбора целевого URL.
Консервативный fallback: если правило не найдено — вернуть fetch(request), чтобы запрос прошёл дальше.

Простой пример wildcard‑перенаправления (псевдокод):

// проверить точное совпадение
if (redirectMap.has(path)) return Response.redirect(redirectMap.get(path), 301)
// проверить wildcard '/old/*'
for (let [key, val] of redirectMap.entries()) {
  if (key.endsWith('/*')) {
    let base = key.slice(0, -1)
    if (path.startsWith(base)) {
      let tail = path.slice(base.length)
      let location = val.replace('*', tail)
      return Response.redirect(location, 301)
    }
  }
}

Тесты и критерии приёмки

Критерии приёмки:

Для каждого правила из спецификации при запросе к старому URL клиент получает корректный код 301/302 и Location.
Если правила нет — запрос передаётся origin без изменений.
Логи ошибок присутствуют и доступны для анализа.

Тесты:

Unit tests для функции соответствия пути → location.
Интеграционные запросы к test‑поддомену Worker с реальными заголовками.
Канареечное развёртывание и ручные проверки 200 запросов для контроля.

Однострочный глоссарий

Worker — исполняемый на edge JavaScript‑скрипт; KV — key‑value хранилище Cloudflare; route — правило сопоставления URL с Worker.

Резюме

Cloudflare Workers позволяют реализовать быстрые и масштабируемые перенаправления на edge, снижая нагрузку на origin и улучшая время отклика.
Для простых наборов правил подойдёт структура Map; для большого объёма правил рассмотрите KV и Wrangler для CI/CD.
Обязательно тестируйте в staging, контролируйте развёртывание и соблюдайте требования безопасности и приватности.

Если нужно, могу прислать шаблон CI/CD для автоматизированного развёртывания через Wrangler, примеры миграции правил из CSV в KV и готовые unit‑тесты для функции обработки путей.