Как антифрод маркетплейсов палит IPv6-прокси по поведению

Прокси поменять легко. Шаблон поведения — нет. Антифрод маркетплейсов давно забил на чёрные списки IP: адреса меняются быстрее, чем их успевают вносить. Смотрят на другое — как именно сессия двигается во времени. IPv6 тут даёт и преимущество, и головную боль: адресное пространство огромное, зато префикс /64 выдаёт пул с потрохами.

Почему IPv6 не спасает от поведенческого анализа

Допустим, у вас ротация на 10 000 адресов из /64. С точки зрения блоклиста вы чисты. С точки зрения поведенческой модели — вы один и тот же пользователь, который просто переобувается. Антифрод строит граф сессий по cookie, fingerprint браузера, TLS-отпечатку и таймингам. IP в этом графе — лишь одна вершина из пяти.

IPv6 добавляет специфику. Префикс /64 обычно принадлежит одному провайдеру или одной подсети. Модель видит: 200 разных /128, но все в одном /64. Это как 200 квартир в одном подъезде, где каждый жилец заходит на маркетплейс ровно в 14:03:17. Статистика такого не прощает.

Плюс TTL и хопы. Пакет через IPv6-прокси приходит с TTL, нехарактерным для заявленного гео. Если адрес числится в Москве, а TTL соответствует 14 хопам до Франкфурта — модель пометит расхождение.

Тайминги: что видит антифрод между запросами

Человек не кликает с точностью до миллисекунд. Робот — тоже, если специально не рандомизирует. Но рандомизация часто кривая: нормальное распределение с σ=200 мс там, где у людей логнормальное с длинным хвостом. Модель это ловит за десяток сессий.

Антифрод считает интервалы между событиями: загрузка страницы → скролл → клик по карточке → добавление в корзину. У живого пользователя медиана между просмотром и кликом — 4-12 секунд, с выбросами до минуты. У скрипта — 800 мс ровно, раз за разом.

Вот как выглядит сбор таймингов на стороне клиента, если вы хотите понять, что именно утекает:

```javascript

const marks = [];

['load', 'scroll', 'click', 'input'].forEach(evt => {

document.addEventListener(evt, e => {

marks.push({

type: evt,

t: performance.now(),

target: e.target?.tagName

});

}, { passive: true });

});

// на unload или по таймеру — отправка пачкой

```

Антифрод маркетплейса делает ровно это. И потом считает энтропию интервалов. Низкая энтропия = бот. Высокая, но с пиками на круглых значениях (1000, 2000, 3000 мс) = бот с рандомизатором.

Глубина сессии и «эффект туриста»

Глубина — сколько страниц за сессию, сколько уникальных товаров просмотрено, сколько времени на каждой. У реального покупателя глубина 8-20 страниц с воронкой: категория → фильтры → карточка → отзывы → возврат в категорию. У парсера — 500 карточек подряд, без фильтров, без отзывов, без возвратов.

Модель считает отношение глубины к времени. 500 страниц за 4 минуты — это 480 мс на страницу. Ни один человек так не читает. Даже если вы поставили задержку 5 секунд между запросами, паттерн «карточка-карточка-карточка» без промежуточных действий выглядит как конвейер.

Отдельный маркер — отсутствие «мёртвого времени». Человек отвлекается, переключает вкладку, уходит на обед. Сессия с непрерывной активностью 40 минут и нулевыми паузами длиннее 3 секунд — красный флаг.

Как антифрод связывает IPv6-адреса в одну сущность

Ключевой трюк: кластеризация по префиксу. Все /128 из одного /64 получают общий «тенант-скор». Если из /64 за сутки пришло 5000 сессий с одинаковым TLS-отпечатком — префикс помечается. Дальше каждый новый адрес из него стартует с пониженным доверием.

Второй слой — ASN и whois. IPv6-прокси часто живут в датацентрахых ASN (Hetzner, OVH, DigitalOcean). Живой пользователь с мобильного оператора и пользователь из хостинга ведут себя по-разному на уровне TCP: разные RTT, разное окно, разный паттерн ретрансмиссий. Антифрод это видит на уровне TLS handshake.

Третий слой — синхронность. Если два адреса из разных /64, но с одинаковым fingerprint браузера, заходят в одну секунду — это один оператор с пулом прокси. Модель строит граф и находит общие узлы.

Кейс: маркетплейс электроники, парсер цен

Задача — собирать цены на 40 000 SKU каждые 15 минут. Пул из 2000 IPv6-адресов, ротация по кругу, задержка 300 мс между запросами.

Через 6 часов аккаунты начали получать 403 на уровне API. Разбор показал: антифрод сгруппировал адреса по /64 (их было всего 8), посчитал медианный интервал между запросами с одного префикса — 300 мс с σ=15 мс. Живой трафик с того же префикса имел медиану 8 секунд. Расхождение в 26 раз — модель закрыла префиксы целиком.

Решение: разнести пул по 40 разным /64 у разных провайдеров, ввести логнормальную задержку (медиана 3 с, хвост до 40 с), добавить «мёртвые» паузы каждые 5-10 минут. Плюс перемешать порядок SKU, чтобы не было линейного сканирования. После этого 403 прекратились, хотя суммарная скорость упала в 4 раза.

Кейс: сравнение TLS-отпечатков через один префикс

Сервис на nginx 1.24 проксировал запросы через пул IPv6. Клиенты шли с разными User-Agent, но одинаковым TLS-отпечатком (JA3). Антифрод маркетплейса строил матрицу: префикс /64 × JA3-хэш. Один хэш на 3000 запросов из одного префикса — аномалия.

Что именно утекало: порядок cipher suites и расширений в ClientHello. Python requests, curl и реальный Chrome дают три разных отпечатка. Если ваш скрапер гоняет всё через requests, а выдаёт себя за Chrome — несоответствие видно на первом же хендшейке.

Проверить свой отпечаток можно так:

```bash

curl -s https://tls.peet.ws/api/all | jq '.tls.ja3_hash, .http2.akamai_fingerprint'

```

Решение — использовать реальный браузерный стек (Playwright с настоящим Chromium) или подбирать TLS-библиотеку под нужный отпечаток. Для распределённого пула — рандомизировать JA3 между несколькими валидными профилями, чтобы на один префикс не приходился один хэш.

Кейс: синхронные сессии из разных /64

Пул из 500 адресов, раскиданных по 50 префиксам. Вроде всё чисто. Но антифрод заметил: сессии стартуют с интервалом ровно 2 секунды, независимо от префикса. То есть планировщик задач запускал воркеры по таймеру, и они синхронно дёргали маркетплейс.

Модель посчитала кросс-корреляцию между префиксами. Высокая корреляция стартов сессий = единый источник. Дальше — бан по fingerprint, а не по IP. Адреса чистые, аккаунты — нет.

Фикс: джиттер на старте воркеров (случайная задержка 0-90 секунд), рандомизация порядка обхода, разные «расписания» для разных групп воркеров. Проверка — считать автокорреляцию временных рядов запросов по префиксам, она должна быть близка к нулю.

Что реально помогает: маскировка под человеческий ритм

Простые задержки не работают. Нужна модель поведения. Минимум — логнормальное распределение интервалов с правильными параметрами. Лучше — имитация воронки: заход в категорию, скролл, пауза на карточке, иногда возврат, иногда уход без действия.

Пример на Python с логнормальной задержкой и случайными паузами:

```python

import random, time

def human_delay(base=2.5, sigma=0.8):

d = random.lognormvariate(0, sigma) * base

time.sleep(min(d, 45))

def session_flow(session):

session.get("/catalog/phones")

human_delay(1.5)

for _ in range(random.randint(3, 8)):

session.get(f"/product/{random.randint(1000, 9999)}")

human_delay()

if random.random() < 0.3:

time.sleep(random.uniform(10, 90))

```

Такая сессия уже не выглядит конвейером. Но помните: антифрод смотрит не только на клиент, но и на серверные метрики — распределение по времени суток, гео, устройство.

Роль IPv6-прокси в этой картине

Хороший IPv6-прокси даёт то, чего не даёт IPv4: огромный пул адресов и естественное распределение по префиксам. Если провайдер выдаёт /64 целиком под клиента, вы контролируете всю подсеть и можете раскидывать сессии так, чтобы они не слипались. Это важнее, чем количество адресов.

Для задач, где нужен стабильный пул с контролем над префиксами и без соседей по /64, который портит репутацию, — lexic.ml даёт изолированные IPv6-подсети с 2015 года. Это не отменяет поведенческий анализ, но убирает один класс проблем: чужие сессии из вашего же префикса.

Метрики, которые стоит мониторить самому

Прежде чем антифрод забанит, вы можете увидеть проблему у себя. Считайте: медиану и σ интервалов между запросами, распределение глубины сессий, долю «мёртвого времени», корреляцию стартов между воркерами, разнообразие JA3 и User-Agent на префикс.

Если медиана интервалов меньше 1.5 секунды — вы уже подозрительны. Если σ меньше 100 мс — вы робот. Если на один /64 приходится больше одного TLS-отпечатка на сотню запросов — префикс скоро пометят. Эти три проверки ловят 80% проблем до того, как их увидит маркетплейс.

Дальше — вопрос дисциплины. Ротация ради ротации не помогает. Помогает имитация человека: неровный ритм, паузы, воронка, разнообразие отпечатков. Прокси — лишь фундамент, поведение — стены.