Как распознать фрод у поставщика прокси: подмены, “миксы”, фальшивые гео

Если вы покупаете мобильные прокси на масштабе, то каждая третья проблема с конверсиями, воронкой и скоростью запуска — это не «креатив не зашел», а фрод со стороны провайдера. Хорошая новость: 80% фрода видно в первые 24 часа, если знать, где смотреть. В статье разложу по полочкам признаки подмен, «миксов», фальшивой геолокации и маскировок ASN, дам простые тесты и чек-листы, а в конце — расчеты, сколько вы теряете без аудита.

Подмена — это когда вам продают одно, а фактически подают другое. Самые частые сценарии: вы берете «стикки» (sticky) с закреплением IP на 24–72 часа, а получаете бэкконнект-агрегатор, где каждый запрос уходит через новый IP из пула. Или объявленные «мобильные 4G» на деле — датацентровые диапазоны с реверс-DNS типа vps-xxx.provider.com и ASN, не принадлежащий мобильному оператору. «Микс» — это когда под одним логином провайдера крутится смесь из мобильных, резидентских, датацентровых IP и даже прокси из публичных Wi‑Fi, а вы об этом узнаете только когда летят KPI.

Как это выглядит на графиках и в логах? Во-первых, аномальная ротация сессий без вашего запроса: sticky-сессия должна держаться стабильно (например, 30–60 минут или дольше при keep-alive), но вы видите смену исходного IP в течение 5–7 минут или на каждый новый TCP‑коннект. Во-вторых, плавающий ASN: сегодня AS8383 (условный мобильный оператор), завтра AS12389 (магистральный оператор связи), послезавтра — AS49505 (датацентр). В-третьих, «залипание» портов: один и тот же порт SOCKS5 отдает трафик из разных подсетей /24, что характерно для бэкконнект‑гейтов. В-четвертых, нестабильный TTL и jitter: мобильная сеть обычно дает ожидаемый разброс RTT, но не 1 мс — 120 мс — 17 мс в рамках одного пинга к ближайшему узлу; такие скачки свойственны цепочкам прокси.

Почему это опасно? Любой антифрод движок и антибот система (в рекламных сетях, маркетплейсах, социальных платформах, платежных шлюзах) отслеживает консистентность окружения: IP, ASN, гео, время жизни сессии, TLS/JA3, заголовки (например, X‑Forwarded‑For), паттерн авторизации, частоту ошибок handshake. «Микс» разбивает целостный «фингерпринт», из-за чего растет доля подозрительных событий, увеличивается стоимость клика/лида, блокируются кабинеты, падает допуск к рекламным инвентарям и тестовым бюджетам. Вы теряете не только деньги сейчас, но и репутацию аккаунтов, накопленные трасты и исторические лимиты.

Дополнительные маркеры подмен: несоответствие заявленного оператора MCC/MNC (по факту реверс-DNS указывает на DC), отсутствие rDNS вовсе, неожиданные HTTP 407/403 с прокси-ошибками от софта провайдера, а также «магический» аптайм IP 24/7 без перерывов — живые мобильные IP за NAT редко держатся в сети месяцами без смены. Еще один тревожный сигнал — нереалистичная цена за «статический мобильный» (например, 2–3$ за месяц), потому что реальный CAPEX/OPEX (SIM, оборудование, трафик, стойки, поддержка) такого не позволяет. И наконец, проверка tracert: маршрут, который стартует с датацентрового узла в другой стране, а потом «прыгает» к мобильному ASN, часто означает GRE‑туннель или прокладку, а не честный мобильный источник.

• Проверяйте стабильность ASN и подсети /24 по каждой сессии; фиксируйте смены более 1–2 раз в сутки как красный флаг.
• Сравнивайте rDNS, whois и BGP-анонсы (есть ли у ASN мобильного оператора собственные анонсы этого префикса).
• Логируйте время жизни sticky-сессии: при честном мобайле — стабильно; при «миксе» — частая незаявленная ротация.

Удобнее всего ловить подмены на входе, в приемочных тестах. Сформируйте автоматический прогон: по API проверяете IP через 3–5 баз геолокации (MaxMind, IP2Location, DB-IP), затем whois/ASN (RIPE, RADb), rDNS, запускаете короткий traceroute до магистральных узлов вашего региона, измеряете RTT/стабильность, проводите тест keep-alive на 30–60 минут с фиксацией исходного IP и ASN каждую минуту. Дополнительно сохраняйте HTTP-заголовки, TLS-отпечаток (JA3), проверяйте WebRTC/DNS‑утечки в вашем стекe. Если хотя бы два источника противоречат друг другу (например, MaxMind видит RU‑mobile, а RIPE показывает /24 у датацентра в другой стране) — поставщик идет в карантин и повторную проверку. Ваша задача — не доказать мошенничество, а доказать консистентность. Все остальное — повод остановить закупку.

Когда нужен «железобетон», собирайте артефакты: сырые логи с таймстемпами, результаты whois/ASN (скрин + текст), traceroute, rDNS, совпадающие записи из разных БД геолокации, дампы JA3/TLS, список портов и прокси‑эндпоинтов. Идеально — сохранять 2–3 параллельные сессии на одном логине, чтобы показать, что разные потоки «смотрят» в разные ASN/подсети одновременно. Отправляйте поставщику краткий отчёт с таймлайном и четкими вопросами. У честного провайдера найдется техническое объяснение (например, плановая миграция узла в пределах оператора), а у «миксера» начнутся отговорки или предложение «заменить пул».

Фальшивое гео — это не просто «Москва вместо Казани». Это любые несостыковки: MaxMind видит RU‑MOW, IP2Location — NL, а traceroute начинает путь из датацентра в другом регионе. Маскировка ASN — когда вам показывают запись в одной базе, но реальный BGP‑анонс идет от другого автономного системы. Такие «косметические правки» ломают таргетинги, модерацию, таргет‑пулы и распределение трафика по регионам в рекламных системах. В итоге CPM растет, охват падает, а кабинеты получают дополнительные проверки из‑за нестабильного источника.

• Сверяйте гео и ASN минимум по 3 независимым источникам: MaxMind, IP2Location, RIPE NCC (whois).
• Делайте короткий traceroute к региональным CDN/узлам — маршрут должен начинаться в нужной стране/регионе.
• Проверяйте DNS/WebRTC утечки: если DNS‑сервер публичный и в другой стране — это флаг.

Попросите 3–5 тестовых эндпоинтов. Прогоните их через автоматическую форму: определение ASN (whois), rDNS, гео (две БД), один ping и traceroute до ближайшего узла (например, магистрального IX вашего региона). Проверьте соответствие MCC/MNC в названии узла (часто прокладывают подсказки прямо в rDNS). Если два из пяти IP имеют несоответствия, не платите — попросите другой пул и повторите тест. Этот «скрининг» снимает до 60% вероятности купить фальшивое гео.

Запустите длительную sticky‑сессию (30–60 минут), снимайте IP/ASN/гео каждую минуту, фиксируйте JA3/TLS и заголовки, собирайте WebRTC/DNS, снимайте throughput (скорость) коротким тестом на 5–10 МБ. Посмотрите на стабильность: честный мобильный прокси держит один ASN и гео, допускает небольшие смещения по городам внутри региона, но не прыгает по странам. Traceroute должен показывать первые hop’ы у местного оператора, а не у DC в другой стране. Если IP «выходит» в магистраль через датацентр, который не принадлежит оператору и не является его официальным аплинком, у вас туннель/прокладка.

Три типовые: 1) доверились красивому дашборду поставщика без внешних верификаций; 2) проверили только HTTP-прокси, а в SOCKS5 канал поставщик отдает другой пул (и наоборот); 3) не зафиксировали начальные метрики (baseline) и теперь спорят на уровне «кажется/не кажется». Всегда ведите журнал: ID прокси, дата/время, ASN, гео из трех БД, traceroute хопы 1–5, rDNS, скорость, потери пакетов. И не забывайте, что антибот‑системы смотрят на консистентность всей сессии: прокси может быть «честным», но ваш браузер льет DNS или WebRTC в другой регион — результат будет тем же, что и при фальшивом гео.

Грамотный процесс — это не «взять дешевле», а «взять предсказуемо». Постройте воронку из трех ступеней: 1) пресейл‑скрининг (5 минут, отсекает очевидный фрод); 2) приемочные испытания (24 часа на выборке из 20–50 IP); 3) постоянный мониторинг (1–5% массива ежедневно). Автоматизируйте проверки по API, храните артефакты, заведите внутренние SLA и штрафные условия. Не забывайте про экономику: стоимость плохого пула — это не цена подписки, а рост CPL/CPA, сгоревшие креативы, потерянный траст и замороженные кабинеты.

• Пропишите техническую спецификацию запроса: оператор, регион, тип ротации, формат (HTTP/SOCKS5), sticky‑параметры, аптайм.
• Сделайте приемочный чек‑лист: что, где и как меряем, какие пороги брака (например, более 5% несоответствий — возврат).
• Внедрите дашборд мониторинга: ASN/гео/RTT/потери/скорость/ошибки авторизации, тревоги и автокарантин пулов.

Ваш бриф должен звучать конкретно: «Нужны мобильные прокси RU, регион ПФО, операторы МТС/Мегафон (MCC/MNC указать), sticky 60 минут без незаявленной ротации, 100 эндпоинтов, протоколы HTTP(S)/SOCKS5, whitelisting по IP и логин/пароль, гарантия по ASN (мобильный), аптайм не ниже 99%, замена при несоответствии 1:1 в течение 24 часов, доступ к тесту 24 часа, отчетность по подсетям /24». Чем детальнее спецификация, тем сложнее «миксерам» проскочить. Попросите образец rDNS/ASN на тест, укажите, что фиксируете traceroute/JA3, — добросовестный провайдер это оценит, фродер — исчезнет.

Скрипт должен 1) выдать 20–50 соединений (sticky и обычные), 2) каждую минуту сохранять IP/ASN/гео/RTT/jitter, 3) пробежать короткий throughput‑тест, 4) снять rDNS, 5) зафиксировать JA3/TLS и заголовки, 6) проверить DNS/WebRTC, 7) сравнить результаты с порогами. Пример порогов: — не более 1 смены ASN за 60 минут; — совладение реверс‑DNS с мобильной средой; — совпадение страны в 3/3 баз гео (допустимо 2/3 при свежем диапазоне, но с примечанием); — потери пакетов не выше 1–2% на коротких трассах; — отсутствие незаявленных ротаций. Итог — PDF/JSON‑отчет с вердиктом «годен/брак/повторная проверка».

Допустим, у вас 500 прокси на пул. Средний бюджет на трафик — 50 000 $/мес. “Микс” даёт +8% к CPL из‑за ростa проверок и снижения траста — это лишние 4 000 $. Плюс при «развале» гео теряете ~5% показов в нужном регионе — минус охват и рост CPM еще на 1 000–1 500 $. Стоимость автоматизации приемки и мониторинга — условно 700–1 200 $/мес (сервер + разработка/поддержка). Экономия с первого месяца — 3 000–4 500 $. На горизонте квартала — 9 000–13 500 $, не считая сохраненного траста аккаунтов и экономии времени команды. Добавьте «страховку» в контракт: штраф за более чем 3% IP с несоответствием ASN/гео — и фрод уходит к конкурентам.

Подмены, «миксы» и фальшивые гео — главная скрытая утечка бюджета в мобильных прокси. По нашим наблюдениям в LTE CENTER, без аудита у 20–35% новых пулов появляются критичные несоответствия в первые 72 часа. Внедрение простого пресейл‑скрининга и приёмочных тестов снижает риски вдвое, а постоянный мониторинг — почти до нуля, при этом экономия в деньгах достигает 6–9% месячного бюджета. Чек‑лист на завтра: 1) перепишите спецификацию запроса поставщику; 2) запустите 24‑часовой приёмочный тест на текущем пуле; 3) подключите ежедневный мониторинг 1–5% IP; 4) зафиксируйте SLA и штрафы в контракте; 5) обучите команду читать ASN/гео/traceroute. Это не «паранойя», это культура закупки инфраструктуры.

Вопрос 1: Как быстро понять, что передо мной “микс”, а не честный мобильный пул?
Ответ: Проведите 5‑минутный скрининг на 3–5 IP: сравните ASN/гео по трем базам, посмотрите rDNS и первые хопы traceroute. Если ASN прыгает, rDNS похож на датацентр, базы гео не согласуются — это «микс».

Вопрос 2: Sticky‑сессия прервалась через 10 минут, это нормально?
Ответ: Нет, если заявлено 30–60 минут без ротации. Фиксируйте логи (IP/ASN/время), запросите замену или возврат, занесите поставщика в карантин до повторной проверки.

Вопрос 3: Разные базы гео показывают разные города внутри одного региона — это критично?
Ответ: Нет, для мобильных сетей это допустимо. Критично — расхождение по странам/регионам и смена ASN на не‑мобильный или датацентровый.

Вопрос 4: Какой минимальный набор метрик хранить?
Ответ: IP, ASN, подсеть /24, rDNS, гео (3 источника), traceroute 3–5 хопов, RTT/jitter, ошибки авторизации, JA3/TLS, WebRTC/DNS, время жизни sticky‑сессии.

Вопрос 5: Что вписать в контракт, чтобы защититься?
Ответ: SLA по ASN/гео, допустимые пороги брака, срок замены 24 часа, штрафы за несоответствия, обязательный тест‑период, обязанность поставщика сообщать о миграциях/работах.