Instagram через IPv6 прокси: что работает, а что ведёт к бану

Почему Instagram вообще смотрит на IPv6

Instagram — это Meta. Meta с 2017 года держит dual-stack на своих edge-узлах. Если ваш клиент умеет IPv6 и у него есть маршрут, он пойдёт по IPv6 в приоритете. Это не фича вашего прокси, это Happy Eyeballs в приложении и RFC 8305 на уровне сети.

Практический вывод: мобильные клиенты Instagram на iOS 16+ и Android 12+ практически всегда используют IPv6, если он доступен. Приложение делает два параллельных соединения — по A и по AAAA — и берёт то, что ответит быстрее. Обычно это IPv6, потому что NAT64/CGNAT на стороне оператора добавляет 20-40 мс латентности.

Прокси на IPv4, который вы подсовываете мобильному клиенту, ломает эту картину. Клиент видит IPv4-адрес прокси, идёт по IPv4, и Meta получает совершенно другую сигнатуру сети. Отсюда половина проблем с логин-челленджами.

Что видит Meta на своей стороне

Meta собирает телеметрию не только по IP. Есть ASN, есть reverse DNS, есть TLS-фингерпринт, есть тайминги TCP-хендшейка, есть MTU и MSS. IPv6-прокси, который отдаёт клиенту адрес из /64 жилого провайдера, выглядит органично. IPv4-прокси из датацентра Hetzner — нет.

Ключевой момент: у Meta есть историческая привязка аккаунта к подсетям. Если аккаунт три года сидел в /64 условного Deutsche Telekom, а потом резко прыгнул в /64 OVH — это триггер. Не мгновенный бан, но челлендж с селфи почти гарантирован.

IPv6-адресация даёт вам /64 на клиента. Это 2^64 адресов. Можно ротировать адрес внутри подсети, не меняя ASN и не меняя геолокацию. Вот почему IPv6-прокси для Instagram работают лучше IPv4 — не потому что IPv6 «лучше», а потому что гранулярность ротации выше.

Ротация внутри /64: как это работает на практике

Провайдер выдаёт вам /64. Вы назначаете клиенту адрес вида 2a01:4f8:1c1c:abcd::1. Через сутки меняете на ::2. Для Meta это два разных IP, но один и тот же префикс, один ASN, одна геолокация. Риск бана падает в разы по сравнению с прыжками между /64 разных хостеров.

Вот как выглядит ротация на стороне сервера с iproute2:

```bash

ip -6 addr add 2a01:4f8:1c1c:abcd::1/64 dev eth0

ip -6 addr add 2a01:4f8:1c1c:abcd::2/64 dev eth0

ip -6 route add default via 2a01:4f8:1c1c::1 dev eth0

```

Клиент подключается к прокси, прокси выбирает исходящий адрес из пула. Простейший пул на Python с random-выбором:

```python

import random

import subprocess

POOL = [f"2a01:4f8:1c1c:abcd::{i}" for i in range(1, 256)]

def pick_source():

return random.choice(POOL)

def curl_via(addr, url):

cmd = ["curl", "-6", "--interface", addr, "-s", "-o", "/dev/null",

"-w", "%{http_code} %{time_total}", url]

return subprocess.run(cmd, capture_output=True, text=True).stdout

print(curl_via(pick_source(), "https://www.instagram.com/"))

```

Это работает, пока префикс не заблокирован целиком. Если Meta забанит /64, вы теряете все 256 адресов разом. Поэтому разумно держать 2-3 /64 от разных провайдеров и переключаться между ними по триггеру.

Что реально ведёт к бану

Первое — несовпадение геолокации. Аккаунт зарегистрирован в Берлине, вы заходите с /64 в Сингапуре. Meta видит это и требует верификацию. IPv6 тут не спасает, спасает только географически консистентный пул.

Второе — использование хостинговых ASN. OVH, Hetzner, DigitalOcean, Vultr — все в чёрных списках Meta. Residential IPv6 от Comcast, Deutsche Telekom, Orange — нет. Разница в цене десятикратная, но разница в выживаемости аккаунта — тоже.

Третье — TLS-фингерпринт. Если вы гоняете Instagram через curl с дефолтным OpenSSL, JA3-хеш не совпадает с мобильным приложением. Meta это видит. Нужен либо реальный мобильный клиент, либо подмена JA3 через uTLS в Go или curl-impersonate.

Четвёртое — тайминги. Мобильный клиент делает запросы с определёнными интервалами. Бот, который долбит API каждые 200 мс, палится моментально. Реальный пользователь открывает ленту раз в 5-15 минут.

Кейс: миграция фермы с IPv4 на IPv6

Была ферма из 40 аккаунтов на IPv4-прокси от одного хостера. Логин-челленджи сыпались на 6-8 аккаунтов в неделю. ASN хостера — AS24940 (Hetzner). Все аккаунты зарегистрированы на немецкие номера.

Причина: Hetzner в чёрном списке Meta с 2019 года. Плюс все 40 аккаунтов с одного /24 — это очевидная ферма.

Решение: переехали на IPv6 от residential-провайдера, получили /56, разбили на 40 /64 по одному на аккаунт, геолокация — Германия, ASN Deutsche Telekom. Ротация внутри /64 раз в 12 часов. Через месяц челленджи упали до 0-1 в неделю. Скорость запросов оставили прежней — 1 запрос в 3-5 секунд с рандомным джиттером.

Кейс: почему /64 важнее, чем кажется

Один клиент использовал IPv6-прокси, но с /128 — один адрес на аккаунт. 20 аккаунтов, 20 разных /128 из разных /64. Логично? Нет.

Meta видит: 20 аккаунтов, 20 разных /64, но все из одного /48, один ASN, одна геолокация. Это ещё более подозрительно, чем 20 аккаунтов с одного /64. Потому что живой пользователь не прыгает между /64 каждые 5 минут.

Правильная схема: один аккаунт = один /64. Внутри /64 ротация по ::1-::ff. ASN и геолокация стабильны. Тогда картина для Meta выглядит как обычный домашний роутер с privacy extensions (RFC 4941), который меняет суффикс раз в сутки.

Кейс: MTU и фрагментация

Тонкий момент, который многие пропускают. IPv6 не делает фрагментацию на маршрутизаторах, только на отправителе. Минимальный MTU для IPv6 — 1280 байт. Если туннель до прокси имеет MTU 1400, а клиент шлёт пакеты 1500, они молча дропаются. TCP-сессия зависает на этапе передачи тела запроса.

Пример: прокси на VPS с MTU 1500, туннель через WireGuard с MTU 1420. Клиент шлёт POST-запрос с медиа на 1.8 МБ. Первые пакеты проходят, потом сессия виснет. Instagram в приложении показывает вечную загрузку. Meta на своей стороне видит оборванное соединение — это тоже сигнал.

Решение: выставить MTU 1380 на интерфейсе прокси и MSS-clamping:

```bash

ip link set dev wg0 mtu 1380

ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --clamp-mss-to-pmtu

```

Проверить можно через ping с указанием размера:

```bash

ping6 -M do -s 1352 www.instagram.com

```

1352 + 40 (IPv6-заголовок) + 8 (ICMPv6) = 1400. Если проходит — MTU в порядке.

Сравнение схем проксирования

| Схема | Риск бана | Латентность | Стоимость /64 |

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

| IPv4 DC, один /24 | Высокий | 5-15 мс | — |

| IPv4 residential | Средний | 20-60 мс | — |

| IPv6 DC, /64 на аккаунт | Средний | 3-10 мс | \$2-5 |

| IPv6 residential, /64 на аккаунт | Низкий | 25-70 мс | \$15-40 |

Цифры по латентности — медиана из Европы до edge-узлов Meta во Франкфурте. Реальные значения плавают в зависимости от маршрута.

Как проверять, что вас не палят

Первый тест — curl с явным IPv6 и проверкой, какой адрес видит Instagram:

```bash

curl -6 --interface 2a01:4f8:1c1c:abcd::1 -s https://api.ipify.org

curl -6 --interface 2a01:4f8:1c1c:abcd::1 -s -A "Instagram 275.0.0.27.98" \

https://www.instagram.com/api/v1/users/web_profile_info/?username=instagram

```

Если второй запрос возвращает 200 и JSON — TLS-фингерпринт и заголовки проходят. Если 403 или редирект на логин — палитесь.

Второй тест — проверка ASN и геолокации. Заходите на ipinfo.io или аналогичный сервис через тот же интерфейс. ASN должен совпадать с заявленным residential-провайдером, а не с хостингом.

Третий тест — тайминги. Замерьте время до первого байта (TTFB) для 100 последовательных запросов. Если дисперсия меньше 5 мс — вы выглядите как бот. У живого мобильного клиента дисперсия 30-200 мс из-за радио-условий.

Прокси-сервер: что крутить в конфиге

Для IPv6-прокси под Instagram критичны три вещи: стабильный исходящий адрес, отсутствие утечек IPv4, корректный DNS. Если DNS-запрос уходит по IPv4 — Meta видит ваш реальный адрес через EDNS Client Subnet.

Пример конфига для 3proxy с IPv6-only исходящим:

```

nserver 2606:4700:4700::1111

nserver 2620:fe::fe

nscache 65536

timeouts 1 5 30 60 180 1800 15 60

auth none

allow *

external 2a01:4f8:1c1c:abcd::1

socks -p1080 -i0.0.0.0 -e2a01:4f8:1c1c:abcd::1

```

Проверить отсутствие утечек можно через dnsleaktest или собственный сниффер на интерфейсе. Если видите IPv4-пакеты — конфиг кривой.

Что делать с WebRTC и медиа

Instagram в вебе использует WebRTC для звонков и загрузки сторис. WebRTC по умолчанию светит локальные и STUN-адреса. Если у клиента IPv4-only браузер, а прокси IPv6-only — WebRTC либо не работает, либо утекает реальный IPv4.

Решение: либо полностью отключать WebRTC через флаги браузера, либо использовать прокси, который поддерживает и IPv4, и IPv6, но с приоритетом IPv6. Второй вариант сложнее, но даёт меньше палева.

Для мобильных клиентов WebRTC не проблема — там всё идёт через нативный стек. Но если вы гоняете веб-версию Instagram через headless Chrome, WebRTC надо глушить на уровне флагов запуска.

Итог по выживаемости

IPv6-прокси для Instagram работают, если соблюдены четыре условия: residential ASN, /64 на аккаунт, ротация внутри /64 без смены префикса, реалистичные тайминги. Нарушение любого из них — и вы в челленджах.

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

Если нужен пул IPv6 с ротацией внутри /64 и residential ASN — смотрите в сторону lexic.ml, там эта схема реализована из коробки с 2015 года. Но даже с идеальным прокси без нормальных таймингов и JA3 вы просто платите за красивый адрес, который всё равно улетит в бан через неделю.