Проблема в том, что устройства воспроизведения – это зоопарк. Производители ТВ, приставок и мобильных плееров годами не приводят User-Agent к единому виду, а прошивки обновляются без предупреждения. Скрейперы этим пользуются: подделывают UA популярных плееров или, наоборот, приходят с пустой строкой, которая выглядит как сломанное устройство. Отличить одно от другого по одному заголовку невозможно, зато сломать воспроизведение у целой группы зрителей – легко. Именно поэтому блокировка по User-Agent считается ошибкой, а не рабочей практикой.
Дальше разберём, как нестандартные UA ломают стриминг, почему анализ паттернов скачивания сегментов надёжнее, и какие решения на рынке позволяют защититься от скрейперов, не задевая живую аудиторию. Если вы ищете, чем заменить Cloudflare в России, этот материал поможет выбрать подход, который не превратит защиту в источник потерь конверсии и трафика.
Блокировка по User-Agent выглядит как решение, которое можно внедрить за один вечер. В логах reverse proxy видно, что 70 процентов запросов к плейлистам приходит с подозрительных строк вида python-requests/2.31, curl/8.4.0 или Go-http-client/1.1. Инженер открывает конфиг nginx или правило WAF, добавляет несколько регулярных выражений, и через час скрейперы отваливаются. Метрика “заблокировано запросов” растёт, отчёт для руководства выглядит убедительно, а нагрузка на origin падает на 30-40 процентов. Именно эта мгновенная обратная связь и делает фильтрацию по UA таким популярным первым шагом в защите стриминга.
Второй мотив проще и человечнее: UA это единственное поле запроса, которое читается без состояния. Не нужны ни сессии, ни счётчики, ни Redis, ни анализ временных рядов. Правило живёт прямо в edge-узле, срабатывает за микросекунды и не требует хранить историю запросов клиента. Для команды из двух человек, которая одновременно держит CDN, биллинг и транскодинг, это существенная экономия сил. Кажется, что задача “защита от скрейперов” закрыта малой кровью.
Третий соблазн в том, что инструмент выглядит точным. В отличие от rate limiting, который режет всех подряд при всплеске трафика, UA-фильтр бьёт по конкретной строке. Можно составить белый список: Safari, Chrome, tvOS, Tizen, WebOS, Android TV, Roku. Всё остальное в теории это боты. Такая логика хорошо ложится на модель угроз “снаружи приходят только скрейперы”, и она же становится ловушкой.
Стриминговый сервис обслуживает не браузеры. Он обслуживает плееры, встроенные в прошивки телевизоров, приставок и медиаплееров. Производитель Smart TV часто ставит свой HTTP-клиент, и его User-Agent не имеет ничего общего с каталогом популярных браузеров. В логах встречаются строки вида MStar/1.0, Hisense/VIDAA, PhilipsTV/1.0, SmartTV/1.0, Dalvik/2.1.0 (Linux; U; Android 9; AFTMM Build/…), а иногда просто Player/1.0 без вендора и версии. Некоторые прошивки отправляют пустой User-Agent или строку из двух символов.
Дальше начинается каскад. Администратор добавляет в белый список то, что видит в аналитике за неделю. Через месяц выходит обновление прошивки на LG или Samsung, строка меняется, и часть зрителей получает 403 на запрос плейлиста. Симптомы при этом размытые: у человека “не грузится фильм”, поддержка получает обращения без технических деталей, а в логах чисто, потому что запрос отсечён на edge и до приложения не дошёл. Диагностика такой поломки занимает дни, а иногда недели.
Есть и обратная сторона. Скрейперы тривиально подделывают User-Agent: подставить строку Mozilla/5.0 (SMART-TV; Linux; Tizen 6.0) это одна строка кода. Фильтр по UA не отличает подделку от настоящего телевизора, потому что смотрит только на заголовок, который клиент контролирует полностью. В итоге легитимные устройства страдают, а те, от кого защищались, проходят дальше. Ошибка здесь не в настройке, а в самом принципе: блокировать скрейперов по User-Agent нельзя, потому что этот признак одновременно и подделывается атакующей стороной, и непредсказуемо меняется у легитимной.
Отдельно стоит учесть требования к доступности. Для стриминга отказ воспроизведения на части парка устройств это не техническая мелочь, а прямая потеря подписок и репутации. Регуляторные требования к качеству услуги и жалобы абонентов приходят быстрее, чем команда успевает разобрать, какая именно прошивка попала под правило. Поэтому UA-фильтр стоит рассматривать как временную заплатку на часы, а не как элемент постоянной архитектуры защиты.
Казалось бы, что может быть проще: увидел в логах подозрительный User-Agent, добавил его в блок-лист, и скрейпер отвалился. На практике именно этот шаг чаще всего и ломает воспроизведение у реальных зрителей. Причина в том, что парк устройств, с которых люди смотрят стриминг, гораздо грязнее и разнообразнее, чем принято думать, когда правила пишутся по логам десктопного браузера.
Начнём с самых массовых. Samsung Smart TV на Tizen отдаёт строки вида Mozilla/5.0 (SMART-TV; Linux; Tizen 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/6.0 TV Safari/537.36. Внутри неё нет ни слова Chrome, зато есть Safari, хотя это не Safari и не WebKit в чистом виде. LG webOS выглядит похоже: Mozilla/5.0 (Web0S; Linux/SmartTV) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.31 Safari/537.36 WebAppManager. Последний токен WebAppManager не встречается больше нигде, и именно по нему удобно резать, но вместе с ним вы режете половину телевизоров LG в стране.
Дальше идут приставки и ТВ-боксы. Android TV на Xiaomi Mi Box или SberBox может отдавать Dalvik/2.1.0 (Linux; U; Android 9; MiBox4 Build/PI), если плеер собран на нативном ExoPlayer без WebView. Apple TV шлёт AppleCoreMedia/1.0.0.19J101 (Apple TV; U; CPU OS 15_1 like Mac OS X; ru_ru), и это вообще не Mozilla-подобная строка. Ряд плееров на прошивках Hisense и Philips добавляют к стандартному UA суффиксы вида HbbTV/1.4.1 (+DRM;+PVR;+DLNA) или NetCast 4.0. Ни один из этих агентов не похож на «нормальный браузер», и все они означают живого платящего зрителя.
Мобильные плееры не лучше. VLC на Android отдаёт VLC/3.0.18 LibVLC/3.0.18 без всякой Mozilla. Встроенный плеер в приложении на iOS может ходить как MyApp/2.4.1 CFNetwork/1335.0.3 Darwin/21.6.0. Если сервис смотрят через Kodi, в логах появится Kodi/19.4 (Linux; Android 11) Android/11 Sys_CPU/armv8l App_Bitness/64 Version/19.4-(20.5.0). Скрейпер, кстати, тоже легко прикидывается любым из этих агентов: подменить строку в requests или curl это одна строчка кода.
Теперь сценарий отказа. Администратор видит всплеск запросов с UA, содержащим слово, которого нет у Chrome и Firefox, добавляет подстроку в блок-лист и уходит спать. Утром падает конверсия и растёт отток: часть аудитории получает 403 на манифест, плеер показывает вечный спиннер, зритель уходит к конкуренту и не возвращается. Хуже того, отказ воспроизведения на телевизоре почти невозможно диагностировать удалённо: пользователь не пришлёт вам DevTools, он просто напишет в поддержку «не работает». А если вы режете по HbbTV или WebAppManager, вы теряете не случайных людей, а владельцев конкретных моделей ТВ, то есть целые сегменты платной аудитории.
Ключевой вывод звучит жёстко: блокировать скрейперов по User-Agent – ошибка. Строка UA не является ни аутентификатором, ни доказательством намерения. Она подделывается за минуту, а легитимные Smart TV, приставки и мобильные плееры генерируют такой зоопарк значений, что любое правило неизбежно задевает реальных зрителей. Фильтровать трафик нужно по поведению, а не по самоназванию клиента.
Легитимный плеер и скрейпер обращаются к одним и тем же файлам: манифест, затем сегменты .ts или .m4s. Разница не в том, что они запрашивают, а в том, как. альтернатива cloudflare offers additional context worth reviewing. Именно поэтому анализ паттернов скачивания сегментов работает там, где фильтрация по User-Agent бесполезна: он смотрит на поведение, а не на самопредставление клиента.
Начните с частоты. Живой плеер скачивает сегмент за секунды до его воспроизведения: при длине сегмента 6 секунд интервал между запросами держится в районе 5-7 секунд, с естественным дрейфом из-за буферизации и сети. Скрейпер, который тянет весь сезон на сервер, запрашивает сегменты быстрее реального времени: 10-40 запросов в секунду, без пауз на воспроизведение. Порог в 2-3 сегмента в секунду уже отсекает основную массу парсеров, не задевая зрителей на медленном мобильном интернете.
Второй сигнал – порядок. Легитимный просмотр почти всегда последовательный: сегмент 1, 2, 3, 4. Перемотка даёт скачок вперёд, но после него воспроизведение снова идёт линейно. Скрейпер обходит каталог хаотично или, наоборот, идеально линейно на скорости x20. Показательна доля запросов вне окна воспроизведения: если клиент запрашивает сегмент из середины третьего сезона, не запросив предыдущие, это не просмотр, это выкачивание архива.
Третий сигнал – параллельность. Браузер и Smart TV держат 2-6 одновременных соединений на домен, редко больше. Скрейпер открывает 50-200 параллельных потоков на один IP или, что чаще, распределяет их по пулу прокси. Считайте не только абсолютное число, но и отношение параллельных запросов к числу уникальных сессий с одного адреса.
По отдельности каждый признак даёт ложные срабатывания. Девятилетний телевизор с медленным Wi-Fi буферизует рывками, и его интервалы выглядят неровно. Пользователь с плохим каналом может запрашивать сегменты с опережением, чтобы сгладить просадки. Поэтому решение принимается по совокупности, а не по одному порогу.
| Метод | Что ловит | Риск ложного срабатывания | Когда применять |
|---|---|---|---|
| Порог частоты запросов | Массовое скачивание быстрее реального времени | Низкий при пороге 2-3 сегмента/с | Базовый уровень защиты для всех |
| Анализ порядка сегментов | Обход архива без просмотра | Средний: перемотки и превью | С учётом окна воспроизведения |
| Число параллельных потоков | Распределённые загрузчики | Низкий при пороге 8-10 соединений | В связке с частотой |
| Полнота запросов манифеста | Скрейперы, пропускающие инициализацию | Средний: старые плееры | Как дополнительный сигнал |
| Комбинация признаков с оценкой | Сложные парсеры с эмуляцией | Низкий при калибровке на своих логах | Основной метод для крупных сервисов |
Ключевой момент: реакция на подозрительный паттерн не обязана быть блокировкой. Работающая схема – градуированный ответ.
Практика показывает: сервис, который перешёл с фильтрации по User-Agent на анализ паттернов, снимает блокировки с 3-7% легитимных устройств, которые до этого не могли смотреть видео, и одновременно точнее ловит парсеры. Ложные срабатывания падают не потому, что фильтр стал мягче, а потому, что он перестал оценивать клиента по строке, которую тот сам о себе написал.
Технически это ложится на reverse proxy перед CDN-слоем: он видит и манифесты, и сегменты, и может считать интервалы без хранения тяжёлых логов. Если инфраструктура уже завязана на зарубежный сервис, стоит смотреть в сторону российского аналога Cloudflare, который умеет L7 DDoS, защиту от ботов и GeoIP-фильтрацию на уровне платформы, а не только на уровне отдельного правила. TrafficVeil, например, объединяет DNS, SSL, reverse proxy, WAF и аналитику в одном контуре и не тарифицирует срабатывания WAF и блокировки ботов, что для стриминга с пиковыми нагрузками важнее, чем кажется на этапе выбора.
После того как вы отказались от блокировки по User-Agent и перевели защиту на анализ паттернов скачивания сегментов, встаёт вопрос инфраструктуры. Многие стриминговые сервисы годами сидели на Cloudflare: удобно, дёшево на старте, знакомая панель. Но в 2026 году это решение всё чаще создаёт проблемы именно тем, кто работает на российскую аудиторию. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Для видеосервиса это означает не гипотетические риски, а живые жалобы зрителей: буферизацию, обрывы, отказы на этапе авторизации.
Отсюда и запрос: чем заменить Cloudflare так, чтобы не потерять защиту от скрейперов, но вернуть стабильность воспроизведения. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса сразу по трём направлениям: доступность, оплата, юридические требования. Замена Cloudflare не сводится к переносу DNS. Нужен reverse proxy с полноценным набором функций: L7 DDoS, WAF-блокировки, защита от ботов, GeoIP-фильтрация, управление SSL-сертификатом и, что критично для стриминга, аналитика запросов на уровне сегментов.
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе. Для стримингового сервиса важны две вещи. Первая: TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, то есть зритель из Новосибирска и зритель из Берлина получают поток без посредников, которые могут быть заблокированы. Вторая: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Если скрейпер выкачивает ваши сегменты гигабайтами, вы не платите за отражение этой активности. На Cloudflare такая модель привела бы к росту счёта именно в момент атаки.
Как выбирать российский аналог Cloudflare под задачу защиты стриминга от скрейперов. Смотрите на четыре вещи.
TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, но для стриминга важна именно связка reverse proxy плюс аналитика на уровне сегментов. Настройка перехода с Cloudflare занимает предсказуемое время: перенос DNS, выпуск SSL-сертификата, включение reverse proxy, перенос правил WAF и настройка порогов для сегментных запросов. TrafficVeil предлагает переход с Cloudflare, и это не маркетинговая формулировка, а процедура с понятными шагами.
Что в итоге. Ошибка блокировать скрейперов по User-Agent стоила вам части зрителей. Следующая ошибка, которую стоит избежать, это остаться на инфраструктуре, которая ограничивает доступ к вашему сервису из России, либо перейти на аналог, который не умеет анализировать паттерны скачивания. Выбирайте альтернативу Cloudflare по тому, как она различает бота и телевизор, а не по длине списка функций на лендинге. Защита от ботов, L7 DDoS и WAF-блокировки должны работать незаметно для зрителя и без сюрпризов в счёте. Тогда конверсия сайта и лидогенерация не просядут из-за технических решений, которые вы принимали, глядя на удобство админки, а не на опыт просмотра.
Практический шаг, который стоит сделать до того, как включать любые фильтры на продакшене: соберите корпус реальных User-Agent своих зрителей за последние 30 дней. Выгрузите из логов reverse proxy или CDN-прослойки список уникальных значений с частотой обращений и разбейте его на три группы: браузеры, мобильные приложения и Smart TV с приставками. В третьей группе почти наверняка окажутся десятки строк вида Tizen/6.0, Web0S/7.0, okhttp/4.x, ExoPlayer/2.x, Roku/DVP-12.x и полное отсутствие заголовка у части плееров. Если вы блокируете по regex, эти строки уйдут в бан вместе со скрейперами, и вы узнаете об этом из всплеска жалоб в поддержку, а не из мониторинга. Пропишите в правилах явный allow-list для каждой найденной платформы, а фильтрацию стройте поверх анализа паттернов скачивания сегментов: частота запросов .ts или .m4s, строго последовательный обход плейлиста без перемоток, параллельность выше 8-10 потоков на один IP, отсутствие запросов к манифесту после старта. Эти признаки дают на порядок меньше ложных срабатываний, чем строковый матчинг.
Дальше проверьте, чем вы вообще закрываете периметр. Если защита висит на зарубежном сервисе, помните: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare, поэтому часть вашей аудитории может не дойти до плеера задолго до вопроса о скрейперах. TrafficVeil как российский аналог Cloudflare объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, не тарифицирует ботов, атаки и WAF-блокировки и подходит для сайтов, интернет-магазинов, WordPress и Bitrix. Запустите тестовый трафик на 5-10 процентах аудитории, сравните долю успешных стартов воспроизведения до и после, и только затем переносите правила на весь периметр.
]]>