Snapchat через IPv6 прокси: работа с геофильтрами и рекламой

Почему Snapchat ломается на обычных прокси

Snapchat — не просто мессенджер. Это рекламная платформа с жёсткой геопривязкой, и она проверяет клиента по десятку сигналов одновременно. IP-адрес тут не главный, а один из многих. Мобильное приложение шлёт на серверы Snap телеметрию: модель устройства, версию ОС, оператора связи, MCC/MNC симки, GPS-координаты, часовой пояс, локаль. Если IP говорит «Германия», а телефон рапортует MCC 250 (Россия) — аккаунт улетает в теневой бан. Реклама не показывается, геофильтры исчезают из выдачи, Stories не грузятся.

Обычные IPv4-прокси тут палятся моментально. Датацентровые подсети Snapchat знает наизусть — это ASN хостеров, которые никогда не выдают residential-трафик. Мобильные операторы сидят в других диапазонах. IPv6 меняет расклад: адресное пространство огромное, /64 на клиента — норма, и многие операторы выдают именно IPv6-адреса мобильным устройствам в первую очередь. Snapchat видит такой трафик как «живой» мобильный, если всё остальное сходится.

Проблема в том, что IPv6-прокси — зоопарк. Одни провайдеры дают /128 с одного адреса на всех, другие — целую /64-подсеть, где каждый запрос уходит с нового адреса. Для Snapchat это критично: смена IP между запросами внутри одной сессии выглядит как угон аккаунта. Нужен стабильный адрес на время сессии, но ротация между сессиями.

Что именно проверяет Snapchat

Разберём сигналы, которые видит сервер при подключении.

| Сигнал | Источник | Что ломает |

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

| IP-адрес и ASN | TCP-соединение | Датацентр = бан |

| Геолокация по IP | GeoIP-база | Несовпадение со GPS |

| MCC/MNC | Заголовок от приложения | Оператор не совпадает с ASN |

| Часовой пояс | Device info | Расхождение с IP-гео |

| Locale | Accept-Language | en_US при IP Германии |

| Device fingerprint | X-Snap-* заголовки | Эмулятор, рутованный телефон |

Snapchat использует собственную систему антифрода, которая сравнивает эти поля между собой. Ключевое правило: всё должно указывать на одну страну и одного оператора. Если прокси даёт немецкий IPv6 от Deutsche Telekom, а телефон рапортует MCC 262 (Германия) — совпало. Если MCC 250 — бан.

Вот как выглядит проверка IP через API, которую стоит прогнать перед заходом в аккаунт:

```bash

curl -6 -s "https://ipapi.co/json/" | jq '{ip, country, asn, org}'

```

Ответ покажет, к какому оператору привязан адрес. Для Snapchat важно, чтобы `org` содержал имя мобильного оператора, а не хостера. `AS3320 Deutsche Telekom AG` — годится. `AS14061 DigitalOcean` — нет.

Архитектура IPv6-прокси для мобильного трафика

Классическая схема: клиент подключается к прокси-серверу по IPv4, а исходящий трафик идёт через IPv6-пул. Пул — это либо /64-подсеть от оператора, либо набор отдельных /128. Для Snapchat нужен режим sticky session: один клиент держит один адрес на всю сессию, обычно 10-30 минут.

Технически это реализуется через SOCKS5 с привязкой к source address. На сервере настраивается несколько IPv6-адресов на интерфейсе, и прокси выбирает исходящий по хешу от логина клиента. Так один и тот же пользователь всегда выходит с одного адреса, пока сессия жива.

```nginx

stream {

upstream snap_backend {

server [2001:db8:1::1]:443;

server [2001:db8:1::2]:443;

}

server {

listen [::]:443;

proxy_pass snap_backend;

proxy_bind \$remote_addr transparent;

proxy_timeout 30m;

}

}

```

Тут `proxy_bind` с `transparent` позволяет сохранять исходный адрес клиента при форвардинге. Для Snapchat важнее исходящий адрес, поэтому в реальной конфигурации bind ставится на конкретный IPv6 из пула, привязанный к сессии.

Ротация адресов и когда она вредит

Ротация — главный инструмент и главная грабля. Snapchat привязывает сессию к IP. Если адрес меняется посреди работы — приложение перелогинивается, а иногда и требует верификацию по SMS. Поэтому ротация должна быть привязана к событиям, а не к таймеру.

Правильные триггеры для смены адреса: новый логин, смена аккаунта, ручной рестарт сессии. Неправильные: каждые 5 минут по крону, каждый запрос, случайный выбор из пула.

Python-пример выбора адреса с привязкой к сессии:

```python

import hashlib

POOL = ["2001:db8:1::1", "2001:db8:1::2", "2001:db8:1::3"]

def pick_address(session_id: str) -> str:

h = hashlib.sha256(session_id.encode()).digest()

idx = int.from_bytes(h[:4], "big") % len(POOL)

return POOL[idx]

session = "user_42_snap"

addr = pick_address(session)

print(f"bind to [{addr}]")

```

Один session_id — один адрес. Пока сессия жива, IP не меняется. Это то, что ждёт Snapchat.

Геофильтры: как они видят ваш IP

Геофильтры в Snapchat привязаны к конкретным координатам и радиусу. Приложение запрашивает у сервера список фильтров для текущей локации. Сервер сверяет GPS с IP-геолокацией. Если GPS говорит «Берлин», а IP — «Франкфурт» (200 км разницы), фильтры Берлина могут не подгрузиться.

Точность GeoIP для IPv6 хуже, чем для IPv4. Базы MaxMind и IP2Location для IPv6 часто указывают город на уровне региона или вообще только страну. Это одновременно и проблема, и преимущество. Проблема: сложно попасть точно в нужный город. Преимущество: если база показывает только страну, Snapchat не может уличить в несовпадении города.

Для работы с геофильтрами нужно выбирать IPv6-пул, привязанный к нужному региону. Мобильные операторы обычно выдают адреса с привязкой к городу или области. Проверить можно так:

```bash

for ip in 2001:db8:1::1 2001:db8:1::2; do

echo -n "\$ip -> "

curl -6 -s --interface \$ip "https://ipapi.co/json/" | jq -r '.city + ", " + .country_name'

done

```

Если пул разбросан по городам — фильтры будут прыгать. Нужен пул из одной локации.

Реклама и почему она не показывается

Рекламный кабинет Snapchat (Snap Ads Manager) проверяет аккаунт жёстче, чем обычное приложение. Тут добавляется биллинг: страна платёжного метода, валюта, налоговый адрес. Если IP — Германия, а карта выпущена в Казахстане, кампанию отклонят на модерации.

IPv6-прокси решает первую часть — страну входа. Но рекламный кабинет требует стабильности: нельзя логиниться с разных IP каждый день. Snapchat помечает такие аккаунты как «shared» и режет охват. Нужен выделенный IPv6-адрес на аккаунт, желательно /128, а не из общего /64.

Цифры, которые стоит держать в голове: Snapchat режет охват рекламы на 40-60% для аккаунтов с подозрительной активностью. CPM вырастает с \$3-5 до \$8-12. Это не бан, а теневое понижение — кампания крутится, но на минимуме.

Практика: настройка SOCKS5 с IPv6-выходом

Соберём рабочий конфиг. Используем Dante или 3proxy. Вот пример для 3proxy с привязкой к IPv6-пулу:

```

3proxy.cfg

nserver 2001:4860:4860::8888

nserver 8.8.8.8

nscache 65536

timeouts 1 5 30 60 180 1800 15 60

auth strong

users user1:CL:pass1

allow user1

parent 1000 socks5 2001:db8:1::1 1080

socks -p1080 -i127.0.0.1

```

`parent` задаёт исходящий IPv6-адрес. Для каждого пользователя — свой parent с уникальным адресом. Так получаем sticky-сессии на уровне конфига.

Проверка, что трафик реально идёт через IPv6:

```bash

curl -x socks5h://user1:pass1@127.0.0.1:1080 https://api6.ipify.org

```

Должен вернуть IPv6-адрес из пула. Если возвращает IPv4 — где-то утечка, Snapchat это заметит.

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

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

Проверить MTU до сервера:

```bash

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

```

Если проходит — MTU 1500. Если нет — уменьшайте размер пакета, пока не найдёте предел. На прокси-сервере стоит выставить `net.ipv6.conf.all.mtu` в найденное значение минус 40 байт на заголовки.

Что ломается на практике

Пример: сервер на Ubuntu 22.04 с 3proxy 0.9.4, пул из /64 от Hetzner. Snapchat логинился, но через 2-3 минуты выкидывал с ошибкой сети. Причина — Hetzner не мобильный оператор, ASN в GeoIP помечен как датацентр. Snapchat видел несоответствие: IP из хостинга, а телефон рапортует мобильный оператор. Решение — переезд на пул от мобильного оператора через партнёра, ASN сменился на телеком, ошибки прекратились.

Пример: пул из 256 IPv6-адресов, ротация каждые 60 секунд. Snapchat начал требовать SMS-верификацию при каждом входе. Причина — смена IP внутри сессии. Решение — sticky-сессии на 30 минут, ротация только при логине. Верификация прекратилась, но осталась при первом входе с нового адреса.

Пример: рекламный кабинет Snap Ads, вход через IPv6 из /64-подсети, где другие адреса использовались под другие аккаунты. Модерация отклонила кампанию со ссылкой на «связанные аккаунты». Причина — Snapchat связывает адреса внутри одной /64. Решение — выделять /128 на каждый рекламный аккаунт, желательно из разных /64. Здесь помогает lexic.ml — выдают отдельные IPv6-адреса с привязкой к мобильным ASN, без соседей в подсети.

Пример: геофильтры Берлина не грузились при IP из Франкфурта. Расстояние 400 км, GeoIP показывал разные города. Решение — пул с привязкой к Берлину, проверка через ipapi перед заходом. После смены пула фильтры появились.

Итоги и что держать в голове

Snapchat смотрит на десяток сигналов, и IPv6-прокси решает только часть. Адрес должен быть из мобильного ASN, стабильный на время сессии, привязанный к нужному городу. Ротация — по событиям, не по таймеру. Для рекламных аккаунтов — выделенный /128 без соседей.

Проверяйте каждый адрес перед использованием: ASN, город, страну. Прогоняйте тестовый логин с нового IP, смотрите на поведение приложения. Если через минуту выкидывает — адрес палёный. Если работает стабильно 30 минут — годится для работы.

MTU не забывайте. IPv6 чувствителен к фрагментации, и на плохом канале медиа Snapchat будет глючить, хотя текстовые сообщения пройдут. Проверка ping6 с флагом -M do — обязательный шаг перед запуском пула в продакшн.