VK через IPv6 прокси: массовые регистрации, автопостинг и парсинг

Почему VK и IPv6 — это отдельная история

VK исторически заточен под мобильный трафик. Больше половины аудитории заходит с телефонов, и это накладывает отпечаток на всю антифрод-логику. Мобильные операторы давно раздают IPv6 — МТС, Мегафон, Билайн поднимают dual-stack на LTE с 2016-2018 годов. Для VK IPv6-адрес с префиксом оператора выглядит органично. Это и создаёт окно возможностей.

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

С IPv4 всё иначе. Датацентровые диапазоны давно в чёрных списках. Резидентные IPv4 дорогие, их 3-5 долларов за адрес в месяц. IPv6 в датацентрах стоит копейки — под /64 можно взять за 1-2 доллара. Разница в цене на порядок. Отсюда весь интерес.

Как VK определяет подозрительность

Антифрод VK собирает десятки сигналов. IP-адрес — только один из них, но важный. Смотри на то, что реально проверяется при регистрации:

- ASN и тип сети (мобильный оператор, датацентр, домашний провайдер)

- Геолокация по IP и её совпадение с указанным городом

- Скорость заполнения формы регистрации

- Наличие JS-отпечатка браузера (WebRTC, canvas, шрифты)

- Поведение: движения мыши, скроллы, тайминги

- Наличие cookie и истории сессии

- Частота запросов с адреса за последние сутки

Если ASN принадлежит хостингу — это первый красный флаг. Если с одного /64 за час регистрируется 50 аккаунтов — второй. Если при этом WebRTC утекает локальный IP из другой подсети — третий.

IPv6-прокси решает только сетевой слой. Всё остальное — на стороне клиента. Многие это путают и удивляются, почему аккаунты летят.

Регистрация через IPv6-прокси: что ломается

Классическая схема: берёшь пул IPv6, ротируешь адрес на каждую регистрацию, шлёшь запросы. На бумаге красиво. На практике VK ловит это за минуты.

Причина — в корреляции. VK видит, что 30 регистраций пришли с адресов одного /64. Даже если каждый /128 уникален, префикс совпадает. Оператор так не делает: у абонента один /64, но регистрации с него идут редко и с разных устройств. А тут — конвейер.

Второй момент — TLS-отпечаток. Если curl или requests идут с дефолтным JA3, VK видит одинаковый отпечаток у сотен «разных» пользователей. Это палево похлеще IP.

Вот как выглядит базовый запрос через IPv6-прокси в Python:

```python

import requests

proxies = {

"http": "http://user:pass@[2001:db8::1]:8080",

"https": "http://user:pass@[2001:db8::1]:8080",

}

headers = {

"User-Agent": "Mozilla/5.0 (Linux; Android 12; SM-A525F) "

"AppleWebKit/537.36 (KHTML, like Gecko) "

"Chrome/108.0.0.0 Mobile Safari/537.36",

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

}

r = requests.get("https://vk.com/", proxies=proxies, headers=headers, timeout=15)

print(r.status_code, r.headers.get("X-Frontend"))

```

Обрати внимание на квадратные скобки вокруг IPv6 — без них requests не распарсит адрес. Это первая грабля, на которую наступают все.

Ротация адресов: /128 против /64

Есть два подхода к ротации. Первый — менять /128 на каждый запрос. Второй — держать один /64 на сессию и менять /128 внутри него. Оба ломаются по-своему.

Ротация /128 на каждый запрос выглядит как пользователь, который скачет по адресам внутри одной подсети. Это физически возможно только через прокси. Настоящий абонент так не делает. VK это видит.

Ротация /64 на сессию — ближе к реальности. Один префикс, стабильный на 10-30 минут. Но тогда встаёт вопрос: сколько сессий с одного /64 допустимо? Эмпирически — 1-3 регистрации в сутки с одного /64. Больше — рост риска бана.

Третий вариант — sticky-сессии по /128 на длительный срок. Один адрес на аккаунт, живёт неделями. Дороже по пулу, но выживаемость выше в разы. Провайдеры вроде lexic.ml дают именно sticky-режим с TTL от часа до бесконечности, и это технически оправдано для соцсетей.

Автопостинг: где рвётся

Автопостинг в VK идёт через API. Методы `wall.post`, `photos.getWallUploadServer`, `video.save`. Лимиты: 50 постов в сутки на стену, 5000 запросов в сутки на токен. Но лимиты — не главная проблема.

Главная — привязка токена к IP. VK пускает API-запросы с любого IP, но если токен получен с одного адреса, а используется с другого — растёт риск. Особенно для токенов, полученных через Implicit Flow с `redirect_uri`.

Схема с IPv6-прокси: получаешь токен через прокси, дальше шлёшь посты через тот же /128. Если адрес меняется — VK может инвалидировать токен или запросить повторную авторизацию.

Вот пример постинга с привязкой к IPv6:

```bash

TOKEN="vk1.a.xxx"

GROUP_ID="123456789"

PROXY="http://user:pass@[2001:db8::42]:8080"

curl -x "\$PROXY" \

-X POST "https://api.vk.com/method/wall.post" \

-d "owner_id=-\$GROUP_ID" \

-d "message=Test post" \

-d "from_group=1" \

-d "access_token=\$TOKEN" \

-d "v=5.199"

```

Ошибки, которые ловят чаще всего: `error_code: 5` (авторизация не прошла), `error_code: 14` (captcha), `error_code: 15` (доступ запрещён). Код 14 — это уже антифрод, значит IP попал в подозрительные.

Парсинг: что отдаёт VK и как

Парсинг VK — отдельная боль. Открытое API даёт ограниченные данные. Полный парсинг идёт через mobile API или скрейпинг HTML. Оба варианта требуют стабильного IP.

Mobile API (`api.vk.com/method/...` с `v=5.199` и user-agent от официального клиента) отдаёт больше, чем web. Например, `users.get` с `fields=followers_count,counters` возвращает данные, скрытые в вебе. Но требует токен от приложения с подходящими правами.

Скрейпинг HTML идёт через `m.vk.com` — мобильная версия легче, меньше JS, быстрее парсится. Но VK отдаёт её только при правильном User-Agent. Отсюда требование к консистентности: UA, IP-тип, TLS-отпечаток должны совпадать.

Если парсить с IPv4-датацентра — получишь 403 через 20-30 запросов. С IPv6 из мобильного диапазона — держит дольше. Но не бесконечно.

Сравнение типов прокси для VK

| Тип | ASN | Цена за IP/мес | Выживаемость регистраций | Годность для парсинга |

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

| DC IPv4 | хостинг | \$0.5-1 | низкая | 403 через 20-50 запросов |

| DC IPv6 | хостинг | \$0.1-0.3 | очень низкая | 403 через 10-30 запросов |

| Резидентные IPv4 | домашний ISP | \$3-5 | средняя | 500-2000 запросов |

| Мобильные IPv4 | оператор | \$15-30 | высокая | 2000-10000 запросов |

| Мобильные IPv6 | оператор | \$1-3 | средняя-высокая | 1000-5000 запросов |

Цифры приблизительные, зависят от провайдера и нагрузки. Но пропорция держится: мобильный IPv6 дешевле мобильного IPv4 в 5-10 раз при сопоставимой выживаемости.

Кейс: 200 регистраций с одного /64

Был эксперимент: пул /64 от хостера в Нидерландах, ротация /128 на каждую регистрацию. 200 аккаунтов за 4 часа.

Результат: 47 аккаунтов ушли в бан в первые сутки, ещё 89 — в течение недели. Выжило 64. Причина бана в 90% случаев — «подозрительная активность», не конкретное нарушение.

Разбор показал: все 200 регистраций шли с одного /64. VK сгруппировал их по префиксу и забанил пачкой. Плюс TLS-отпечаток был идентичен у всех — дефолтный Python requests.

Что помогло: смена /64 каждые 5 регистраций, рандомизация JA3 через `curl_cffi`, разные User-Agent под реальные устройства. Выживаемость выросла до 70-75%.

Кейс: автопостинг в 50 групп

Задача — постить в 50 групп одновременно, каждая со своего токена. Сначала пустили всё через один IPv4-прокси. Через 3 дня 12 токенов инвалидировались, ещё 8 получили captcha на каждый пост.

Причина: VK видит 50 разных токенов с одного IP. Это паттерн бота. Даже если действия легальны, корреляция по IP выдаёт.

Решение: каждому токену — свой /128 из мобильного IPv6-пула. Плюс рандомные задержки между постами (30-180 секунд). Плюс имитация человеческих таймингов: не ровно 50 постов в час, а разброс. После переезда — 47 из 50 токенов живут месяц без проблем.

Кейс: парсинг 10к профилей

Парсинг открытых данных 10 000 профилей через `users.get` батчами по 1000 ID. Один запрос — 1000 профилей, всего 10 запросов. Звучит легко.

На деле: VK режет батчи до 500 ID при высокой нагрузке, а с подозрительного IP — до 100. Плюс rate limit: 3 запроса в секунду на токен, но с плохого IP — 1 запрос в 2 секунды.

С резидентых IPv4 — 10 000 профилей за 40 минут. С мобильных IPv6 — за 25 минут, потому что лимиты мягче. С DC IPv6 — вообще не получилось, 403 на третьем запросе.

Настройка nginx как IPv6-фронта

Если прокси-пул свой, часто ставят nginx как фронт для распределения. Конфиг для IPv6-апстрима:

```nginx

upstream vk_backend {

server [2001:db8::10]:8080;

server [2001:db8::11]:8080;

server [2001:db8::12]:8080;

keepalive 32;

}

server {

listen [::]:443 ssl http2;

server_name proxy.example.com;

ssl_certificate /etc/ssl/proxy.crt;

ssl_certificate_key /etc/ssl/proxy.key;

ssl_protocols TLSv1.2 TLSv1.3;

location / {

proxy_pass http://vk_backend;

proxy_http_version 1.1;

proxy_set_header Connection "";

proxy_set_header Host \$host;

proxy_set_header X-Real-IP \$remote_addr;

proxy_connect_timeout 5s;

proxy_read_timeout 30s;

}

}

```

Ключевое здесь — `keepalive` и `proxy_http_version 1.1`. Без них каждый запрос открывает новое TCP-соединение, растёт latency и палится паттерн. С keepalive — соединение живёт, выглядит как обычный клиент.

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

IPv6 не делает фрагментацию на роутерах. Только end-to-end. Минимальный MTU для IPv6 — 1280 байт. Если туннель до прокси имеет MTU меньше — пакеты молча теряются.

Классическая грабля: PPPoE-туннель с MTU 1492, IPv6-пакеты с заголовком 40 байт не влезают. Решение — MSS clamping на роутере или уменьшение MTU на интерфейсе.

Проверить реальный MTU до прокси:

```bash

ping6 -M do -s 1452 2001:db8::1

```

Если проходит — MTU 1500. Если нет — уменьшай `-s` до прохождения. Разница между 1452 и 1232 — 220 байт на пакет, на потоке в 100 Мбит/с это заметно.

Что реально работает

Связка для стабильной работы с VK через IPv6 выглядит так. Мобильный IPv6-пул от оператора или близкого к нему провайдера. Sticky-сессии по /128 с TTL от 1 часа. Рандомизация TLS-отпечатка через `curl_cffi` или `httpx` с кастомным SSL-контекстом. Разные User-Agent под реальные устройства. Задержки между запросами в диапазоне 1-15 секунд. Разные /64 для разных групп аккаунтов.

Без любого из этих элементов схема разваливается. IPv6 сам по себе — не серебряная пуля. Это один слой из пяти-шести, которые нужно собрать.

Мониторинг и метрики

Что мерить, чтобы понимать состояние пула:

- Процент успешных запросов по каждому /64

- Количество captcha (error_code 14) на 1000 запросов

- Количество 403 на 1000 запросов

- Среднее время жизни аккаунта после регистрации

- Процент токенов, инвалидированных за сутки

Если captcha растёт выше 5% — пора менять пул. Если 403 выше 2% — IP уже в чёрном списке. Если среднее время жизни падает ниже недели — что-то не так с поведенческими факторами, не с сетью.

Метрики собираются просто: логируешь каждый запрос с кодом ответа и привязкой к /64. Дальше агрегация по префиксу. Через сутки видно, какие подсети токсичные.

Итог

VK через IPv6 — рабочая схема, но с оговорками. Дешёвый DC IPv6 не годится. Нужен мобильный или близкий к мобильному диапазон. Нужна корректная ротация: /64 на группу, /128 на сессию. Нужна консистентность отпечатков. Без этого — деньги на ветер и баны пачками.

Основная ошибка — думать, что IPv6 сам решит проблему. Он решает только сетевой слой. Остальные пять слоёв антифрода остаются на тебе.