CGNAT в мобильном интернете — что это? Во многих мобильных сетях абоненту не выдают «чистый» публичный IPv4 напрямую. Трафик проходит через Carrier-Grade NAT (CGNAT) — NAT оператора, где один публичный IPv4 разделяется между множеством пользователей. Снаружи вы выглядите как часть большого пула, а выходной IPv4 может меняться заметно чаще, чем у домашнего провайдера.
Для мобильных прокси это даёт типичную «двойную картину»: общий мобильный IPv4 часто помогает трасту (похож на реального пользователя), но мешает IP‑whitelist (allowlist), потому что белый список требует стабильного IP. Ниже — практический разбор без мифов: репутация общих IP, риски соседей, когда нужен sticky, когда — ротация и что предлагать клиенту, если у него строгие требования по whitelist.
1) Как устроен CGNAT: NAT поверх NAT
Домашний NAT делает ваш роутер: устройства внутри сидят на приватных адресах (192.168.x.x), а наружу выходят через один публичный IPv4. В мобильных сетях часто добавляется ещё один NAT на стороне оператора. Получается схема NAT444:
- Устройство → приватный IP
- Сеть оператора → внутренний адрес абонента (часто 100.64.0.0/10 — shared space)
- CGNAT → пул публичных IPv4 на тысячи абонентов
Чтобы различать пользователей под одним IPv4, CGNAT переводит порты (PAT/NAPT). Поэтому «ваш внешний адрес» на практике — это ещё и внешний порт плюс время жизни сессии.
2) Почему mobile IP trust часто выше
Для антифрода мобильный трафик выглядит иначе, чем датацентровый: другой ASN, другая статистика сессий, естественная динамика. Во многих сценариях это даёт преимущество:
- Мобильный ASN — сигнал «это не серверный хостинг».
- Смешанный «живой» фон: много обычных пользователей в том же пуле.
- Ротация снижает накопление подозрений на одном IP, если вы не генерируете токсичный трафик.
Именно поэтому мобильные прокси часто «живут» дольше в SMM/рекламе, чем датацентры. Но общая репутация — палка о двух концах.
3) Репутация IP и «бан через соседей»
Общий IP = общая репутация. Если кто-то из «соседей» на том же внешнем IPv4 спамит, ломает логины или парсит слишком агрессивно, последствия могут прилететь всем:
- IP попадает в стоп‑листы из‑за жалоб/спама.
- Сервис повышает уровень проверок (captcha, 2FA, 429) из‑за всплесков запросов.
- Массовые логины с одного IP триггерят «automation».
Вывод: мобильный пул требует лимитов, профилей и грамотного выбора режима: sticky сессия или rotating IP.
4) Почему whitelist IP проблема при CGNAT
IP‑whitelist работает только если внешний IP стабилен. При CGNAT он часто нестабилен по определению:
- Частая смена IPv4 (балансировка/переподключение/изменение контекста).
- Порт‑зависимость: внешний порт может быть непредсказуемым, а некоторые сетевые сценарии к этому чувствительны.
- Коллатеральные эффекты: сервисы не всегда хотят «доверять» shared‑IP так же, как выделенному.
Поэтому запрос клиента «дайте IP, я добавлю в whitelist» нужно переводить в плоскость решений, а не спорить с физикой сети.
5) Sticky vs ротация: практическое правило
Sticky — удерживаем один внешний IP максимально долго. Ротация — регулярно меняем IP.
Sticky нужен, когда:
- Есть логин‑сессии и риск проверок при смене IP (соцсети, рекламные кабинеты, маркетплейсы).
- Долгая работа в админке/веб‑приложении с токенами и сессиями.
- Нужно временно «поддержать» allowlist (хотя бы на часы).
Ротация лучше, когда:
- Парсинг/мониторинг с большим количеством однотипных запросов.
- QA‑проверки гео, локальной выдачи, карт.
- Нужно быстро уйти от 429/captcha и взять «свежий» выход.
6) Что предложить клиенту, если whitelist обязателен
Рабочих сценариев несколько:
- Статическая точка выхода: клиент ходит на ваш шлюз/прокси с фиксированным IP, а уже дальше трафик уходит в мобильную сеть. Whitelist работает по IP шлюза, но сервис видит датацентровый адрес.
- Выделенный мобильный IPv4: дороже и доступен не всегда, зато сохраняет мобильный ASN и даёт стабильность.
- Не IP‑whitelist, а whitelist идентичности: mTLS, подпись запросов, OAuth, токены с ротацией. IP — как дополнительный фактор, а не единственный замок.
- IPv6: если сервис поддерживает IPv6, иногда allowlist проще строить там (с учётом особенностей privacy‑адресов).
7) Рекомендации провайдеру мобильных прокси
- Снижайте конкуренцию клиентов за один внешний IP: шардируйте пулы.
- Вводите лимиты и backoff на ошибки, особенно 429/403.
- Отдельные профили под SMM (sticky) и под парсинг (ротация + паузы).
- Мониторьте репутацию: доля captcha, аномалии, стоп‑листы.
8) Короткий чек‑лист для клиента
- Если нужен whitelist — уточните, принимает ли сервис диапазоны или строго один IP.
- Для логинов — sticky 30–120 минут и минимум переподключений.
- Для парсинга — ротация + лимиты + корректные заголовки + кеширование.
- Помните про «соседей»: репутация общего IP меняется со временем.