Правила по пути и тегам, stale-if-error, revalidate на edge.
CDN и edge-кеш для продуктовых команд
CDN для статики, медиа и API без лишней операционной боли.
cdn.biletk.ru ускоряет выдачу статики, медиа и кэшируемых API-ответов без отдельной инфраструктурной экосистемы. Один origin, понятные правила кеширования, мгновенный purge и детальная наблюдаемость по трафику, ошибкам и hit ratio.
- Подходит для frontend-ассетов, HLS/DASH, скачивания файлов и read-heavy API.
- Поддерживает TLS 1.3, HTTP/3, signed URLs, rules engine и origin shield.
- Даёт эксплуатационной команде понятную картину: кэш, промахи, ошибки origin и purge.
Сводка за последние 24 часа
Очистка по пути, префиксу и тегу без полной инвалидации зоны.
- Origin origin-01.biletk.ru
- TLS Активен, автообновление
- Shield Москва
- Последний purge 42 сек назад
- Frontend assets
- Изображения и медиа
- Загрузки и релизы
- Read-heavy API
- Signed links
- Multi-origin failover
Возможности
Набор функций, который нужен в реальной эксплуатации
Не “магическая доставка контента”, а конкретные механики, которые помогают сократить нагрузку на origin и держать SLA без ручной возни.
Edge-кеш с внятными правилами
TTL по пути, заголовкам и query-параметрам, bypass для приватных ответов, stale при деградации origin и раздельные политики для статических и API-маршрутов.
Origin shield и снижение нагрузки
Один защищённый вход в origin вместо хаотичных промахов с разных PoP. Полезно для S3, nginx, object storage и legacy-бэкендов с ограниченным запасом по соединениям.
TLS, signed URLs и базовая защита
TLS 1.3, автоматическая ротация сертификатов, контроль доступа по подписи, ограничения по IP и времени жизни ссылки, фильтрация типовых всплесков трафика.
Несколько origin и failover
Primary/secondary origin, переключение по кодам ответа и таймаутам, health-check и отдельные правила для статических ассетов, видео-сегментов и пакетов обновлений.
Понятная аналитика и экспорт логов
Трафик, hit ratio, коды ответов, разрез по доменам, странам и маршрутам. Логи можно выгружать в S3-совместимое хранилище или забирать по расписанию.
Purge без боли
Инвалидация по пути, префиксу и тегам, безопасный rollout новых версий, прогрев кеша и отдельные права для эксплуатационной команды и релиз-менеджеров.
Управление и API
Подключение без длинного внедрения
Типовой сценарий занимает один рабочий слот: настроить DNS, добавить origin, включить TLS и описать пару правил кеширования. Остальное команда эксплуатации уже ведёт через панель и API.
Подключить домен
CNAME или проксирование существующего хоста без переделки origin-сервиса.
Настроить политику кеша
TTL, bypass, cache key, signed URLs, правила для API и purge по тегам.
Передать эксплуатацию команде
Мониторинг, логи, статистика, разграничение прав и рабочий публичный status.
POST /v1/zones/main/purge
{
"paths": ["/assets/app.css"],
"tags": ["release-2026-04-09"]
}
- HTTP/3 и Brotli
- Origin shield
- Сжатие изображений без перекодирования
- Статистика по доменам и маршрутам
- Ротация сертификатов
- Оповещения по 5xx и росту промахов
Сеть и операции
Инфраструктура и эксплуатация, которые выдерживают прод-нагрузку
CDN полезен только тогда, когда у команды есть контроль над кешем, понятная сеть и нормальная операционная модель. Поэтому акцент здесь на рабочих параметрах, а не на абстрактных обещаниях.
Региональные группы
Текущий контур рассчитан на проекты с аудиторией в РФ, СНГ и международной выдачей.
| Регион | Назначение | Особенности |
|---|---|---|
| Москва / Санкт-Петербург | Основная выдача и shield | Стабильный транзит, горячий кеш |
| Европа | Статика и международные пользователи | HTTP/3, TLS offload, image-heavy трафик |
| Казахстан / СНГ | Локальная выдача и разгрузка origin | Быстрый доступ к крупным файлам и обновлениям |
| APAC | Медиа и глобальные релизы | Поддержка range requests и сегментов видео |
Что видит эксплуатация
Не только “трафик вырос”, а вполне рабочая картина того, где именно начинается деградация.
- Кэш-промахи по путям. Быстро видно, какие маршруты убивают origin.
- Ошибки upstream. Разделение между сетевыми таймаутами, 5xx и проблемами TLS.
- Purge-журнал. Кто чистил кеш, по какому тегу и с каким результатом.
- Статистика по доменам. Удобно для нескольких продуктов в одном аккаунте.
Подключение
Как обычно заводят проект в CDN
Без танцев с миграцией: вначале уводят статику и загрузки, затем добавляют чувствительные маршруты, а API оставляют только там, где кеширование действительно помогает.
Выбирают зону и origin
Обычно это nginx, object storage или уже существующий media-сервер. На этом этапе определяют поведение по промахам и таймаутам.
Описывают правила
Статика получает длинный TTL, API-маршруты ограниченный кеш, а приватные ресурсы уходят через signed URLs или bypass.
Смотрят на метрики после переключения
Оценивают hit ratio, просадку по origin, рост отдачи с edge и реальную картину по 4xx/5xx в первые часы после запуска.
Тарифы
Простая сетка без “свяжитесь с нами ради каждой мелочи”
Для старта хватит базового плана. Когда появляется несколько доменов, логирование и круглосуточная эксплуатация, переходят на старшие пакеты.
Для одного проекта
Для фронтенда, лендингов, загрузок и первых релизов через CDN.
- 2 ТБ включённого трафика
- 1 origin и 1 зона
- HTTP/3, Brotli, TLS
- Purge по пути
- Email-поддержка в рабочее время
Для продукта с нагрузкой
Когда нужно несколько доменов, логирование, shield и понятная операционка.
- 20 ТБ включённого трафика
- До 5 origin и 10 зон
- Origin shield и purge по тегам
- Экспорт логов и ролевой доступ
- Поддержка 24/7 по инцидентам
Для крупных сервисов
Контрактная схема для медиа, high-load API и критичных релизных контуров.
- Индивидуальные лимиты и маршрутизация
- Выделенный NOC-канал
- Отдельные условия по SLA
- План внедрения и миграции
- Договор и закрывающие документы
Финальные параметры трафика, логов, SLA и правил обслуживания зависят от профиля нагрузки и требований к эксплуатации. Базовая сетка нужна, чтобы сразу понимать порядок бюджета.
FAQ
Вопросы, которые задают перед запуском
Здесь только рабочие вопросы: что кешируется, как очищается, как защищается origin и кто реагирует ночью, если что-то пошло не так.
Обычно нет. В большинстве случаев достаточно домена, origin-адреса и правил кеша. Изменения в приложении нужны только если вы хотите использовать purge по тегам, signed URLs или специальные заголовки для управления кешем.
Для части API да. Обычно кешируют публичные GET-ответы, каталог, карточки, справочники, конфиги и read-heavy маршруты. Авторизационные или сильно персонализированные ответы либо bypass, либо кешируются очень точечно.
Есть purge по пути, префиксу и тегам. Для frontend-ассетов часто используют versioning и длинный TTL, а purge нужен для HTML, manifest-файлов и спорных артефактов, которые нельзя ждать до естественного истечения.
Можно настроить failover на резервный origin, ограничение по таймаутам и stale-выдачу из кеша, если контент уже был на edge. Это не лечит всё, но даёт заметно более мягкое поведение при проблемах на backend-стороне.
На коммерческих пакетах есть 24/7 канал по инцидентам и рабочий NOC. Для базовых планов остаётся поддержка в рабочее время и понятный публичный status, чтобы команда не гадала, где именно проблема.
Контакты
Можно подключить один домен, а можно сразу обсудить рабочую схему под прод.
Для типового старта достаточно написать объём трафика, тип origin и какие маршруты хотите увести на CDN. Для более серьёзной схемы обсуждают логирование, SLA, shield и сценарии аварийного обхода origin.
Новые проекты, расчёт по трафику, выбор тарифа, внедрение и договор.
Оперативная связь по сбоям, деградации origin, всплескам 5xx и сетевым проблемам.
Жалобы, репорты, спорный трафик, вопросы по подписи ссылок и ограничению доступа.