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

Instagram — один из самых капризных сервисов для проксирования. Не потому что сложный протокол, а потому что Meta (бывшая Facebook) вложила кучу денег в детект автоматизации и подмены IP. IPv6 тут добавляет свой слой сложности: пул адресов огромный, но не весь чистый.

Разберём, что реально работает, а где начинаются грабли.

Как Instagram видит ваш IP

При заходе с мобильного приложения Instagram отправляет запросы на десяток поддоменов: `i.instagram.com`, `graph.instagram.com`, `scontent-*.cdninstagram.com`, `instagram.c10r.facebook.com`. Каждый из них может резолвиться и по A, и по AAAA. Если у вас IPv6-only прокси, а клиент умеет только IPv4 — половина запросов уйдёт напрямую, минуя прокси. Это первая классическая ошибка.

Meta собирает отпечаток из IP, ASN, геолокации (по базе MaxMind), TLS-фингерпринта (JA3/JA4), заголовков User-Agent и поведенческих паттернов. IPv6-адрес сам по себе не подозрителен — миллионы реальных мобильных клиентов сидят на IPv6 у операторов. Проблема в том, ЧТО за IPv6.

Датацентровые диапазоны (например, `2a03:2880::/32` — это сам Facebook, а `2606:4700::/32` — Cloudflare) палятся мгновенно. Жилые IPv6 от провайдеров (Comcast, Deutsche Telekom, Ростелеком) — уже лучше. Но если один и тот же /64 используется сотней аккаунтов одновременно — бан прилетит быстро.

Резолвинг: AAAA-записи ломают проксирование

Клиент по умолчанию предпочитает IPv6, если он есть у сервера. Это поведение RFC 6724 (address selection). Если ваш прокси слушает только IPv4, а Instagram отдаёт AAAA — браузер или приложение пойдёт напрямую по IPv6, если у машины есть глобальный IPv6.

Проверить, куда реально уходит трафик:

```bash

curl -6 -v --proxy socks5h://[2a01:4f8:1c1c:abcd::1]:1080 \

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

-H 'User-Agent: Instagram 219.0.0.12.117 Android'

```

Флаг `-6` заставит curl использовать IPv6 для резолва, `socks5h` — резолвить имя на стороне прокси, а не локально. Без `h` DNS утечёт мимо туннеля, и Instagram увидит ваш реальный резолвер. Это вторая ошибка, которая валит аккаунты пачками.

В Python через `requests` + `socks` то же самое:

```python

import requests

proxies = {

"http": "socks5h://[2a01:4f8:1c1c:abcd::1]:1080",

"https": "socks5h://[2a01:4f8:1c1c:abcd::1]:1080",

}

headers = {

"User-Agent": "Instagram 219.0.0.12.117 Android (30/11; 420dpi; 1080x2400; samsung; SM-G991B; o1s; exynos2100; en_US; 340792199)",

"X-IG-App-ID": "936619743392459",

}

r = requests.get(

"https://i.instagram.com/api/v1/users/web_profile_info/",

params={"username": "instagram"},

proxies=proxies,

headers=headers,

timeout=15,

)

print(r.status_code, r.headers.get("x-ig-set-www-claim"))

```

`X-IG-App-ID` — обязательный заголовок для многих мобильных эндпоинтов. Без него получите 400 или пустой ответ. И да, `socks5h` не работает в `requests` без пакета `PySocks` — ставьте `requests[socks]`.

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

Простая схема: один жилой /64 на аккаунт, стабильный ASN, геолокация совпадает с телефоном. Если аккаунт зарегистрирован на немецкий номер — сидите на немецком IPv6 от Deutsche Telekom или Vodafone. Скачки между континентами за минуту — верный путь к чекпоинту.

Для парсинга публичных профилей (не логин, а чтение) жилой пул не обязателен. Достаточно чистых датацентровых IPv6 с ротацией. Instagram отдаёт публичные данные с rate limit примерно 200 запросов в час на IP, потом 429 с `Retry-After` в районе 300-900 секунд. Ротация по /64 помогает обойти, но не долбите чаще раза в 3 секунды.

Для мультиаккаунтинга (не буду спрашивать зачем) — только sticky sessions. Прокси должен держать один и тот же IPv6 за аккаунтом минимум неделями. Meta отслеживает смену IP у аккаунта и при частых прыжках кидает `checkpoint_required`. Пул из 1000 адресов, где каждый аккаунт сидит на своём /128 стабильно — работает. Пул на 50 адресов с ротацией каждые 10 минут на 200 аккаунтов — гарантированный бан за сутки.

Где начинаются баны

Первое — IPv6 из «грязных» диапазонов. Есть публичные списки (Spamhaus, FireHOL), но Meta использует свои. Диапазоны хостеров вроде Hetzner, OVH, DigitalOcean помечены как «hosting» в их внутренней базе. Заход с такого адреса в web-версию Instagram — сразу капча. В мобильное приложение — иногда пускает, но с флагом «suspicious».

Второе — /64, засвеченный спамом. Если с подсети уже долбили Instagram сотни ботов, весь /64 попадёт под усиленный контроль. Проверить репутацию конкретного адреса можно через `curl` к публичным API:

```bash

curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=2a01:4f8:1c1c:abcd::1&maxAgeInDays=90" \

-H "Key: YOUR_KEY" -H "Accept: application/json" | jq '.data.abuseConfidenceScore'

```

Больше 20 — уже риск. Больше 50 — не суйтесь.

Третье — несоответствие TLS-фингерпринта. Если сидите с IPv6 мобильного оператора, но TLS-хендшейк от Python `requests` (JA3 = `3b5074b1b5d032e5620f69f9f700ff0e` — характерный для OpenSSL) — палево. Мобильное приложение Instagram использует BoringSSL с другим набором шифров. Для парсинга публички это терпимо, для логина — нет. Тут либо `curl_cffi` с импersonation, либо реальный мобильный клиент.

Кейс: парсер публичных профилей на 50k запросов в сутки

Задача — собирать метрики публичных аккаунтов. Сервер на Ubuntu 22.04, nginx 1.24 как reverse proxy к локальному скрипту, пул IPv6 от швейцарского провайдера (не хостинг, жилые).

Первая попытка: один IPv6, 2 запроса в секунду. Через 40 минут — 429 на все запросы, `Retry-After: 900`. Причина — превышение rate limit по IP.

Вторая попытка: ротация по /64 из пула 256 подсетей, round-robin. Через 3 часа — часть подсетей начала отдавать 403 с `{"message":"challenge_required"}`. Причина — Meta сгруппировала подсети по ASN и применила репутацию на весь диапазон.

Решение: пул из 40 жилых /64 от разных ASN (Swisscom, Init7, Sunrise), sticky на 10 минут, не более 1 запроса в 2 секунды на адрес. Итог — 50k запросов в сутки стабильно, 429 ловим в 0.3% случаев.

Кейс: логин через IPv6 и мгновенный чекпоинт

Клиент арендовал IPv6-прокси у крупного хостера, попытался залогиниться в аккаунт, зарегистрированный год назад с российского мобильного IP. Первый же запрос к `i.instagram.com/api/v1/accounts/login/` вернул 400 с `checkpoint_required`.

Разбор: резолв `i.instagram.com` дал AAAA `2a03:2880:f10c:83:face:b00c:0:25de` (это сам Facebook edge). Прокси был в датацентре Hetzner, ASN 24940 — в базе Meta помечен как hosting. Плюс страна не совпала (Германия vs Россия), плюс TLS-фингерпринт от Python.

Что помогло: жилой IPv6 российского провайдера, `curl_cffi` с `impersonate="chrome110"`, прогрев сессии — 3 дня только чтения ленты без действий. После прогрева логин прошёл.

Кейс: мультиаккаунт и корреляция по /64

Ферма на 30 аккаунтов, каждому выдавался свой /128 из одной /64. Через неделю — бан 12 аккаунтов одновременно. Meta связала их по подсети: все /128 в одном /64 принадлежат одному абоненту, и если с одного адреса был спам, страдают все.

Вывод: один /64 = один «абонент» = максимум 1-2 аккаунта. Для 30 аккаунтов нужно 15-30 разных /64, желательно от разных ASN. Провайдеры вроде lexic.ml выдают именно так — по /64 на клиента, а не нарезают /128 из одной подсети, что как раз и спасает от такой корреляции.

Клиентская сторона: как не слить реальный IPv6

Если у машины есть глобальный IPv6 (а на большинстве современных провайдеров есть), приложения могут ходить напрямую, игнорируя прокси. Проверить:

```bash

curl -6 ifconfig.co

```

Если вернул ваш реальный адрес — IPv6 утекает. Отключить глобальный IPv6 на интерфейсе или использовать firewall:

```bash

sudo ip6tables -A OUTPUT -d 2a03:2880::/32 -j REJECT

```

Это грубо, но работает: весь трафик к Meta пойдёт через IPv4, а значит через прокси, если он настроен. Более аккуратно — policy routing через `ip -6 rule`.

Что в итоге

IPv6 для Instagram работает, но не любой. Жилые диапазоны от операторов — да. Датацентровые — только для парсинга публички с низким rate. Sticky-сессии обязательны для аккаунтов. Резолвинг через `socks5h` — обязательно. TLS-фингерпринт для логина — обязательно. Один /64 на аккаунт — обязательно.

Всё остальное — лотерея с плохими шансами. Meta обновляет детект регулярно, так что схему придётся подкручивать. Но базовые принципы (чистый ASN, стабильность, консистентность) не меняются годами.