CDN как платформа управления трафиком: больше чем кеширование
Сеть доставки контента (CDN) давно переросла роль пассивного кеширующего прокси. Сегодня это активный слой маршрутизации, который принимает решения о судьбе каждого запроса до того, как он достигнет origin-сервера. Cloudflare, Fastly и AWS CloudFront предоставляют механизмы для обработки трафика на основе десятков параметров: от страны пользователя до версии протокола TLS.
Практическая ценность такого подхода в том, что вы можете менять логику обработки запросов без правки кода приложения. Перенаправить мобильных пользователей на облегченную версию сайта, отправить трафик из ЕС на сервер во Франкфурте для соблюдения GDPR или заблокировать парсинг контента ботами - все это настраивается на границе сети за минуты.
Ключевые возможности интеллектуальной маршрутизации в CDN:
- Геолокационная маршрутизация по стране, региону или континенту
- Разделение трафика по типу устройства через анализ User-Agent
- Маршрутизация на основе заголовков запросов: язык, кастомные метки, API-ключи
- Выделение трафика по протоколу: HTTP/2, WebSocket, gRPC
- Автоматический фейловер между дата-центрами при сбоях
- Защита от ботов и DDoS-атак через rate limiting и WAF
- Выполнение кастомного кода на edge через Workers и Lambda@Edge
В этой статье мы разберем каждый сценарий с конкретными примерами конфигураций для трех основных провайдеров. Все инструкции проверены в production-средах и готовы к применению.
Правила маршрутизации: как направить трафик по нужному пути
Правила маршрутизации в CDN работают как набор условий и действий. Условие определяет, какой трафик попадает под правило, а действие указывает, что с ним делать: перенаправить, модифицировать заголовки, заблокировать или отправить в конкретный origin pool.
Порядок правил критически важен. Первое совпавшее условие применяется немедленно, а последующие игнорируются. Это отличает CDN от классических балансировщиков, где часто используется взвешенное распределение. Подробнее о балансировке на уровне приложений мы рассказывали в руководстве по HAProxy ACL.
Геолокационная маршрутизация: направляем пользователя в ближайший дата-центр
Гео-маршрутизация снижает задержку и помогает выполнять требования по локализации данных. Пользователь из Токио получает ответ от сервера в Азии, а не ждет пакет из Вирджинии. Разница в RTT может составлять 150-200 мс, что критично для API и интерактивных приложений.
Cloudflare: используйте Transform Rule с условием по полю ip.geoip.country. Создайте правило в разделе Rules → Transform Rules → Modify Request Header. Укажите условие (ip.geoip.country eq "DE") и действие - установку заголовка X-Origin-Region: eu. На стороне origin читайте этот заголовок для выбора базы данных или логики обработки.
Fastly: в VCL-сниппете проверяйте заголовок req.http.X-Geo-Country-Code, который Fastly добавляет автоматически. Пример кода для редиректа:
if (req.http.X-Geo-Country-Code == "US") {
set req.backend = F_us_origin;
} else {
set req.backend = F_eu_origin;
}AWS CloudFront: заголовок CloudFront-Viewer-Country содержит двухбуквенный код страны. Настройте Origin Groups с разными origins для каждого региона и используйте CloudFront Functions для выбора бэкенда по этому заголовку. Сравнение подходов к геофильтрации для разных провайдеров мы разбирали в статье по сравнению Cloudflare, AWS WAF и самописных решений.
Маршрутизация по типу устройства: адаптация контента под клиента
Разделение мобильного и десктопного трафика на уровне CDN избавляет бэкенд от необходимости анализировать User-Agent при каждом запросе. Вы можете направить мобильных пользователей на отдельный origin с облегченными страницами или на поддомен m.example.com.
Cloudflare: поле cf.device_type принимает значения mobile, desktop или tablet. Создайте Redirect Rule: условие (cf.device_type eq "mobile") и целевой URL с подстановкой https://m.example.com$1. Правило сработает до обращения к origin, экономя ресурсы сервера.
Fastly: анализируйте req.http.User-Agent через регулярные выражения в VCL. Типовой паттерн для мобильных устройств:
if (req.http.User-Agent ~ "(Mobile|Android|iPhone)") {
set req.http.X-Device-Type = "mobile";
}AWS CloudFront: заголовок CloudFront-Is-Mobile-Viewer содержит true или false. Используйте его в Cache Behavior для выбора разных origin paths или в Lambda@Edge для модификации запроса.
Маршрутизация по заголовкам и протоколу: тонкая настройка трафика
Заголовки запросов дают максимальную гибкость. Вы можете маршрутизировать трафик по языку (Accept-Language), версии API (X-API-Version), признаку тестового трафика (X-Canary: true) или типу аутентификации.
Пример для мультиязычного приложения на Cloudflare: создайте Transform Rule с условием (http.request.headers["accept-language"][0] contains "ru") и добавьте заголовок X-Language: ru. Origin читает этот заголовок и возвращает локализованный контент без разбора Accept-Language на бэкенде.
WebSocket-трафик требует отдельной обработки из-за долгоживущих соединений. На Cloudflare включите WebSocket в разделе Network и создайте правило маршрутизации по заголовку Upgrade: websocket. Направьте такой трафик в выделенный origin pool с увеличенными таймаутами. На AWS CloudFront используйте отдельный Cache Behavior с протоколом WebSocket и повышенным idle timeout.
Для A/B-тестирования через заголовки удобно использовать кастомный заголовок X-Experiment. Cloudflare Workers или Lambda@Edge могут устанавливать этот заголовок на основе cookie или хеша IP-адреса, а последующее правило маршрутизации направляет трафик в нужный origin. Готовые конфигурации для A/B-тестов и канареечных развертываний смотрите в руководстве по HAProxy ACL.
Отказоустойчивость: автоматическое переключение при сбоях
CDN выступает первым эшелоном фейловера. При отказе основного дата-центра трафик автоматически уходит на резервный, а пользователи не замечают сбоя. Время переключения зависит от настроек health check: при интервале проверки 30 секунд и пороге в 2 провала фейловер произойдет через 60 секунд после отказа.
Настройка Health Checks и Origin Groups
Cloudflare Load Balancing:
- Создайте монитор в разделе Traffic → Health Checks. Укажите URL для проверки (например,
/health), метод GET, ожидаемый код ответа 200. Настройте интервал 30 секунд и таймаут 5 секунд. - Создайте пул origins: добавьте IP-адреса или доменные имена основного и резервного серверов. Привяжите созданный монитор к пулу.
- Настройте правило в разделе Load Balancing: укажите пул и регион (или оставьте глобальным). Включите опцию Session Affinity, если приложение требует закрепления сессии.
Fastly: health check настраивается в VCL. Пример конфигурации с резервным бэкендом:
backend F_primary {
.host = "primary.example.com";
.port = "443";
.probe = {
.url = "/health";
.timeout = 2s;
.interval = 15s;
.window = 5;
.threshold = 3;
}
}
backend F_secondary {
.host = "secondary.example.com";
.port = "443";
.probe = {
.url = "/health";
.timeout = 2s;
.interval = 15s;
.window = 5;
.threshold = 3;
}
}
sub vcl_recv {
set req.backend = F_primary;
if (!req.backend.healthy) {
set req.backend = F_secondary;
}
}AWS CloudFront Origin Groups: при создании Origin добавьте второй origin и объедините их в группу. Настройте Failover Criteria: укажите коды ответов (например, 500, 502, 503, 504), которые считаются отказом. CloudFront автоматически переключится на второй origin при совпадении критериев.
Защита на границе сети: блокировка ботов и DDoS-атак
Фильтрация вредоносного трафика на уровне CDN снижает нагрузку на origin и предотвращает инциденты безопасности. Объемные DDoS-атаки поглощаются распределенной сетью CDN, а боты блокируются до того, как доберутся до приложения. Выбор облачной защиты от DDoS с интеграцией через Terraform мы детально разобрали в статье по сравнению Cloudflare и альтернативных сервисов.
Rate Limiting и Bot Management: настройка и примеры
Cloudflare Rate Limiting: создайте правило в разделе Security → WAF → Rate Limiting Rules. Укажите поле для группировки (обычно IP), порог срабатывания (например, 100 запросов за 10 секунд) и действие - Block или JS Challenge. Для защиты API установите более строгие лимиты: 30 запросов в минуту с одного IP.
Cloudflare Bot Management автоматически классифицирует трафик по типам ботов. В разделе Security → Bots включите Bot Fight Mode для блокировки confirmed bots. Для тонкой настройки используйте поле cf.bot_management.score в правилах WAF: при score ниже 30 применяйте капчу, ниже 10 - блокируйте.
Fastly Rate Limiting через VCL: используйте встроенный счетчик ratelimit. Пример блокировки при превышении 60 запросов в минуту с одного IP:
sub vcl_recv {
if (ratelimit.check_rate(client.ip, 60, 60s) > 60) {
error 429 "Too Many Requests";
}
}AWS WAF Rate-based Rule: в консоли AWS WAF создайте правило с типом Rate-based rule. Укажите лимит 100 запросов за 5 минут, источник - IP address. Добавьте условие для блокировки запросов с подозрительными User-Agent через строковые паттерны: curl, python-requests, scrapy.
Edge Computing: выполнение кода ближе к пользователю
Edge computing позволяет выполнять кастомную логику обработки запросов в точках присутствия CDN. Код запускается в дата-центре рядом с пользователем, что исключает задержку на обращение к origin. Типовые сценарии: персонализация контента, аутентификация запросов, A/B-тестирование, модификация заголовков для маршрутизации.
Cloudflare Workers: пример маршрутизации с гео-редиректом
Worker на JavaScript обрабатывает запрос до обращения к origin. Пример гео-редиректа с проверкой страны через request.cf.country:
export default {
async fetch(request) {
const country = request.cf.country;
const url = new URL(request.url);
if (country === 'US') {
url.hostname = 'us.example.com';
} else if (['DE', 'FR', 'NL'].includes(country)) {
url.hostname = 'eu.example.com';
}
return fetch(url.toString(), request);
}
}Ограничения Workers: время выполнения CPU - 10 мс на бесплатном тарифе, 50 мс на платном. Количество запросов: 100 000 в день бесплатно. Для задач, требующих длительной обработки, лучше использовать традиционные origin-серверы.
AWS Lambda@Edge: модификация заголовков для маршрутизации
Lambda@Edge выполняется в ответ на события CloudFront: viewer request, origin request, origin response, viewer response. Для маршрутизации используйте viewer request - функция срабатывает до выбора origin.
Пример на Node.js, добавляющий заголовок X-Device-Type на основе User-Agent:
exports.handler = async (event) => {
const request = event.Records[0].cf.request;
const userAgent = request.headers['user-agent']?.[0]?.value || '';
let deviceType = 'desktop';
if (/Mobile|Android|iPhone/.test(userAgent)) {
deviceType = 'mobile';
} else if (/iPad|Tablet/.test(userAgent)) {
deviceType = 'tablet';
}
request.headers['x-device-type'] = [{ key: 'X-Device-Type', value: deviceType }];
return request;
};После этого настройте Cache Behavior в CloudFront для маршрутизации по заголовку X-Device-Type. Ограничения Lambda@Edge: максимальное время выполнения 5 секунд для viewer request, память до 128 МБ. Функции развертываются только в регионе us-east-1.
Сравнение провайдеров: Cloudflare vs Fastly vs AWS CloudFront
Выбор CDN для интеллектуальной маршрутизации зависит от приоритетов: простота настройки, гибкость правил, интеграция с существующей инфраструктурой или стоимость. Таблица ниже суммирует ключевые различия.
| Критерий | Cloudflare | Fastly | AWS CloudFront |
|---|---|---|---|
| Гибкость правил | Transform Rules, Page Rules - визуальный редактор | VCL - полный контроль через код | CloudFront Functions + Lambda@Edge |
| Edge Computing | Workers (JavaScript, до 50 мс CPU) | Compute@Edge (Rust, JavaScript, Go) | Lambda@Edge (Node.js, Python, до 5 с) |
| Защита от DDoS | Встроенная, без ограничений по объему | Базовая, требует настройки | AWS Shield Standard (включен), Advanced опционально |
| WAF | Встроенный, managed rules | Через партнеров или VCL | AWS WAF, интеграция с marketplace |
| Сложность настройки | Низкая - UI и готовые шаблоны | Высокая - требует знания VCL | Средняя - много сервисов AWS |
| Стоимость | Бесплатный тариф, Pro от $20/мес | От $50/мес + трафик | Pay-as-you-go, зависит от объема |
| Интеграция с экосистемой | Независимый провайдер | Независимый провайдер | Глубокая интеграция с AWS (S3, EC2, Lambda) |
Cloudflare оптимален для быстрого старта и комплексной защиты. Fastly выбирают команды, которым нужен полный контроль над логикой через VCL. AWS CloudFront - естественный выбор для инфраструктуры на AWS, особенно с S3 и Lambda. Для геофильтрации веб-приложений с готовым кодом на Python, Node.js и Go обратитесь к практическому руководству по геофильтрации в 2026 году.
Типичные ошибки и их решение
При внедрении правил маршрутизации в CDN системные администраторы регулярно сталкиваются с одними и теми же проблемами. Разберем их с методами диагностики и исправления.
Неправильный порядок правил. Правила обрабатываются последовательно, и первое совпадение останавливает цепочку. Если правило блокировки ботов стоит после правила гео-маршрутизации, бот из заблокированной страны все равно попадет в origin. Диагностика: включите логирование всех правил в Cloudflare (Security → Events) или Fastly (Real-Time Logging). Исправление: размещайте правила безопасности перед правилами маршрутизации.
Конфликт условий. Два правила с пересекающимися условиями дают непредсказуемый результат. Пример: правило для мобильных устройств и правило для конкретной страны - мобильный пользователь из этой страны попадет только под первое. Решение: объединяйте условия в одном правиле через логическое И.
Игнорирование кеширования при маршрутизации. Если CDN кеширует ответ, последующие запросы не проходят через правила маршрутизации. Пользователь получает закешированный ответ, даже если правила изменились. Исправление: настройте Cache Key так, чтобы он включал заголовки, влияющие на маршрутизацию (язык, устройство, регион). В Cloudflare это делается через Cache Key в разделе Caching.
Отсутствие мониторинга. Без алертов о срабатывании фейловера вы рискуете узнать об отказе основного дата-центра от пользователей. Настройте уведомления: в Cloudflare - Notification в разделе Notifications, в Fastly - алерты через Status Page, в AWS - CloudWatch Alarms на метрики CloudFront.
Превышение лимитов edge computing. Workers и Lambda@Edge имеют жесткие ограничения по времени выполнения и памяти. Функция, которая работает в тесте, может упасть в production при пиковой нагрузке. Мониторьте метрики: cpu_time_ms для Workers, Duration и Max Memory Used для Lambda@Edge. Оптимизируйте код или вынесите тяжелую логику на origin.