Facebook через IPv6 прокси: таргетинг, парсинг и обход геоблокировок

Как Facebook видит IPv6

Facebook принимает IPv6 с 2012 года. Двухстековые AAAA-записи отдаются для `facebook.com`, `graph.facebook.com`, `connect.facebook.net`. Инфраструктура разбита на edge-узлы, каждый анонсирует свой /48 или /56 через anycast BGP. Для клиента это значит одно: адрес, с которого приходит запрос, уходит в лог вместе с ASN и геолокацией по базе MaxMind.

Когда вы заходите с обычного домашнего IPv6 от провайдера, Facebook видит префикс, привязанный к региону. Ростелеком отдаёт адреса из блока, привязанного к Москве. Немецкий Hetzner — к Франкфурту. Это работает как гео-метка, которую нельзя подделать заголовком `X-Forwarded-For`. Отсюда растут все проблемы с таргетингом, парсингом и блокировками.

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

Почему IPv4-прокси упирается в потолок

Классический резидентный IPv4-прокси стоит от 3 до 15 долларов за гигабайт. Пул адресов ограничен, провайдеры давно распродали свободные блоки. Один адрес переиспользуется сотнями клиентов, Facebook это видит через поведенческий анализ и режет по репутации.

IPv6 меняет экономику. Провайдер выдаёт клиенту /64 — это 18 квинтиллионов адресов. Дата-центр получает /48, может нарезать /64 подсети и раздавать их как отдельные «прокси». Стоимость адреса падает в сотни раз. Проблема одна: репутация. Facebook знает диапазоны хостеров и относится к ним с подозрением.

Рабочая схема — брать IPv6 от residential-провайдеров, а не от OVH или DigitalOcean. Тогда адрес выглядит как домашний, но вы управляете им программно.

Настройка туннеля

Простейший вариант — SOCKS5 поверх IPv6. Поднимаем на сервере в нужной стране, клиент ходит через него.

```bash

ssh -6 -D 1080 -N -f user@[2001:db8::1]

```

Это даёт локальный SOCKS5 на порту 1080, весь трафик уходит через IPv6-адрес сервера. Проверяем:

```bash

curl -6 --socks5-hostname localhost:1080 https://api.ipify.org

```

Ответ — IPv6-адрес сервера. Теперь Facebook видит его. Для ротации адресов нужен пул: несколько /64 на одном интерфейсе, привязка через `ip -6 addr add` и переключение исходящего адреса через `ip -6 route`.

Ротация адресов без разрыва сессии

Facebook привязывает сессию к паре (cookie, IP). Смена адреса посреди логина выкидывает на чекпоинт. Ротацию делают между сессиями, не внутри.

```python

import requests

PROXIES = [

"socks5h://[2001:db8:1::1]:1080",

"socks5h://[2001:db8:2::1]:1080",

"socks5h://[2001:db8:3::1]:1080",

]

def fetch_profile(user_id, proxy):

url = f"https://graph.facebook.com/v18.0/{user_id}"

r = requests.get(url, proxies={"https": proxy}, timeout=15)

return r.json()

for uid in ["4", "5", "6"]:

print(fetch_profile(uid, PROXIES[hash(uid) % len(PROXIES)]))

```

Ключевой момент — `socks5h`, а не `socks5`. Буква `h` заставляет резолвить DNS на стороне прокси. Иначе запрос к `graph.facebook.com` уйдёт с вашего локального резолвера, и Facebook увидит DNS-запрос из вашей страны.

Таргетинг и гео-привязка

Рекламный кабинет Facebook определяет страну показа по IP аккаунта, а не по настройкам. Если вы сидите с российского адреса и пытаетесь запустить кампанию на Германию, аукцион отдаст трафик, но CPM будет выше на 20–40%. Причина — Facebook не доверяет несоответствию.

С IPv6-прокси из Франкфурта картина другая. Адрес попадает в немецкий префикс, MaxMind отдаёт country=DE, city=Frankfurt. Система считает аккаунт локальным. CPM падает до уровня местных рекламодателей.

Проверить, что видит Facebook, можно через их же debug-инструмент:

```bash

curl -6 --socks5-hostname localhost:1080 \

"https://graph.facebook.com/debug_token?input_token=TOKEN&access_token=TOKEN"

```

В ответе будет `data.ip_address` — тот адрес, который Facebook зафиксировал при выдаче токена. Если он не совпадает с ожидаемым регионом, токен выдавался через другой прокси.

Парсинг: где ломается

Graph API отдаёт данные через официальные endpoints, но требует токен и лимиты. Публичный парсинг HTML идёт через обычные запросы, и тут IPv6-прокси критичен.

Facebook режет по частоте: с одного /64 больше 200 запросов в час — прилетает 429. С одного /128 — примерно 20–30 запросов. Разница в том, что /64 можно нарезать на тысячи /128 и раскидать запросы.

```python

import asyncio, aiohttp

async def fetch(session, url, proxy):

try:

async with session.get(url, proxy=proxy, timeout=10) as r:

return r.status, await r.text()

except Exception as e:

return None, str(e)

async def main(urls, proxies):

async with aiohttp.ClientSession() as session:

tasks = []

for i, url in enumerate(urls):

proxy = proxies[i % len(proxies)]

tasks.append(fetch(session, url, proxy))

return await asyncio.gather(*tasks)

proxies = [f"socks5://[2001:db8:{i:x}::1]:1080" for i in range(1, 50)]

urls = [f"https://www.facebook.com/profile.php?id={1000+i}" for i in range(500)]

results = asyncio.run(main(urls, proxies))

print(sum(1 for s, _ in results if s == 200))

```

С 50 адресами и задержкой 200 мс на запрос реально вытянуть 500 профилей за 15–20 секунд без единого 429. С одним IPv4-адресом та же задача растянется на час или упрётся в капчу.

Задержки и MTU

IPv6-туннели добавляют оверхед. Инкапсуляция в 6in4 съедает 20 байт на заголовок, MTU падает с 1500 до 1480. При неправильной настройке PMTUD крупные пакеты молча теряются, TLS-хендшейк зависает на этапе передачи сертификата.

Типичные цифры для прямого IPv6 до edge Facebook:

| Маршрут | RTT, мс | Потери |

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

| Москва → Франкфурт | 28 | 0.1% |

| Москва → Амстердам | 35 | 0.2% |

| Новосибирск → Франкфурт | 62 | 0.5% |

| Через 6in4-туннель | +15 | 1.2% |

Если RTT выше 100 мс, Facebook начинает чаще показывать капчу при логине. Это не блокировка, а эвристика на аномальную задержку.

Когда IPv6 не работает

Не все сайты отдают AAAA-записи. Facebook отдаёт, но часть CDN внутри — нет. Если клиент настроен только на IPv6 и не имеет fallback на IPv4, запрос к `static.xx.fbcdn.net` может зависнуть. Решение — dual-stack на клиенте, приоритет IPv6 через `gai.conf`.

Второй случай — провайдер режет IPv6. Некоторые корпоративные сети блокируют протокол полностью. Туннель через IPv4 спасает, но теряется главное преимущество — residential-префикс.

Реальный пример: рекламный кабинет на Германию

Агентство вело кампанию для немецкого клиента из Москвы. Изначально — российский IPv4, CPM 4.20 EUR, CTR 0.8%. Facebook показывал объявления, но аукцион занижал охват.

Перевели кабинет на IPv6-прокси из Hetzner Falkenstein. Адрес 2a01:4f8::/32, страна DE. Через неделю CPM упал до 2.90 EUR, CTR вырос до 1.4%. Причина — Facebook перестал считать аккаунт «иностранным» и поднял trust score.

Через месяц Hetzner-префикс попал в фильтр как дата-центровый. CPM вернулся к 4.10. Переключились на residential-IPv6 от немецкого провайдера Deutsche Glasfaser. Стабильно 2.80–3.00 EUR. Вывод: репутация префикса важнее страны.

Парсинг маркетплейса

Facebook Marketplace отдаёт данные только авторизованным сессиям и привязывает их к региону. Запрос из неправильной страны — пустой ответ или 403.

Схема: логин через IPv6-прокси нужной страны, сохранение cookies, дальнейшие запросы через тот же адрес. Смена адреса внутри сессии — мгновенный чекпоинт.

```bash

curl -6 --socks5-hostname localhost:1080 \

-c cookies.txt -b cookies.txt \

-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \

"https://www.facebook.com/marketplace/108484758438479/search/?query=iphone"

```

Куки живут 30–90 дней при активном использовании. Один /128 тянет одну сессию. Для десяти параллельных сессий нужно десять адресов из одного /64 — Facebook видит их как соседей и не банит всю подсеть.

Инструменты и обвязка

Для массовых задач удобно держать пул прокси на одном сервере. Каждый /128 вешается на loopback, SOCKS5 слушает на своём порту. Управление — через systemd или простой Python-демон.

```bash

for i in \$(seq 1 100); do

ip -6 addr add 2001:db8::\$i/128 dev lo

done

```

Дальше — `3proxy` или `danted` с конфигом на диапазон. Ротация — переключением исходящего адреса через `ip -6 route replace default via ... src 2001:db8::42`.

Для управления пулом на несколько тысяч адресов используют готовые панели. Сервис lexic.ml держит IPv6-прокси с 2015 года и отдаёт /64-подсети под клиента — это снимает возню с ручной нарезкой и даёт готовый SOCKS5-endpoint на каждый адрес.

Что убивает аккаунт быстрее всего

Не геолокация, а поведение. Facebook смотрит на тайминги, порядок запросов, движения мыши. IPv6-прокси решает сетевую часть, но если вы логинитесь в 3 часа ночи по времени страны аккаунта и делаете 500 запросов в минуту — бан придёт независимо от адреса.

Правило простое: один адрес — одна сессия — один профиль. Задержки между действиями 2–5 секунд. Логин в рабочие часы целевого региона. Тогда IPv6-прокси работает месяцами без ротации.