Парсинг Wildberries и Ozon: почему пул IPv4 в 1000 адресов хуже, чем 200 IPv6-подсетей

Реальность антибот-систем

Wildberries и Ozon вкладывают миллионы в защиту от парсинга. Каждый запрос проходит через сложную систему фильтров: анализ User-Agent, TLS-отпечатков, поведенческих факторов, частоты запросов. Но самый базовый и действенный фильтр — IP-адрес.

Ограничения на стороне WB: около 20-40 запросов в минуту с одного IP. Ozon чуть лояльнее — до 60 запросов в минуту. Превысил — получи бан на 15 минут. Систематически превышаешь — блокировка на сутки или неделю.

Парсеру нужно обходить эти лимиты. И тут начинается главная развилка: брать пул IPv4 или строить работу на IPv6.

IPv4-подход: 1000 адресов и их проблемы

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

Проблема номер один: репутация подсетей

Провайдеры прокси выдают адреса из определённых подсетей. Антибот-системы WB и Ozon давно вычислили эти диапазоны. Если подсеть засвечена парсерами — бан прилетает на следующий же запрос.

Пример: прокси-провайдер с диапазоном 185.200.0.0/22. Через него парсят тысячи клиентов. WB достаточно увидеть IP из этой подсети — и сразу капча. Репутация подсети убита.

Проблема номер два: стоимость и масштабирование

1000 IPv4 — это не просто адреса. Это:

- аренда или покупка адресов (от \$0.5 до \$2 за адрес в месяц)

- серверы для проксирования

- логистика распределения нагрузки

Когда нужно 5000 адресов — цена растёт линейно. Никакой экономии масштаба. IPv4-адресов в принципе мало, и их стоимость только растёт.

IPv6-подход: 200 подсетей и их преимущества

IPv6-адреса стоят копейки. Обычно их дают бесплатно вместе с VPS или выделенным сервером. Одна подсеть /64 содержит 18 квинтиллионов адресов. Практически бесконечный ресурс.

Как это работает технически

Сервер с IPv6 получает одну подсеть /64. Из неё можно генерировать любое количество уникальных адресов. Каждый адрес — это отдельная сущность для антибот-системы.

```bash

Генерация случайного IPv6 адреса из подсети

!/bin/bash

SUBNET="2a01:4f8:1c1c:7a00::/64"

for i in {1..10}; do

RANDOM_SUFFIX=\$(openssl rand -hex 8)

echo "\${SUBNET%%::*}::\${RANDOM_SUFFIX:0:4}:\${RANDOM_SUFFIX:4:4}"

done

```

Но просто иметь адреса мало. Нужно правильно их презентовать системе.

Тонкость с privacy extensions

Windows, Linux и Android по умолчанию используют privacy extensions для IPv6. Это значит, что ОС генерирует временные адреса и периодически их меняет. Для браузера это нормально. Для парсера — проблема.

Антибот-системы видят, что адрес меняется каждые 10-15 минут. Для легитимного пользователя такое поведение ненормально. Поэтому при настройке парсера нужно отключать privacy extensions и использовать стабильные адреса.

```python

import socket

import random

def generate_ipv6_address(subnet: str) -> str:

"""Генерация стабильного IPv6 адреса из подсети"""

Убираем префикс /64

base = subnet.split("/")[0]

Генерируем 64-битный суффикс

suffix = ''.join(random.choices('0123456789abcdef', k=16))

Форматируем адрес

return f"{base}:{suffix[:4]}:{suffix[4:8]}:{suffix[8:12]}:{suffix[12:]}"

```

Кейс: парсинг карточек товаров WB

Проблема: нужно собрать 50000 карточек товаров в категории "электроника". Антибот-система WB блокирует после 30 запросов в минуту с одного IP.

Причина: стандартный парсер на одном IP упирается в лимит через 30-40 секунд работы. Дальше — капча или бан.

Технические детали: WB использует Cloudflare, который анализирует не только IP, но и TLS-отпечатки. Если парсер не имитирует реальный браузер — бан прилетает быстрее.

Решение: сервер с 5 IPv6-подсетями /64. На каждой подсети поднимаем 50 прокси. Итого 250 уникальных адресов. Каждый адрес делает максимум 20 запросов в минуту. Нагрузка распределяется равномерно.

Результат: 50000 карточек за 45 минут. Банов нет. Антибот-система не видит аномалий — каждый адрес ведёт себя как обычный пользователь.

Кейс: мониторинг цен на Ozon

Проблема: нужно проверять цены на 10000 товаров каждые 10 минут. Это 1000 запросов в минуту.

Причина: Ozon блокирует IP после 60 запросов в минуту. Нужен пул минимум из 20 адресов.

Решение: одна IPv6-подсеть /64 на обычном VPS за \$10 в месяц. Генерируем 200 адресов из подсети. Каждый адрес опрашивает 50 товаров раз в 10 минут. Никаких блокировок.

```bash

Настройка прокси на основе IPv6

/etc/nginx/conf.d/ipv6_proxy.conf

stream {

upstream backend {

server 127.0.0.1:8080;

}

server {

listen [::]:8080;

proxy_pass backend;

}

}

```

Стоимость решения: \$10 в месяц за VPS. Сравните с \$500-1000 за аналогичный пул IPv4.

Кейс: обход блокировок при массовом сборе данных

Проблема: сбор данных о всех продавцах на WB. Объём — миллионы запросов. Даже 1000 IPv4 не хватает.

Причина: WB анализирует не только IP, но и паттерны запросов. Если 1000 адресов работают синхронно — это выглядит как атака. Нужна рандомизация.

Решение: 200 IPv6-подсетей на 10 серверах. Каждая подсеть даёт 1000 уникальных адресов. Рандомизация времени между запросами от 100 до 500 мс. Ротация адресов каждые 5 минут.

Результат: 2 миллиона запросов за 3 часа. Блокировок нет. Нагрузка на серверы минимальная — IPv6-обработка не требует значительных ресурсов.

Технические грабли с IPv6

Не всё так гладко. Есть несколько моментов, которые нужно учитывать.

MTU и фрагментация

IPv6 не поддерживает фрагментацию на маршрутизаторах. Если пакет превышает MTU — он отбрасывается. Для парсинга это может быть проблемой при работе с большими ответами.

Решение: настроить MTU на интерфейсе. Обычно 1500 байт достаточно. Для HTTPS-запросов — 1450 байт из-за TCP-заголовка.

Прокси-цепочки

Некоторые прокси-провайдеры не поддерживают IPv6. Если планируете строить цепочку прокси — убедитесь, что каждый элемент цепочки умеет работать с IPv6.

DNS-резолвинг

Некоторые DNS-серверы до сих пор не умеют корректно обрабатывать PTR-записи для IPv6. Это может вызвать проблемы при проверке репутации адреса.

Сравнение затрат

| Параметр | 1000 IPv4 | 200 IPv6-подсетей |

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

| Стоимость в месяц | \$500-2000 | \$50-200 |

| Количество адресов | 1000 | 200 x 10^18 |

| Масштабирование | Линейный рост цены | Практически бесплатно |

| Репутация | Часто засвечены | Чистая |

| Настройка | Сложная | Средняя |

| Риск блокировки | Высокий | Низкий |

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

Начинайте с одной подсети /64. Тестируйте на небольшом объёме данных. Постепенно увеличивайте количество подсетей.

Обязательно используйте реальный браузерный движок. Playwright или Puppeteer с headless-режимом. Простые HTTP-запросы палятся мгновенно.

```python

from playwright.async_api import async_playwright

async def fetch_product(url: str, proxy: str):

async with async_playwright() as p:

browser = await p.chromium.launch(

headless=True,

args=['--no-sandbox']

)

context = await browser.new_context(

proxy={"server": proxy}

)

page = await context.new_page()

await page.goto(url, timeout=30000)

content = await page.content()

await browser.close()

return content

```

Выводы

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

Ключевое преимущество — не количество адресов, а их качество. Чистая подсеть без репутационных проблем. Плюс возможность генерировать новые адреса в любой момент.

Главное — правильно настроить инфраструктуру. Стабильные адреса, рандомизация запросов, имитация реального пользователя. Тогда ни Wildberries, ни Ozon не увидят подвоха.

Начинайте с малого. Одна подсеть, один сервер, тестовый парсер. Когда отработаете механику — масштабируйтесь. IPv6 это позволяет делать без лишних затрат.