IPv6 прокси для Pinterest: массовый постинг без бана по cookies-цепочке

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

Pinterest завязан на cookies-цепочку жёстче, чем кажется. Аккаунт, device fingerprint и IP-адрес связываются в один кластер на стороне бэкенда. Стоит разорвать связь — и сессия улетает в shadowban, а не в явный бан. Посты публикуются, но их никто не видит. Хуже явного бана, потому что диагностировать сложно.

IPv4-прокси в массовом постинге живут недолго. Причина банальная: пул адресов /24 у большинства провайдеров засвечен. Pinterest видит, что с 50 аккаунтов идут запросы с одного C-класса, и помечает весь диапазон. Даже резидентские прокси не спасают — ASN один, подсеть одна, поведение однотипное.

IPv6 меняет расклад. У каждого аккаунта можно держать отдельный /64 — это 2^64 адресов на клиента. Pinterest не может заблокировать диапазон целиком, потому что за ним стоят тысячи реальных пользователей. Плюс IPv6-адреса выдаются блоками, и ротация внутри /64 выглядит как обычная смена IP у мобильного оператора.

Cookies-цепочка: что именно связывает Pinterest

Pinterest ставит около 12 cookies, но критичных всего четыре. `_auth` — основной токен сессии, живёт 30 дней. `_pinterest_sess` — серверная сессия, привязана к IP и User-Agent. `csrftoken` — защита от подделки запросов. И `_routing_id` — внутренний идентификатор для A/B-тестов, который тоже участвует в fingerprint.

Связка работает так: при логине сервер пишет в `_pinterest_sess` хеш от IP + UA + timestamp. При каждом запросе хеш пересчитывается и сверяется. Если IP сменился, но UA остался — сессия живёт. Если сменились оба — разлогин. Если IP прыгает между запросами внутри одной сессии — CSRF-проверка падает.

Отсюда правило: один аккаунт = один IPv6-адрес на всю жизнь сессии. Не ротация на каждый запрос, а sticky-сессия. Ротация допустима только между логинами, с полной очисткой cookies.

Настройка IPv6-прокси для sticky-сессий

Ключевой момент — привязка /64 к аккаунту, а не отдельного адреса. Внутри /64 можно менять адрес, но Pinterest видит изменение в пределах одной подсети и не триггерит защиту. Это критично для долгих сессий, когда провайдер перевыдаёт адрес.

Пример конфига nginx как forward-proxy с привязкой исходящего IPv6:

```nginx

stream {

upstream pinterest_backend {

server 151.101.0.84:443;

}

server {

listen [::]:8443;

proxy_pass pinterest_backend;

proxy_bind \$remote_addr transparent;

proxy_ssl_server_name on;

proxy_ssl_name pinterest.com;

}

}

```

`transparent` требует CAP_NET_ADMIN и настройки iptables. Для продакшена проще использовать SOCKS5 с явной привязкой исходящего адреса. Проверка, что адрес действительно исходящий:

```bash

curl -6 --interface 2a01:4f8:c17:1234::5 -s https://api64.ipify.org

```

Ответ должен вернуть именно `2a01:4f8:c17:1234::5`. Если возвращает другой — маршрутизация настроена криво, трафик уходит через дефолтный шлюз.

Python-клиент с привязкой к /64

Реальный код для постинга. Использует requests с кастомным source_address через socket. Работает с HTTP/2 через httpx, потому что Pinterest режет HTTP/1.1 на части эндпоинтов.

```python

import httpx

import socket

from http.cookiejar import MozillaCookieJar

class IPv6BoundTransport(httpx.HTTPTransport):

def __init__(self, source_addr, *args, **kwargs):

self.source_addr = source_addr

super().__init__(*args, **kwargs)

def handle_request(self, request):

sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)

sock.bind((self.source_addr, 0))

return super().handle_request(request)

def make_client(ipv6_addr, cookies_file):

jar = MozillaCookieJar(cookies_file)

jar.load(ignore_discard=True, ignore_expires=True)

transport = IPv6BoundTransport(ipv6_addr)

return httpx.Client(

transport=transport,

cookies=jar,

headers={

"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "

"AppleWebKit/537.36 (KHTML, like Gecko) "

"Chrome/120.0.0.0 Safari/537.36",

"Accept-Language": "en-US,en;q=0.9",

"X-Requested-With": "XMLHttpRequest",

},

timeout=30.0,

http2=True,

)

```

UA должен совпадать с тем, что был при логине. Если зашли с Chrome 120 на macOS — не меняйте на Linux Firefox. Pinterest сверяет UA в `_pinterest_sess` побайтово.

Ротация внутри /64: когда и как

Ротация адреса внутри /64 нужна в двух случаях. Первый — после смены аккаунта на том же прокси. Второй — при подозрении на rate-limit по конкретному адресу. Pinterest лимитирует сохранения: примерно 200 пинов в час на аккаунт, но при агрессивном поведении может резать по IP уже после 50.

Смена адреса — атомарная операция. Старый адрес удаляется из интерфейса, новый добавляется. Сессия при этом рвётся, но cookies остаются валидными, потому что `_pinterest_sess` привязан к /64, а не к конкретному адресу.

```bash

ip -6 addr del 2a01:4f8:c17:1234::5/64 dev eth0

ip -6 addr add 2a01:4f8:c17:1234::6/64 dev eth0

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

```

Между удалением и добавлением — пауза не меньше 30 секунд. Мгновенная смена выглядит как переподключение к сети, и Pinterest это логирует.

Таблица: сравнение схем проксирования

| Схема | Стоимость на 1000 аккаунтов | Вероятность бана за 30 дней | Сложность настройки |

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

| Datacenter IPv4 | ~\$200/мес | 60-80% | Низкая |

| Residential IPv4 | ~\$3000/мес | 15-25% | Средняя |

| Mobile IPv4 | ~\$5000/мес | 5-10% | Высокая |

| IPv6 /64 пул | ~\$80/мес | 8-15% | Высокая |

Цифры из практики 2023-2024. IPv6 выигрывает по цене, но требует грамотной инфраструктуры. Провайдер вроде lexic.ml даёт пул /64 по цене обычного VPS, что делает схему экономически осмысленной.

Типичные грабли

Первая и главная — использование одного /64 на несколько аккаунтов одновременно. Pinterest видит, что два аккаунта ходят из одной подсети с одинаковым UA и похожим поведением. Через 3-5 дней оба улетают в теневой бан. Один /64 = один активный аккаунт.

Вторая — игнорирование IPv6 leak. Если на машине есть IPv4-маршрут по умолчанию, часть запросов может уйти через него. Особенно это касается DNS и WebSocket-соединений. Проверяется через tcpdump на интерфейсе:

```bash

tcpdump -i eth0 -n 'host 151.101.0.84' -c 20

```

Если видите IPv4-пакеты к Pinterest — маршрутизация сломана. Нужно либо отключить IPv4 на интерфейсе, либо явно указать `precedence ::ffff:0:0/96 100` в gai.conf.

Третья — повторное использование cookies после бана. Даже если аккаунт разбанили через апелляцию, старые cookies отравлены. Pinterest помечает `_auth` как compromised и следит за ним. Нужен полный релогин с чистого /64.

Мониторинг состояния сессий

Без мониторинга схема разваливается за неделю. Нужно отслеживать минимум три метрики: HTTP-код ответов (403 и 429 — красные флаги), время ответа (рост выше 2 секунд — признак throttling), и наличие shadowban (посты публикуются, но не появляются в выдаче).

Пример health-check на Python:

```python

import httpx

from datetime import datetime

def check_account(client, username):

r = client.get(f"https://www.pinterest.com/{username}/")

if r.status_code == 403:

return "banned"

if r.status_code == 429:

return "rate_limited"

if r.elapsed.total_seconds() > 2.5:

return "throttled"

if "noindex" in r.headers.get("X-Robots-Tag", ""):

return "shadowbanned"

return "ok"

```

`X-Robots-Tag: noindex` на профиле — почти верный признак теневого бана. Pinterest ставит его, чтобы профиль не индексировался, но пользователь об этом не знает.

Что делать с забаненными аккаунтами

Явный бан — не конец. Pinterest часто снимает его после апелляции, если аккаунт не был явно спамерским. Но возвращать его на тот же /64 нельзя. Нужен свежий адрес из другой /64, полная очистка cookies, новый fingerprint браузера.

Теневой бан снимается сложнее. Обычно требуется 2-3 недели полного молчания аккаунта, потом постепенное возвращение активности — 1-2 пина в день, без массовых действий. Если через месяц профиль всё ещё в noindex — аккаунт мёртв, дешевле создать новый.

Создание нового аккаунта с того же /64, где сидел забаненный — гарантированный бан в течение суток. Pinterest связывает новые регистрации с подсетью и блокирует по ассоциации. Нужен либо свежий /64, либо пауза минимум 60 дней.

Итоги по инфраструктуре

Рабочая схема выглядит так: пул /64 от провайдера, по одному адресу на аккаунт, sticky-сессия через SOCKS5 или transparent proxy, ротация только между аккаунтами, мониторинг HTTP-кодов и X-Robots-Tag. Стоимость на 1000 аккаунтов — порядка \$80-150 в месяц, что в 20-30 раз дешевле резидентских IPv4.

Главное — не экономить на качестве пула. Дешёвые /64 из публичных диапазонов уже засвечены, Pinterest их знает. Нужен провайдер с чистыми блоками, желательно в ASN, которые не ассоциируются с хостингом. Проверяется через `whois` и историю abuse-репортов по ASN.