Если конверсия с мобильного трафика внезапно упала, а форма регистрации или оплаты выдаёт ошибку 403 у реальных клиентов — виноват, скорее всего, не хакер, а ваш собственный WAF. Межсетевой экран видит тысячи запросов с одного IP-адреса оператора мобильной связи и принимает это за DDoS или брутфорс. На самом деле за этим IP сидят сотни или тысячи обычных людей — это технология CGNAT. Разбираемся, как это обнаружить и исправить, не открывая при этом дыру для реальных атак.
Что такое CGNAT и почему он создаёт проблему
CGNAT (Carrier-Grade NAT) — это технология, которую операторы мобильной связи используют из-за дефицита IPv4-адресов. Вместо того чтобы выдавать каждому абоненту уникальный публичный IP, оператор "прячет" тысячи пользователей за одним или несколькими общими адресами. Для сайта это выглядит так: с одного IP приходит трафик от сотен разных людей одновременно — разные устройства, разные браузеры, разное поведение, но один и тот же внешний адрес.
Для обычного веб-сервера это не проблема — он просто обрабатывает запросы. Но для систем защиты, которые считают запросы в единицу времени с одного IP, это выглядит как аномалия. Представьте: за минуту с одного адреса приходит 200 запросов на страницу входа. Для WAF это классический паттерн брутфорса или скрейпинга. А по факту это могут быть 150 реальных клиентов одного мобильного оператора в вашем регионе, которые просто одновременно открыли сайт после рекламной рассылки или публикации в соцсетях.
Особенно остро проблема проявляется в странах с высокой плотностью мобильного интернета — операторы объединяют огромное количество абонентов за минимальным числом внешних IP. Именно поэтому тестировать поведение сайта нужно не с обычного датацентрового IP, а именно с мобильных прокси, которые реально проходят через инфраструктуру CGNAT оператора — только так можно воспроизвести ту же картину, что видит WAF у живых пользователей.
Почему WAF видит в CGNAT угрозу
Большинство WAF-решений — Cloudflare, AWS WAF, Imperva, встроенные модули Nginx/ModSecurity — используют rate-limiting по IP-адресу как базовый механизм защиты от ботов и DDoS. Логика простая: если с одного IP больше N запросов за T секунд — блокируем или показываем капчу. Это правило отлично работает для классических атак с одного устройства, но полностью ломается на CGNAT-трафике.
Есть несколько типичных сценариев, где это выстреливает:
- Rate-limiting по IP. Лимит "100 запросов в минуту с одного IP" — нормален для датацентрового трафика, но катастрофичен для мобильного региона с миллионом абонентов за одним адресом.
- Поведенческий скоринг. Если система накапливает "репутацию" IP на основе истории запросов, то один "плохой" пользователь за CGNAT может испортить репутацию адреса для тысяч последующих честных клиентов.
- Географическая эвристика. WAF иногда помечает IP как подозрительный, если видит резкие скачки активности, несвойственные "обычному" пользователю — а поведение CGNAT-адреса именно такое: пиковые нагрузки в часы активности аудитории.
- Блок по ASN оператора. Некоторые правила WAF банят целые диапазоны ASN мобильных операторов, если ранее с этих диапазонов шли атаки — под раздачу попадают все клиенты оператора в стране.
Итог: чем жёстче настроен WAF "из коробки", тем выше шанс, что он банит не ботов, а вашу реальную мобильную аудиторию — особенно если бизнес ориентирован на страны с развитым мобильным интернетом и высокой долей CGNAT-трафика.
Чем это грозит бизнесу: потерянные клиенты и деньги
Проблема CGNAT-блокировок редко видна в стандартной аналитике. Google Analytics и Яндекс.Метрика просто не фиксируют тех, кто получил 403 ошибку на уровне WAF — такие визиты часто даже не долетают до счётчика. В итоге маркетолог видит падение конверсии, но не понимает причину, и начинает оптимизировать креативы и посадочные страницы, хотя проблема в инфраструктуре.
Реальные последствия для разных сегментов бизнеса:
- E-commerce. Покупатель с мобильного интернета не может завершить оформление заказа — форма оплаты выдаёт ошибку, корзина теряется. Прямые потери в выручке, особенно заметные после запуска рекламы в TikTok Ads или Facebook Ads, где основной трафик — мобильный.
- SaaS и регистрации. Пользователь пытается зарегистрироваться или войти в личный кабинет, получает капчу на каждом шаге или блок — уходит к конкуренту.
- Контент и реклама. Рекламный трафик с мобильных устройств массово "отваливается" на лендинге, рекламный бюджет тратится, а конверсии нет — алгоритмы рекламных площадок интерпретируют это как низкое качество аудитории и повышают цену клика.
- Служба поддержки. Растёт количество обращений "ваш сайт не открывается", "не могу зарегистрироваться" — а техподдержка не видит проблему, потому что сама заходит с десктопа через офисный Wi-Fi без CGNAT.
Самое неприятное — такие блокировки сложно диагностировать постфактум, потому что лог WAF показывает один "подозрительный" IP с огромным числом запросов, и администратор видит в этом подтверждение правильности блокировки, а не ложное срабатывание.
6 проверок с мобильных IP, чтобы найти проблему
Чтобы понять, банит ли ваш WAF честных мобильных клиентов, нужно воспроизвести реальные условия CGNAT — то есть протестировать сайт с настоящих мобильных IP разных операторов и регионов. Вот практический чек-лист из 6 проверок.
Проверка 1: Массовый заход с одного мобильного IP
Настройте несколько параллельных сессий через один и тот же мобильный IP (это естественно для прокси с CGNAT оператора) и выполните 50-100 обычных действий — открытие страниц, добавление в корзину, переход между разделами. Если после определённого порога начинает появляться капча или 403 — это первый сигнал проблемы.
Проверка 2: Смена User-Agent при одном IP
Один CGNAT-адрес обслуживает разные устройства — iPhone, Android, разные браузеры. Запустите запросы с разными User-Agent строками через один IP и проверьте, не включается ли WAF-правило "подозрительная вариативность устройств с одного адреса".
Проверка 3: Тест на критичных формах
Пройдите полный путь клиента — регистрация, авторизация, оформление заказа, оплата — именно через мобильный IP оператора. Часто WAF агрессивнее настроен именно на формах с вводом данных (логин, платёж), где риск брутфорса выше, и это первое место, где теряются реальные клиенты.
Проверка 4: Проверка по разным операторам и регионам
Поведение CGNAT отличается у разных операторов и в разных странах — где-то за одним IP скрыто 50 абонентов, где-то 5000. Протестируйте сайт с мобильных IP нескольких операторов в ключевых для бизнеса гео, чтобы понять, есть ли региональная специфика блокировок.
Проверка 5: Анализ ответа сервера по кодам и заголовкам
Фиксируйте не просто факт блокировки, а точный HTTP-код и заголовки ответа (например, cf-mitigated: challenge у Cloudflare). Это поможет понять, какой именно механизм защиты сработал — rate-limit, бот-детект или географическое правило.
Проверка 6: Долгосрочный мониторинг репутации IP
Повторяйте тест с одного и того же мобильного IP на протяжении нескольких дней. Если доступ со временем ухудшается без видимых причин с вашей стороны — значит, система накопительного скоринга "портит" репутацию адреса из-за активности других абонентов за тем же CGNAT, и это системная, а не разовая проблема.
Важно понимать:
Для таких тестов нужны именно реальные мобильные IP, а не датацентровые или обычные резидентные адреса — только трафик, прошедший через инфраструктуру оператора, точно воспроизводит паттерн CGNAT, который видит ваш WAF на реальных пользователях.
Как настроить WAF, чтобы не банить честных клиентов
После диагностики нужно скорректировать правила защиты так, чтобы не потерять уровень безопасности, но перестать банить реальных мобильных пользователей. Вот основные подходы.
| Проблема | Решение в WAF |
|---|---|
| Жёсткий rate-limit по IP | Повысить лимит для известных ASN мобильных операторов или перейти на лимит по сессии/куки вместо чистого IP |
| Накопительный скоринг репутации IP | Сократить время "памяти" репутации для диапазонов CGNAT, добавить whitelist по известным ASN операторов |
| Блок по гео/ASN целиком | Заменить полную блокировку на мягкий challenge (JS-проверка) вместо 403 |
| Жёсткая капча на формах входа | Включать капчу адаптивно — только при реальных признаках брутфорса (множественные неудачные попытки с одного аккаунта), а не по факту CGNAT-IP |
Хорошая практика — вести собственный список известных диапазонов мобильных операторов по вашим ключевым гео и давать им отдельные, более мягкие правила по сравнению с обычным интернет-трафиком. Это требует времени на настройку, но кардинально снижает число ложных блокировок.
Инструменты для тестирования с мобильных прокси
Для регулярного аудита защиты сайта удобно использовать связку из антидетект-браузера и мобильных прокси. Антидетект-браузеры (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) позволяют создавать изолированные профили с разными отпечатками устройства, а мобильные прокси обеспечивают реальный CGNAT-трафик от операторов.
Пошаговый подход к тестированию:
- Создайте несколько профилей в антидетект-браузере с разными параметрами устройства (разный User-Agent, разрешение экрана, таймзона).
- Подключите к каждому профилю мобильные прокси нужного региона и оператора — это даст реальное поведение CGNAT.
- Пройдите ключевые пользовательские сценарии: регистрация, вход, добавление в корзину, оплата.
- Зафиксируйте все случаи капчи, 403 и других блокировок, сопоставьте с настройками WAF.
- Повторите тест через резидентные прокси для сравнения — это поможет понять, специфична ли проблема именно для мобильного трафика.
Для параллельного тестирования в разных гео также полезны резидентные прокси — они помогают оценить, насколько WAF одинаково агрессивен для обычного домашнего трафика и мобильного CGNAT. Если планируете нагрузочные тесты с серверной инфраструктуры без привязки к оператору, для контрольных проверок без CGNAT-эффекта можно подключить прокси дата-центров — они дадут чистую базовую линию без искажений, свойственных мобильным сетям.
Такой комплексный подход — мобильные, резидентные и датацентровые IP в одном тесте — даёт полную картину: вы точно видите, где именно срабатывает защита и для какого типа трафика, а не гадаете по косвенным признакам в логах.
Частые вопросы
Можно ли полностью исключить CGNAT-диапазоны из правил WAF?
Не рекомендуется — это снизит защиту от реальных атак, которые тоже могут идти через мобильные сети. Правильнее смягчить пороги и перейти на мягкий challenge вместо жёсткой блокировки.
Как часто нужно проводить такие проверки?
Минимум раз в месяц и обязательно после любого изменения правил WAF или запуска новой рекламной кампании на мобильную аудиторию.
Влияет ли это на SEO?
Да — если поисковые боты или реальные пользователи с мобильных устройств получают 403, это увеличивает показатель отказов и может негативно сказаться на поведенческих метриках ранжирования.
Заключение
CGNAT — это не угроза, а особенность мобильного интернета, с которой сталкивается практически любой бизнес с мобильной аудиторией. Проблема не в самой технологии, а в том, что стандартные настройки WAF изначально не учитывают её специфику и наказывают честных пользователей за поведение, свойственное обычным мобильным сетям. Шесть проверок из этой статьи помогут быстро диагностировать, теряете ли вы клиентов из-за ложных блокировок, а точечная настройка правил WAF — вернуть конверсию без снижения уровня защиты.
Если вы планируете регулярно тестировать поведение сайта и рекламных воронок так, как это видят реальные мобильные клиенты, рекомендуем использовать мобильные прокси — они дают настоящий CGNAT-трафик операторов и позволяют находить ложные блокировки до того, как их найдут ваши клиенты.