Зачем тестировать WAF и бот‑защиту именно с мобильных сетей
Cloudflare стоит между вашим сайтом и посетителем и решает судьбу каждого запроса: пропустить, записать в лог, показать challenge (JS/CAPTCHA) или заблокировать. Для владельца сайта это удобно — часть защиты “из коробки” и управляется из панели.
Но мобильный трафик отличается. У операторов часто используется CGNAT: тысячи абонентов выходят в интернет через одни и те же публичные IP. Плюс частая смена адресов, разные ASN, особенности IPv6/IPv4, in‑app браузеры и WebView. В итоге защиты легко “перестараться” и получить false positive — блокировку легитимного клиента.
Поэтому тестирование Cloudflare WAF с мобильных IP — это нормальная QA‑практика: проверить, не режете ли вы аудиторию lifecell/Vodafone/Kyivstar и другие мобильные сети.
Что именно делает Cloudflare на стороне владельца сайта
Ложные блокировки проще диагностировать, когда вы понимаете слои защиты:
- WAF Managed Rules — управляемые правила Cloudflare/партнёров против типовых атак. У каждого правила есть rule ID и категория.
- Custom rules — ваши собственные условия и действия (Block/Challenge/Log/Skip и т.д.).
- Bot protection — механизмы оценки бот‑трафика (в зависимости от плана: Bot Fight Mode / Super Bot Fight Mode / Bot Management).
- Rate limiting / DDoS — отдельные механизмы по частоте запросов и объёму атак.
Ключевой момент: false positive может прийти из любого слоя. Поэтому “выключили WAF — не помогло” иногда означает, что сработал бот‑фильтр или лимитирование.
Как выглядит false positive в реальной жизни
- Жалобы “с мобильного не открывается”, а по Wi‑Fi всё нормально.
- Проблема привязана к одному оператору или региону.
- Сбой появился после изменения правил, включения антибот‑режима или обновления managed rules.
- Блокируется конкретный путь: /login, /checkout, /api/*, /graphql и т.д.
В мобильных сетях один IP часто “делят” многие люди, и репутация такого IP может быть подпорчена чужими действиями. Поэтому задача — не обвинить оператора, а найти конкретное правило и аккуратно его поправить.
Где искать причину блокировки в Cloudflare Dashboard
Стартовая точка — Security / Security Center → Events (Security Events). Это основной журнал, где вы увидите:
- Action (Block/Challenge/Log/Allow);
- Источник (Managed rules, Custom rule, Bot, Rate limiting);
- Rule ID, название правила/пакета;
- Ray ID — идентификатор запроса (очень полезен);
- IP клиента, ASN, страну, user‑agent, host, URI, метод.
Если пользователь видит страницу ошибки Cloudflare, попросите его скопировать Ray ID. Это быстро сокращает поиск.
Почему мобильные сети чаще попадают под “ложные” триггеры
- CGNAT и высокая “плотность” запросов с одного IP.
- Смена IP во время сессии или между запросами.
- Необычные заголовки у in‑app браузеров и старых устройств.
- Смешанный IPv6/IPv4 маршрут и разные профили репутации.
- Паттерны API: частые POST, параллельные вызовы, отсутствующие рефереры.
Как мобильные прокси помогают проверить правила “в бою”
Мобильные прокси с украинских операторов — инструмент, чтобы воспроизвести условия реального клиента и собрать доказательства: время, Ray ID, событие в журнале, rule ID. В QA это полезно для:
- Проверки разных мобильных ASN Украины;
- Сравнения “домашний интернет vs мобильная сеть” при одинаковых действиях;
- Быстрой валидации, что исключение не слишком широкое.
Важно: цель — сделать защиту точнее и не резать легитимный трафик, а не “обходить” правила в продакшене.
Пошаговый алгоритм: как диагностировать и исправить false positive
Шаг 1. Соберите минимальные данные
- URL/endpoint и метод (GET/POST).
- Время инцидента (±10 минут).
- Ray ID (если есть).
- Оператор (lifecell/Vodafone/Kyivstar), устройство/приложение, был ли VPN.
Шаг 2. Воспроизведите через мобильный прокси нужного оператора
Поднимите мобильный IP этого оператора и повторите сценарий (логин/корзина/API). Если воспроизводится — фиксируйте Ray ID или точное время.
Шаг 3. Найдите событие в Security Events
Фильтруйте по host, URI, action, а при наличии Ray ID — ищите по нему. На этом шаге главное — понять какой слой вынес решение: managed/custom/bot/rate.
Шаг 4. Определите “что именно” сработало
- Managed rule (WAF Managed Rules) с конкретным rule ID?
- Ваше custom rule?
- Событие связано с bot‑защитой?
- Сработало ограничение по частоте?
Шаг 5. Внесите минимально достаточную правку
Лучше начинать с мягких мер:
- перевести правило в Log (временный “предохранитель”);
- сделать узкое исключение для конкретного URI/метода/ASN;
- и только если нужно — менять чувствительность или отключать правило целиком.
Как ставить исключения безопасно
Для managed rules правильный механизм — Exceptions / Skip: вы пропускаете исполнение конкретных правил/наборов для запросов, которые подходят под выражение (например, POST на /api/auth/login для определённого ASN).
Что хорошо включать в условие исключения:
- host (если поддоменов несколько),
- path (/api/* или точный endpoint),
- method (часто проблема только в POST),
- content-type (JSON vs form-data),
- ASN (когда проблема строго операторская).
Чего лучше избегать:
- глобального Allow “по Украине” или “по всем мобильным ASN” без ограничения по URI;
- отключения всего ruleset вместо одной проблемной проверки;
- исключений только по user-agent (его легко подделать).
Кейс: клиентов lifecell блокирует WAF‑правило
Типичная история для личных кабинетов и API:
- Поступают жалобы: “с lifecell не могу войти/оформить заказ”.
- С Wi‑Fi не воспроизводится, с другого оператора — тоже.
- Проблема появилась после усиления WAF или обновления managed rules.
Как воспроизвели
- Запустили мобильный прокси lifecell.
- Повторили логин (POST /api/auth/login или /login).
- Сняли время и Ray ID.
Что нашли в логах
В Security Events видно: action = Block/Managed Challenge, источник = WAF Managed Rules, rule ID указывает на конкретную проверку (часто “подозрительный” параметр или JSON‑поле). Также заметно, что ASN — lifecell и с IP идёт много запросов из‑за CGNAT.
Как исправили
- Сначала перевели действие правила в Log именно для этого endpoint.
- Затем создали узкое исключение (Skip) для POST на /api/auth/login, сохранив остальную защиту.
- Добавили серверную валидацию на бэкенде (компенсация снижения WAF‑контроля на точке входа).
Как проверили
- Повторили логин с lifecell‑прокси — блоков нет.
- Убедились, что события ушли в Log, а не в Block.
- Прогнали негативные тесты, чтобы исключение не стало “дырой”.
Что ещё смотреть
- логи origin (доходит ли запрос до сервера),
- логи приложения (ошибки авторизации, которые маскируются под “WAF”),
- просадки по URL/ASN после изменений,
- рост 4xx/отказов из‑за challenge.
Профилактика: как уменьшить false positive
- тестируйте изменения заранее на мобильных IP разных операторов,
- усиливайте правила постепенно (Log → Challenge → Block),
- разделяйте политики для /api, /admin, /checkout,
- не полагайтесь на WAF как на единственный барьер — валидируйте на сервере,
- следите за блоками по мобильным ASN Украины.
Чек‑лист: тестирование Cloudflare WAF с мобильных IP
- Пройти ключевые сценарии (главная/поиск/логин/форма/checkout/API).
- Повторить с 2–3 украинских операторов (разные ASN).
- Для любой проблемы фиксировать Ray ID.
- В Security Events определить слой и правило.
- Править минимально: Log → узкий Skip/Exception → негативные тесты.
- Проверить метрики после правок (блоки, 4xx, конверсия).
Вывод
Если ваш сайт работает на Cloudflare, мобильный трафик Украины нужно учитывать как отдельный “класс” клиентов. Мобильные прокси помогают быстро воспроизводить проблемы и настраивать WAF/бот‑защиту точечно: по конкретному правилу и конкретному endpoint, без глобального отключения защиты.