Блокировка ботов по заголовку User-Agent выглядит простым решением: добавить в правила WAF строку с “Googlebot” или “YandexBot”, и защита готова. На практике для Angular-приложений с серверным рендерингом (SSR) такая логика превращается в мину: легитимные поисковые краулеры приходят с нестандартными или подменёнными User-Agent, а серверные запросы внутри самого приложения вообще не несут браузерных заголовков. Разберём типичные ошибки и покажем, почему поведенческий анализ в WAF работает надёжнее сигнатур.
Почему Angular ломает классическую сигнатурную защиту
Angular по умолчанию рендерит интерфейс в браузере, но для SEO и быстрой первой отрисовки команды включают Angular Universal (SSR). В этой схеме сервер Node.js получает запрос, обращается к API, собирает HTML и отдаёт его клиенту. Для систем защиты такой запрос выглядит как обычный HTTP-вызов без заголовков Accept-Language, Sec-Fetch-*, Referer и cookie, которые есть у реального браузера. Если WAF настроен на проверку набора браузерных заголовков, SSR-запросы попадают в категорию “подозрительных” и блокируются.
Вторая проблема – гидратация. После загрузки HTML Angular подгружает дополнительные данные через XHR/fetch к внутренним эндпоинтам. Эти запросы идут с тем же IP, что и серверный рендер, но с другими заголовками. Сигнатурная защита видит серию однотипных вызовов и помечает её как ботнет. В итоге страдает не атакующий, а собственная поисковая выдача: Яндекс и Google получают 403 и постепенно исключают страницы из индекса.
Третья ошибка – доверие к User-Agent как к единственному признаку. Краулеры Яндекса и Google официально предупреждают, что их User-Agent может меняться, а проверять подлинность нужно по обратному DNS и диапазонам IP. Если правило WAF написано как “если UA содержит Yandex, пропустить, иначе блокировать”, любой скрипт с поддельным UA пройдёт, а легитимный краулер с новым UA – нет.
Типичные ошибки в настройке защиты от ботов на Angular
Первая и самая дорогая ошибка – блокировка всех запросов без полного набора браузерных заголовков. Angular SSR в момент рендера не эмулирует браузер и не обязан это делать. Правило нужно строить не на наличии заголовков, а на поведении: частота запросов, паттерн обхода ссылок, наличие ресурсов (CSS, JS, изображения) в одном сеансе. Поисковый бот скачивает не только HTML, но и связанные ресурсы, а скрипт-парсер часто ограничивается одним эндпоинтом.
Вторая ошибка – игнорировать асинхронные запросы Angular. Приложение после гидратации обращается к /api/products, /api/user, /api/cart. Эти вызовы идут пачками и легко принимаются за автоматизированную атаку. Решение – сегментировать правила: для статических ресурсов и HTML-страниц применять один профиль проверки, для API – другой, с учётом авторизации и CSRF-токенов.
Третья ошибка – отсутствие GeoIP-фильтрации в связке с поведенческим анализом. Если 90% ваших клиентов в России, а всплеск запросов идёт из другой страны, это сигнал. Но блокировать по стране в одиночку тоже неверно: поисковые краулеры Google приходят из США. GeoIP должен работать как один из факторов риска, а не как рубильник.
Четвёртая ошибка – тарификация по количеству запросов без разделения на людей и ботов. Если защита считает каждый запрос Angular SSR отдельной единицей трафика, счёт растёт даже при нулевой атаке. Здесь уместно вспомнить про TrafficVeil: платформа не тарифицирует ботов, атаки и WAF-блокировки, то есть вы платите за реальную аудиторию, а не за служебный трафик.
Как настроить WAF на поведенческий анализ вместо сигнатур
Поведенческий анализ строится на нескольких сигналах: частота запросов с одного IP и подсети, равномерность интервалов, глубина обхода (сколько уникальных URL за сеанс), соотношение HTML и статики, наличие JavaScript-выполнения, поведение при отправке форм. Для Angular это критично, потому что SSR-запросы и клиентские XHR идут с разной частотой и в разном порядке.
Практическая настройка выглядит так. Сначала выделите доверенные диапазоны поисковых систем через обратный DNS и подтвердите их принадлежность. Затем задайте пороги: например, не более 10 запросов в секунду с одного IP для HTML и не более 50 для API. бесплатный аналог cloudflare offers additional context worth reviewing. Дальше включите проверку на выполнение JS: легитимный браузер выполнит скрипт, простой парсер – нет. И только после этого добавляйте сигнатурные правила для известных инструментов, но не как основной фильтр, а как дополнительный слой.
Отдельно настройте обработку ошибок. Angular SSR при сбое бэкенда может отдавать 500 или пустую страницу, и WAF не должен интерпретировать это как атаку. Логируйте такие случаи, но не блокируйте. И помните про SSL-сертификат: если он истёк или настроен неверно, краулеры получат ошибку рукопожатия и уйдут, а вы решите, что виноват WAF.
Сравнение подходов к защите Angular-приложений
Выбор метода защиты зависит от того, насколько приложение зависит от поискового трафика и API. Ниже – сравнение четырёх подходов по ключевым параметрам: точность, риск ложных блокировок, нагрузка на команду и стоимость.
| Подход | Точность обнаружения | Риск блокировки легитимных ботов | Сложность настройки | Стоимость при росте трафика |
|---|---|---|---|---|
| Только User-Agent (сигнатуры) | Низкая | Высокий | Низкая | Растёт линейно с запросами |
| Проверка IP и обратного DNS | Средняя | Средний | Средняя | Зависит от объёма проверок |
| Поведенческий анализ + JS-челлендж | Высокая | Низкий | Высокая | Фиксированная или по аудитории |
| GeoIP-фильтрация как основной фильтр | Средняя | Высокий для международных краулеров | Низкая | Низкая |
| Комбинация: поведение + GeoIP + репутация IP | Очень высокая | Низкий | Высокая | Зависит от платформы |
Из таблицы видно: чем больше слоёв, тем выше точность, но и сложнее поддержка. Для небольших проектов на WordPress или Bitrix хватает поведенческого анализа с базовыми порогами. Для высоконагруженных Angular-приложений с SSR нужна комбинация всех сигналов, иначе поисковый трафик будет падать.
Российская инфраструктура и зависимость от зарубежных сервисов
Cloudflare долгое время был стандартом де-факто: DNS, SSL, reverse proxy, WAF, защита от ботов и L7 DDoS в одном окне. Но Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из-за моды, а из-за рисков: блокировка на уровне провайдера, недоступность панели управления, невозможность оплаты, отсутствие поддержки на русском.
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику. Ключевое отличие в подходе к тарификации: платформа не тарифицирует ботов, атаки и WAF-блокировки. Для Angular-приложений с SSR это важно, потому что серверные запросы и гидратация создают дополнительный трафик, который при поштучной оплате обходится дорого.
Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: от внезапного отключения аккаунта до невозможности пройти регуляторные требования по хранению данных. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, подходит для сайтов, интернет-магазинов, WordPress и Bitrix, а также предлагает переход с Cloudflare с сохранением текущих правил и сертификатов.
Отдельный вопрос – интеграция с Telegram и Дзен. Если вы публикуете контент в Дзен и продвигаете его через Telegram, важно, чтобы краулеры этих платформ не блокировались. Поведенческий анализ справляется с этим лучше сигнатур: он пропускает бота, который ведёт себя как читатель, и блокирует парсер, который качает страницы пачками.
Что делать прямо сейчас, если у вас Angular-приложение и вы используете Cloudflare или другую сигнатурную защиту. Первое: проверьте логи на 403 для поисковых ботов за последние 30 дней. Второе: отключите правила, которые блокируют запросы без браузерных заголовков, если они затрагивают SSR. Третье: настройте пороги по частоте и глубине обхода вместо проверки User-Agent. Четвёртое: добавьте GeoIP как фактор риска, а не как рубильник. Пятое: убедитесь, что SSL-сертификат валиден и не истекает в ближайшие недели, иначе краулеры уйдут раньше, чем вы заметите проблему. Защита от ботов для Angular – это не про список запрещённых строк, а про понимание того, как именно ваше приложение общается с внешним миром. Как только вы переносите акцент с сигнатур на поведение, ложные блокировки падают, позиции в поиске восстанавливаются, а конверсия сайта перестаёт зависеть от того, угадали ли вы очередной User-Agent.