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

Содержание

Почему IPv6 сам по себе не спасает
Тайминги — главный маркер
низкий коэффициент вариации = машина
Порядок запросов и «холодный старт»
Согласованность сессии
TLS-фингерпринт и HTTP/2
Поведение при ошибках и retry
Кейс: парсер Ozon на IPv6-пуле
Кейс: самовыкуп в Wildberries
Кейс: скрейпинг Amazon
Что реально проверять перед запуском
Итог

Прокси решает только половину задачи. Вторая половина — не выдать себя действиями. Антифрод маркетплейсов уже года три как перестал смотреть исключительно на IP. Сейчас в приоритете поведенческие паттерны: тайминги, последовательность запросов, энтропия сессий. IPv6 тут не панацея — адресов много, но поведение остаётся поведением.

Разберу, как именно антифрод-движки ловят IPv6-прокси по тому, что аккаунт делает, а не по тому, откуда он пришёл.

Почему IPv6 сам по себе не спасает

IPv6 даёт 2^128 адресов. Кажется, что можно крутить их бесконечно. На практике провайдер выделяет клиенту /64 или /48 — это блок, который антифрод видит целиком. Заходят сто аккаунтов с разных адресов из одного /64 — для системы это одна подсеть. Один ASN. Один владелец.

Wildberries, Ozon, Amazon используют геолокацию по префиксу, а не по конкретному адресу. Если /64 привязан к дата-центру в Нидерландах, а аккаунт заявляет Москву — расхождение фиксируется сразу. Плюс IPv6-блоки дата-центров давно в репутационных базах: Spamhaus, MaxMind, IPQualityScore. Антифрод не блокирует по одному признаку, но складывает в скоринг.

Есть нюанс с MTU. IPv6 не фрагментирует пакеты на маршрутизаторах — только источник. Если прокси-сервер отдаёт PMTU 1280 вместо 1500, это видно в TCP-квитировании. Некоторые антифроды (в частности, решения на базе TLS-фингерпринта) это ловят через JA3/JA4.

Тайминги — главный маркер

Человек не кликает каждые 400 мс. Человек не отправляет форму ровно через 2.5 секунды после загрузки страницы. Боты и автоматизация — кликают. Антифроды строят распределение интервалов между действиями и сравнивают с эталоном.

Пример: парсер карточки товара на Python через requests делает запросы с интервалом 800-900 мс. Стандартное отклонение — 40 мс. У живого пользователя σ обычно 300-800 мс. Такой паттерн — красный флаг, даже если IP чистый и IPv6-адрес свежий.

Вот как выглядит проверка таймингов на стороне антифрода (упрощённо):

```python

import statistics

def timing_score(intervals_ms):

if len(intervals_ms) < 5:

return 0.0

mean = statistics.mean(intervals_ms)

stdev = statistics.pstdev(intervals_ms)

cv = stdev / mean if mean else 0

низкий коэффициент вариации = машина

if cv < 0.15:

return 0.9

if cv < 0.35:

return 0.5

return 0.1

```

Коэффициент вариации ниже 0.15 — почти гарантированно скрипт. Живой юзер редко даёт такую стабильность. Прокси тут ни при чём — палится ритм.

Порядок запросов и «холодный старт»

Новый аккаунт с идеальным IPv6, но который первым делом идёт в корзину, минуя главную, каталог и карточку — подозрителен. Антифроды маркетплейсов строят граф переходов. Нормальный путь: главная → категория → карточка → отзывы → корзина. Бот часто прыгает напрямую по API-эндпоинтам или через deep link.

Ещё маркер — отсутствие статических ресурсов. Живой браузер тянет CSS, JS, шрифты, картинки. Headless-парсер часто берёт только HTML. Антифрод видит: запрос на `/product/12345` есть, а запросов на `/static/app.js` и `/img/thumb/...` нет. Это ловится на уровне CDN-логов и передаётся в антифрод.

Проверить себя можно так — посмотреть, какие заголовки реально уходят:

```bash

curl -6 -v -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \

-H "Accept: text/html,application/xhtml+xml" \

-H "Accept-Language: ru-RU,ru;q=0.9" \

-H "Accept-Encoding: gzip, deflate, br" \

https://marketplace.example/product/12345 2>&1 | grep -E "^>"

```

Если `Accept-Encoding` без `br`, `Sec-Fetch-*` отсутствуют, а `User-Agent` устарел — это отпечаток бота, независимо от IPv6.

Согласованность сессии

IPv6-прокси часто ротируется. Каждый запрос — новый адрес из /64. Для антифрода это выглядит как аккаунт, который за пять минут зашёл из Москвы, Казани и Франкфурта. Даже в пределах одной страны смена /64 каждые 30 секунд — аномалия.

Живой пользователь держит сессию на одном адресе. Мобильный оператор может сменить адрес при переключении LTE/Wi-Fi, но не десять раз за минуту. Антифроды считают частоту смены IP на сессию. Больше двух-трёх за сессию — флаг.

Плюс cookie и localStorage. Прокси-пул часто не синхронизирует состояние между воркерами. Аккаунт приходит с одним `session_id`, а через запрос — с другим. Или вообще без cookie, хотя до этого они были. Это ловится тривиально на уровне балансировщика.

TLS-фингерпринт и HTTP/2

JA3 и JA4 — хеши параметров TLS-хендшейка. Chrome 120 и Python requests дают разные отпечатки. IPv6-прокси не меняет TLS-стек клиента. Если аккаунт заявляет Chrome, а JA3 соответствует OpenSSL из Python — расхождение.

HTTP/2 добавляет ещё слой: порядок и приоритеты фреймов SETTINGS, WINDOW_UPDATE. Реальные браузеры шлют их в определённой последовательности. Библиотеки — иначе. Антифроды Cloudflare, Akamai, DataDome это давно используют.

Вот пример, как выглядит расхождение: аккаунт логинится с UA Chrome 121, но TLS-отпечаток — Go (стандартный `net/http`). Маркетплейс видит несоответствие и повышает скор. Прокси не поможет — проблема на уровне клиента.

Поведение при ошибках и retry

Бот при 429 или 403 делает retry через фиксированный интервал. Человек — либо ждёт, либо уходит. Антифроды специально отдают ошибки и смотрят на реакцию. Если через 1.0 секунды ровно приходит повторный запрос — это машина.

E-commerce антифроды (Forter, Riskified, Sift) строят поведенческие модели на десятках тысяч сессий. Паттерн «ошибка → retry через равные интервалы» — классический признак автоматизации. IPv6-ротация тут только усугубляет: каждый retry с нового адреса выглядит как распределённая атака.

Кейс: парсер Ozon на IPv6-пуле

Конфигурация: 500 IPv6-адресов из /48, ротация каждые 60 секунд, Python + requests, интервал 500 мс. Через 40 минут — блокировка всех аккаунтов.

Причина: коэффициент вариации интервалов 0.08, отсутствие запросов на статику, одинаковый JA3 на всех «пользователях». Антифрод Ozon (собственная разработка на базе ML) сгруппировал сессии по поведенческому кластеру и забанил пул целиком.

Решение: увеличили jitter интервалов до 200-1500 мс, добавили загрузку CSS/JS через headless Chromium, синхронизировали cookie между воркерами, разбили /48 на несколько /64 с разными ASN. Прокси-сервис на lexic.ml как раз отдаёт пулы с разными префиксами — это снижает вес кластерного признака. После правок — 8 часов работы без блокировок.

Кейс: самовыкуп в Wildberries

Сценарий: 20 аккаунтов, каждый со своего IPv6 из /64 одного провайдера. Логин, добавление в корзину, оформление заказа. Все действия в течение 90 секунд после логина.

Причина: антифрод WB ловит «холодный старт» — аккаунт без истории сразу оформляет заказ. Плюс все 20 аккаунтов из одной /64-подсети. Плюс одинаковый порядок действий с точностью до секунды.

Решение: прогрели аккаунты за 3-5 дней (просмотры, избранное, отзывы), разнесли заказы по времени, использовали разные /64. Заказы прошли.

Кейс: скрейпинг Amazon

Конфигурация: 200 IPv6 из AWS, ротация по запросу, curl с рандомным UA. Блокировка через 15 минут.

Причина: AWS-префиксы в репутационных базах. Плюс curl без `Sec-Fetch-*` заголовков. Плюс TLS-отпечаток curl (JA3 = `3b5074b1b5d032e5620f69f9f700ff0e`) — известный маркер ботов. Amazon отдаёт 503 через CloudFront WAF.

Решение: перешли на headless Chromium с реальным профилем, добавили `Sec-Fetch-Site: same-origin`, `Sec-Fetch-Mode: navigate`. Ротацию привязали к смене аккаунта, а не к каждому запросу. Блокировки прекратились.

Что реально проверять перед запуском

Перед тем как гонять аккаунты через IPv6-прокси, прогоните чек-лист:

| Проверка | Инструмент | Норма |

|---|---|---|

| JA3/JA4 совпадает с UA | tls.peet.ws | Chrome UA → Chrome JA3 |

| Заголовки Sec-Fetch | curl -v | все 4 присутствуют |

| Задержки между кликами | лог клиента | CV > 0.3 |

| Смена IP на сессию | лог прокси | ≤ 2 |

| Загрузка статики | HAR-файл | CSS/JS/шрифты есть |

| Cookie-синхронизация | тест между воркерами | session_id стабилен |

Прогон через `tls.peet.ws/api/all` покажет отпечаток TLS, HTTP/2 и заголовки в одном ответе. Это быстрее, чем ловить блокировку на боевом аккаунте.