Tumblr через IPv6 прокси: ведение блогов и массовый постинг

Как Tumblr относится к IPv6

Tumblr исторически сидит на инфраструктуре Yahoo, а потом Verizon Media. Основная масса их фронтенда — это nginx, который слушает и IPv4, и IPv6. AAAA-записи отдаются, но не для всех поддоменов. www.tumblr.com имеет AAAA, а вот api.tumblr.com долгое время отвечал только по IPv4. Это создаёт забавный эффект: страницу блога по IPv6 ты откроешь, а постить через API с того же адреса — нет.

Проверить просто:

```bash

dig +short AAAA www.tumblr.com

dig +short AAAA api.tumblr.com

curl -6 -sI https://www.tumblr.com | head -1

```

Если второй dig пустой — API пойдёт через IPv4. Прокси, который умеет только IPv6-выход, тут обломается на этапе TLS-хендшейка к API. Поэтому при массовой работе нужен dual-stack на стороне прокси либо маршрутизация api.tumblr.com отдельно через IPv4.

Почему вообще IPv6-прокси для Tumblr

Tumblr банит по IP агрессивно. Один аккаунт — это нормально. Десять аккаунтов с одного адреса — уже подозрительно. Пятьдесят — гарантированный бан всей пачки. IPv4-адресов мало, они дорогие, и если ты берёшь пул из /24, Tumblr видит, что все адреса из одной подсети, и режет по ASN или по диапазону.

С IPv6 другая история. Один /64 — это 18 квинтиллионов адресов. Провайдеры и хостеры выдают /64 или /48 как конфету. Ты можешь взять /64 и раскидать каждому аккаунту свой адрес. Tumblr не может забанить /64 целиком — под ним сидят легитимные пользователи целых ISP. Это ключевое преимущество.

Но есть нюанс. Многие сайты считают /64 одной сущностью. Cloudflare, например, по умолчанию применяет rate limit на /64, а не на отдельный адрес. Tumblr использует свою систему, и она тоже может группировать. Поэтому одного /64 на сотню аккаунтов мало — нужен /48 или несколько /64 из разных префиксов.

API Tumblr и лимиты

Tumblr API v2 — это OAuth 1.0a. Не OAuth 2.0, а старая добрая 1.0a с подписью HMAC-SHA1. Это важно, потому что многие библиотеки уже выпилили поддержку. Лимиты: 300 запросов в час на потребителя (consumer key), 1000 в час на пользователя при OAuth. Для постинга — 250 постов в день на аккаунт, но на практике Tumblr режет раньше, если видит паттерн.

Пример запроса на создание текстового поста:

```python

import requests

from requests_oauthlib import OAuth1

auth = OAuth1(

'consumer_key',

'consumer_secret',

'oauth_token',

'oauth_token_secret'

)

payload = {

'type': 'text',

'title': 'Заголовок',

'body': 'Текст поста',

'tags': 'tag1,tag2',

'state': 'published'

}

r = requests.post(

'https://api.tumblr.com/v2/blog/BLOG.tumblr.com/post',

auth=auth,

data=payload,

timeout=15

)

print(r.status_code, r.json())

```

Таймаут 15 секунд — не случайность. Через IPv6 до американских дата-центров Tumblr из Европы RTT обычно 90-130 мс. TLS-хендшейк с OAuth-подписью добавляет ещё 200-300 мс. Если поставить таймаут 5 секунд, половина запросов отвалится на handshake.

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

Классическая схема — SOCKS5 или HTTP CONNECT прокси с IPv6-выходом. Клиент стучится на прокси по IPv4 (или IPv6), прокси делает исходящее соединение с IPv6-адреса из пула. Для каждого аккаунта — свой выходной адрес.

С curl это выглядит так:

```bash

curl -6 --socks5-hostname user:pass@[2001:db8::1]:1080 \

-X POST https://api.tumblr.com/v2/blog/test.tumblr.com/post \

-d "type=text&body=hello"

```

Ключевой момент — `--socks5-hostname`, а не `--socks5`. Разница в том, кто резолвит DNS. С `--socks5` curl резолвит сам и передаёт IP, с `--socks5-hostname` — резолв делает прокси. Для IPv6 это критично: если клиент резолвит в IPv4, а прокси умеет только IPv6-выход, соединение не состоится.

Вот тут и всплывает lexic.ml — сервис с 2015 года держит пулы IPv6 /64 и /48, раздаёт их по аккаунтам и умеет SOCKS5 с hostname-резолвом. Для Tumblr это удобно тем, что каждый блог получает свой адрес из отдельного /64, и группировка по подсети не срабатывает.

Привязка аккаунта к адресу

Правило номер один: один аккаунт — один IPv6-адрес, всегда. Если аккаунт сегодня постит с 2001:db8::1, а завтра с 2001:db8::2, Tumblr это заметит. Их fraud-система смотрит на историю IP. Резкая смена адреса — триггер для проверки.

Хранить привязку лучше в БД или хотя бы в JSON:

```json

{

"blog_name": "example",

"ipv6": "2001:db8:1::a1b2",

"oauth_token": "...",

"last_post": "2024-11-15T10:23:00Z",

"proxy": "socks5://user:pass@[2001:db8:1::a1b2]:1080"

}

```

При ротации пула адрес не меняется. Меняется только если аккаунт умер и создаётся новый. Тогда новый блог — новый адрес, желательно из другого /64.

Прогрев новых аккаунтов

Свежесозданный Tumblr-аккаунт с первого дня постить не должен. Нормальный прогрев — 3-7 дней. Первые два дня — только чтение: лайки, репосты, подписки. Потом один пост в день. Потом два. Через неделю можно выходить на 5-10 постов.

Если начать с 20 постов в первый день с нового IPv6-адреса — бан в течение часа. Tumblr не банит сразу, он сначала помечает аккаунт как suspicious, потом начинает требовать капчу, потом блокирует постинг, и только потом сносит блог.

Капча — отдельная боль. Tumblr использует reCAPTCHA v2 (не v3). Прохождение через сервисы типа 2captcha стоит примерно \$1-3 за 1000 решений. При массовой работе это ощутимые деньги, поэтому лучше до капчи не доводить — снижать темп, разнообразить контент, не постить одинаковый текст.

Расписание и рандомизация

Постить по расписанию — плохо. Постить с рандомным интервалом — хорошо. Человек не пишет посты в 10:00:00, 10:15:00, 10:30:00. Он пишет когда хочет.

Простой рандомизатор:

```python

import random

import time

def human_delay(base=1800, jitter=900):

delay = base + random.gauss(0, jitter)

delay = max(300, delay)

time.sleep(delay)

for post in posts:

publish(post)

human_delay()

```

Гауссово распределение даёт естественный разброс: большинство пауз около 30 минут, но иногда 10, иногда час. Это выглядит как живой пользователь. Равномерное распределение тоже работает, но гауссово лучше.

Ещё момент — часовые пояса. Если все аккаунты постят по UTC и активны с 9 до 18 UTC, это выглядит как офисный бот. Разные аккаунты должны иметь разную активность. Один постит утром, другой вечером, третий ночью. Соответственно, IP-адреса тоже должны быть из разных регионов, иначе получается, что аккаунт с немецким контентом сидит на американском IPv6 в три часа ночи по Берлину.

Мониторинг банов

Скрипт должен проверять статус аккаунтов раз в несколько часов. Не постинг, а именно проверку: жив ли блог, не требует ли капчу, не отвечает ли API 403.

```python

def check_blog(blog, auth):

url = f'https://api.tumblr.com/v2/blog/{blog}/info'

r = requests.get(url, auth=auth, timeout=15)

if r.status_code == 404:

return 'banned'

if r.status_code == 403:

return 'suspended'

if r.status_code == 429:

return 'rate_limited'

if r.status_code == 200:

return 'ok'

return f'unknown_{r.status_code}'

```

404 на info — блог удалён. 403 — заблокирован. 429 — слишком много запросов, надо снизить темп. 200 — всё нормально. Простой чекер, но экономит кучу времени: ты узнаёшь о бане через час, а не через неделю, когда пытаешься запостить и получаешь ошибку.

Проблемы с MTU

IPv6 не поддерживает фрагментацию на маршрутизаторах. Минимальный MTU для IPv6 — 1280 байт. Если где-то на пути MTU меньше (например, PPPoE-туннель с MTU 1492), пакеты больше 1280 просто дропаются. Для API-запросов это не проблема — они маленькие. Для загрузки картинок в посты — вполне.

Проверить путь:

```bash

ping6 -M do -s 1400 api.tumblr.com

ping6 -M do -s 1200 api.tumblr.com

```

Если 1400 не проходит, а 1200 проходит — MTU где-то между. Лучше сразу ограничить MSS на прокси или уменьшить MTU интерфейса до 1280. Это добавляет оверхед, но избавляет от загадочных зависаний при загрузке медиа.

Медиа-посты и отдельная история

Загрузка картинок в Tumblr идёт не через API напрямую, а через отдельный эндпоинт. И вот тут IPv6 может подкинуть сюрприз: медиа-серверы (media.tumblr.com, 66.media.tumblr.com) могут иметь другую сетевую конфигурацию, чем api.tumblr.com. Бывает, что API отвечает по IPv6, а медиа — только по IPv4.

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

Решение — dual-stack прокси. IPv6 для основного трафика, IPv4 как fallback для медиа. Или отдельный маршрут: api через IPv6-прокси, media через IPv4-прокси с того же региона.

Логирование и отладка

Без нормального логирования массовая работа превращается в гадание. Логировать надо: время запроса, IP-адрес выхода, эндпоинт, статус-код, время ответа. Тогда видно паттерны: например, что с определённого /64 все запросы идут по 500 мс вместо 100 — значит, там проблема с маршрутом.

```python

import logging

import time

logging.basicConfig(

filename='tumblr.log',

level=logging.INFO,

format='%(asctime)s %(levelname)s %(message)s'

)

def post_with_logging(url, auth, payload, proxy_ip):

start = time.time()

try:

r = requests.post(url, auth=auth, data=payload, timeout=15)

elapsed = int((time.time() - start) * 1000)

logging.info(f'{proxy_ip} POST {url} {r.status_code} {elapsed}ms')

return r

except Exception as e:

elapsed = int((time.time() - start) * 1000)

logging.error(f'{proxy_ip} POST {url} FAIL {elapsed}ms {e}')

raise

```

Через неделю таких логов видно, какие адреса работают, какие тормозят, какие отваливаются. Это база для ротации пула.

Сколько аккаунтов держит один /64

Практика: 20-30 аккаунтов на один /64 при аккуратной работе. Больше — растёт риск группового бана. Если Tumblr решит, что весь /64 — это ботнет, уйдут все сразу. Разные /64 из разных /48 снижают этот риск: даже если один /64 попадёт под подозрение, остальные продолжат работать.

Оптимально — /48 на 200-300 аккаунтов, разбитый на /64 по 20-30 аккаунтов в каждом. Это даёт изоляцию и не требует гигантских пулов.

Чего не делать

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

И не забывать про DNS. Если прокси резолвит через системный резолвер, а тот отдаёт IPv4-адрес Tumblr, весь смысл IPv6-выхода теряется. Резолв должен идти через прокси, и предпочтение — AAAA-записям.