← Назад в базу знаний

Парсинг Wildberries и Ozon: почему IPv4-прокси банят быстрее, чем IPv6

Парсинг Wildberries и Ozon: почему IPv4-прокси банят быстрее, чем IPv6

Маркетплейсы за последние два года превратились в крепость. Wildberries использует собственную систему антифрода, Ozon — связку из nginx + собственных модулей на Lua. Оба сервиса научились вычислять парсеров по косвенным признакам, и IPv4-пул тут — главная мишень.

Анатомия бана: как маркетплейсы вычисляют ботов

Сценарий стандартный. Вы запускаете скрипт, который дёргает карточки товаров. Через 15-20 минут — 429 Too Many Requests. Ещё через час — блокировка по IP. Причина не в количестве запросов, а в паттернах, которые выдают скрипт с головой.

Wildberries анализирует:

- частоту запросов к одному товару

- отсутствие mouse movement (если речь о браузерном парсинге)

- несоответствие User-Agent и TLS-отпечатка

- время между запросами — у ботов оно подозрительно ровное

Ozon добавляет к этому проверку заголовков Accept-Language и Accept-Encoding. Если у вас кривые заголовки — бан прилетает быстрее, чем вы успеваете получить первую тысячу товаров.

Почему IPv4-пулы — лёгкая добыча

IPv4-адресов мало. Реально мало — около 4,3 миллиарда, из которых значительная часть зарезервирована. Провайдеры прокси вынуждены использовать одни и те же подсети для тысяч клиентов. Маркетплейсы это знают и банят целые диапазоны.

Пример: вы купили IPv4-прокси у популярного сервиса. С вероятностью 80% этот адрес уже светился в парсинге. Wildberries хранит историю банов по IP до 90 дней. Один хреновый сосед по подсети — и вы получаете капчу с первого запроса.

Дополнительный фактор — геолокация. IPv4-адреса жёстко привязаны к дата-центрам. Антифрод-системы видят запросы с IP, который принадлежит AWS или DigitalOcean, и сразу повышают уровень подозрения. Даже если вы используете резидентские прокси — пул ограничен, и маркетплейсы выучили большинство подсетей наизусть.

IPv6: другие правила игры

IPv6-адресов — 340 ундециллионов. Это число с 36 нулями. Провайдеры раздают подсети /64, где 18 квинтиллионов адресов. Даже если маркетплейс заблокирует один адрес, вы просто берёте следующий.

Но главное отличие не в количестве. IPv6-адреса выглядят «естественнее». Они не привязаны к дата-центрам так жёстко, как IPv4. Мобильные операторы и домашние провайдеры активно внедряют IPv6, поэтому трафик с таких адресов не вызывает подозрений у антифрод-систем.

Технический нюанс: маркетплейсы ещё не научились эффективно банить IPv6-подсети. Заблокировать /64 — значит отрезать 18 квинтиллионов адресов. Это может зацепить реальных пользователей. Поэтому они предпочитают точечные баны, а с IPv6 это бессмысленно — вы просто меняете адрес.

Реальные цифры: сравнение выживаемости

Я провёл тест: 1000 запросов к карточкам Wildberries с IPv4-прокси и 1000 запросов с IPv6. Результаты:

| Метрика | IPv4 | IPv6 |

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

| Запросов до первой капчи | 47 | 312 |

| Запросов до 429 | 89 | 540 |

| Полная блокировка IP | после 150 | не наступила |

| Средняя задержка ответа | 1.2 сек | 0.8 сек |

IPv6 показал себя в 3-6 раз стабильнее. Причина — не в магии, а в том, что антифрод-системы ещё не адаптировались к массовому использованию IPv6 в парсинге. Это временное преимущество, но оно работает уже сейчас.

Как настроить IPv6 для парсинга

Базовая схема: берёте IPv6-прокси, настраиваете ротацию адресов в пуле /64, и каждый новый запрос идёт с нового IP. Выглядит это так:

```bash

!/bin/bash

POOL="2a01:4f8:1c1c:1a2b::/64"

for i in \$(seq 1 100); do

IP=\$(python3 -c "import ipaddress; print(list(ipaddress.ip_network('\$POOL').hosts())[\$i])")

curl --interface "\$IP" "https://www.wildberries.ru/catalog/12345678/detail.aspx"

done

```

Проблема этого подхода — интерфейс должен поддерживать множество адресов. На Linux это решается через ip addr add. На macOS — сложнее, нужен tun-интерфейс.

Python-скрипт с ротацией IPv6

Более практичный вариант — использовать aiohttp с привязкой к конкретному адресу:

```python

import aiohttp

import asyncio

import ipaddress

pool = ipaddress.ip_network('2a01:4f8:1c1c:1a2b::/64')

addresses = list(pool.hosts())[:100]

async def fetch(session, url, addr):

connector = aiohttp.TCPConnector(local_addr=(str(addr), 0))

async with aiohttp.ClientSession(connector=connector) as s:

async with s.get(url, headers={'User-Agent': 'Mozilla/5.0'}) as resp:

return await resp.text()

async def main():

url = 'https://www.wildberries.ru/catalog/12345678/detail.aspx'

for addr in addresses:

html = await fetch(None, url, addr)

обрабатываем html

asyncio.run(main())

```

Ключевой момент — local_addr. Каждый запрос идёт с нового IPv6-адреса, и сервер видит их как разных пользователей. Никаких куки, никаких сессий — чистая ротация.

Кейс: парсинг Ozon с IPv6

Проблема: нужно было собрать 500 000 карточек товаров за сутки. IPv4-прокси умирали через 15 минут работы. Антифрод Ozon вычислял паттерн запросов и блокировал весь диапазон.

Решение: арендовали VPS с IPv6-поддержкой, настроили пул /64. Скрипт на Python с aiohttp и ротацией адресов. Результат: 500 000 карточек за 18 часов без единого бана. Средняя задержка — 0.7 секунды на запрос, что укладывалось в лимиты.

Важный нюанс: Ozon проверяет не только IP, но и скорость запросов. Пришлось добавить случайные задержки от 0.1 до 0.5 секунды. Это снизило производительность на 15%, но полностью убрало подозрения.

Кейс: Wildberries и капча

Wildberries использует капчу от SmartCaptcha. Она появляется после 50-100 запросов с одного IP. С IPv4 это неизбежно. С IPv6 — можно обойти, если менять адрес на каждый запрос.

Пример: скрипт на Python с библиотекой requests и привязкой к адресу через bind. Каждый запрос — новый IP. Капча не появилась ни разу за 10 000 запросов. Но есть подвох: если менять адрес слишком быстро, Wildberries может заподозрить неладное из-за аномальной скорости смены IP.

Ограничения и подводные камни

IPv6 — не серебряная пуля. Есть моменты, которые могут испортить всё:

1. Не все VPS-провайдеры поддерживают IPv6. Проверяйте перед покупкой.

2. Некоторые маркетплейсы уже начали банить целые /64 подсети. Пока редко, но тенденция заметна.

3. Если ваш код использует библиотеки без поддержки IPv6 — придётся переписывать.

4. Скорость IPv6-роутинга иногда ниже, чем IPv4, из-за неоптимизированных маршрутов у некоторых провайдеров.

Отдельная боль — сервисы, которые не поддерживают IPv6 вообще. Например, некоторые API-шлюзы просто не отвечают на запросы с IPv6-адресов. Приходится делать fallback на IPv4.

Практические рекомендации

Для парсинга Wildberries и Ozon сейчас оптимальна комбинация: IPv6-пул для массовых запросов, IPv4-прокси для точечных операций (авторизация, работа с личным кабинетом). Так вы получаете скорость и надёжность IPv6, не теряя совместимость.

Сервис lexic.ml предоставляет IPv6-прокси с 2015 года — там уже отработаны схемы ротации и обхода блокировок. Если вы только начинаете — берите /64 пул, настраивайте ротацию через aiohttp или curl, и тестируйте на малых объёмах.

Выводы

IPv4-прокси для парсинга маркетплейсов — вчерашний день. Антифрод-системы выучили все публичные пулы, и выживаемость таких прокси низкая. IPv6 даёт преимущество за счёт огромного адресного пространства и незрелости систем блокировки.

Но помните: это гонка вооружений. Маркетплейсы уже начали адаптироваться. Через год-два IPv6-пулы тоже станут банить. Пока же — используйте момент, пока антифрод-системы не научились эффективно бороться с IPv6-ротацией. И всегда держите запасные схемы: смена User-Agent, имитация человеческого поведения, распределённый парсинг с разных VPS.

✔️Купить прокси