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

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

Telegram Bot API работает поверх HTTPS. Серверы Telegram доступны и по IPv4, и по IPv6 — `api.telegram.org` резолвится в оба семейства. Но вот с клиентской стороны всё сложнее. Если вы запускаете бота на VPS с IPv6-адресом и без IPv4, `requests` или `aiohttp` уйдут по IPv6-маршруту. Telegram это принимает. Проблема не в протоколе, а в том, как вы выглядите со стороны.

Когда один IP отправляет 200 сообщений в минуту — это норма для бота. Когда тот же IP шлёт 20 000 запросов в час с разными `chat_id` — начинаются 429 и бан. Telegram не блокирует IPv6 как класс. Он блокирует паттерны поведения. Именно поэтому пул IPv6-адресов становится рабочим инструментом: каждый адрес из /64 выглядит как отдельный клиент.

Почему IPv6, а не IPv4

IPv4-прокси дорогие. Ресурс исчерпан, аренда одного адреса у провайдера — от 1 до 3 долларов в месяц, а пул из 500 адресов обойдётся в серьёзную сумму. IPv6 даёт /64 бесплатно вместе с VPS. Это 18 квинтиллионов адресов. Даже /112 — уже 65 536 адресов, чего хватит любому парсеру.

Второй момент — репутация. IPv4-подсети часто уже «сожжены»: кто-то до вас спамил с них, и Telegram держит диапазон в чёрном списке. Свежий IPv6 /64 от хостера обычно чистый. Роскомнадзор и прочие фильтры IPv6 почти не трогают — блокировки там точечные.

Третий — стоимость трафика. У многих хостеров IPv6-трафик не тарифицируется или тарифицируется дешевле.

Архитектура пула

Классическая схема: VPS с выделенным /64, на нём поднимается прокси-сервер, который слушает на всех адресах префикса. Клиент подключается к нужному адресу — исходящий трафик уходит с этого адреса. Для Telegram это выглядит как разные машины.

Схема простая:

```

VPS (2001:db8:1234::/64)

├── 2001:db8:1234::1 — основной адрес

├── 2001:db8:1234::2 — прокси-выход #1

├── 2001:db8:1234::3 — прокси-выход #2

└── ... до ::ffff

```

На стороне VPS нужно добавить адреса на интерфейс и настроить прокси. На стороне клиента — переключать исходящий адрес между запросами.

Настройка адресов на сервере

Добавляем диапазон на loopback или на основной интерфейс. Для 1000 адресов:

```bash

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

ip -6 addr add 2001:db8:1234::\${i}/64 dev eth0

done

```

Это работает, но при перезагрузке всё слетит. Правильнее — через systemd-unit или скрипт в `networkd-dispatcher`. На Debian с systemd-networkd:

```

/etc/systemd/network/10-eth0.network

[Match]

Name=eth0

[Network]

Address=2001:db8:1234::1/64

Address=2001:db8:1234::2/64

Address=2001:db8:1234::3/64

Gateway=2001:db8:1234::ffff

```

Для тысяч адресов такой файл раздувается. Тогда используют `ip -6 addr add` в скрипте запуска или netplan с диапазоном.

Прокси-сервер: 3proxy и его настройка

3proxy — самый лёгкий вариант. Конфиг для IPv6-прокси с авторизацией:

```

/etc/3proxy/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 user:CL:pass

allow user

proxy -6 -n -a -p8080 -i2001:db8:1234::1

proxy -6 -n -a -p8081 -i2001:db8:1234::2

proxy -6 -n -a -p8082 -i2001:db8:1234::3

```

Флаг `-6` заставляет слушать IPv6, `-i` привязывает к конкретному адресу. Каждый прокси-порт выходит с отдельного IP. Для 1000 адресов — 1000 строк, генерируются скриптом.

Альтернатива — Dante. Он тяжелее, но умеет SOCKS5 из коробки:

```

/etc/danted.conf

logoutput: syslog

internal: 2001:db8:1234::1 port = 1080

external: 2001:db8:1234::1

socksmethod: username

user.privileged: root

user.notprivileged: nobody

client pass {

from: 0.0.0.0/0 to: 0.0.0.0/0

log: error

}

socks pass {

from: 0.0.0.0/0 to: 0.0.0.0/0

command: bind connect udpassociate

log: error

}

```

Dante не так гибко ротирует адреса, зато стабильнее под нагрузкой.

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

Ключевой момент — как клиент выбирает адрес. Два подхода: через прокси-порт или через bind на локальный IPv6. Второй быстрее, но требует, чтобы все адреса были на клиентской машине.

Пример на Python с `aiohttp` и bind:

```python

import aiohttp

import asyncio

from itertools import cycle

IPS = [f"2001:db8:1234::{i}" for i in range(2, 1002)]

ip_pool = cycle(IPS)

async def send_message(session, chat_id, text, local_ip):

connector = aiohttp.TCPConnector(local_addr=(local_ip, 0))

async with aiohttp.ClientSession(connector=connector) as s:

url = f"https://api.telegram.org/bot{TOKEN}/sendMessage"

payload = {"chat_id": chat_id, "text": text}

async with s.post(url, json=payload) as resp:

return await resp.json()

async def main():

tasks = []

for chat_id in chat_ids:

local_ip = next(ip_pool)

tasks.append(send_message(None, chat_id, "hello", local_ip))

results = await asyncio.gather(*tasks, return_exceptions=True)

print(results)

asyncio.run(main())

```

`local_addr` в TCPConnector заставляет сокет биндиться на конкретный IPv6. Каждый запрос уходит с нового адреса. Telegram видит распределённую нагрузку.

Через прокси — медленнее, но не требует root на клиенте:

```python

import requests

proxies = {

"https": "http://user:pass@[2001:db8:1234::2]:8080"

}

r = requests.post(

f"https://api.telegram.org/bot{TOKEN}/sendMessage",

json={"chat_id": 123456, "text": "test"},

proxies=proxies,

timeout=10

)

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

```

Разница в задержке: bind даёт +2-5 мс, прокси добавляет 15-40 мс в зависимости от расстояния до VPS.

Ограничения Telegram Bot API

Нельзя просто так взять и разослать 100 000 сообщений. Telegram режет:

| Лимит | Значение |

|---|---|

| Сообщений в секунду на один чат | 1 |

| Сообщений в секунду в группу | 20 |

| Массовых рассылок в секунду | ~30 |

| Запросов к API в минуту с одного IP | ~3000 (неофициально) |

| Размер сообщения | 4096 символов |

| Файл через Bot API | 50 МБ (скачивание), 20 МБ (загрузка) |

При превышении — 429 с `retry_after`. Игнорировать нельзя: повторные нарушения ведут к временному бану IP или всего бота. Пул IPv6 помогает обойти лимит на IP, но не лимит на бота.

Кейс: рассылка на 50 000 подписчиков

Задача — разослать уведомление базе из 50 000 пользователей. Один IP, один бот. При 30 сообщениях в секунду — 28 минут. Telegram начнёт отдавать 429 уже на 5-й минуте, потому что лимит на бота — не только по IP, но и по `bot_token`.

Решение: разбить на пул ботов. 10 ботов, каждый со своим токеном, каждый через свой IPv6-адрес. Итого 300 сообщений в секунду, 5000 на бота. Время — 2 минуты 47 секунд. Плюс retry с экспоненциальной задержкой при 429.

Код для обработки 429:

```python

import time

import requests

def send_with_retry(url, payload, proxies, max_retries=5):

delay = 1

for attempt in range(max_retries):

try:

r = requests.post(url, json=payload, proxies=proxies, timeout=15)

if r.status_code == 429:

retry_after = r.json().get("parameters", {}).get("retry_after", delay)

time.sleep(retry_after)

delay *= 2

continue

return r.json()

except requests.RequestException as e:

time.sleep(delay)

delay *= 2

return None

```

Параметр `retry_after` приходит в теле ответа. Использовать его обязательно — иначе бан.

Кейс: парсинг каналов

Парсинг публичных каналов через Bot API невозможен — бот не видит сообщения в каналах, куда не добавлен. Обычно используют MTProto-клиенты (Telethon, Pyrogram) с user-аккаунтами. Здесь IPv6-пул критичен: Telegram банит user-аккаунты за резкие смены IP и за массовые запросы.

Схема: 50 аккаунтов, 50 IPv6-адресов, каждый аккаунт жёстко привязан к своему адресу. Смена IP для аккаунта — красный флаг. Telethon позволяет задать `local_addr`:

```python

from telethon import TelegramClient

client = TelegramClient(

session="acc_01",

api_id=API_ID,

api_hash=API_HASH,

connection=ConnectionTcpFull,

local_addr=("2001:db8:1234::42", 0)

)

```

Один аккаунт — один адрес — одна сессия. При парсинге 200 каналов с 50 аккаунтов получаем ~4 канала на аккаунт. Задержка между запросами — 3-5 секунд. За час собирается ~50 000 сообщений.

Если адрес начнёт светиться в жалобах — аккаунт улетит в бан. Поэтому пул должен быть с запасом: 20-30% адресов в резерве.

Кейс: геораспределённые прокси

Задача — обойти региональные ограничения на контент. Некоторые каналы и боты доступны только из определённых стран. Telegram не блокирует по гео, но контент внутри может быть недоступен.

Решение: IPv6-адреса из разных стран. Хостеры вроде Hetzner (Германия), OVH (Франция), Vultr (США, Япония) дают /64. Арендуете 5 VPS в 5 локациях, поднимаете прокси на каждой, ротируете по гео-признаку. Задержка до `api.telegram.org` из Франкфурта — 8-12 мс, из Токио — 180-220 мс. Для рассылок это не критично, для парсинга в реальном времени — важно.

Проверка задержки до конкретного DC Telegram:

```bash

for dc in 149.154.167.50 149.154.167.51 149.154.175.50; do

ping -6 -c 3 \$dc | tail -1

done

```

Telegram имеет 5 дата-центров. Bot API живёт в DC2 (Амстердам) и DC4 (Амстердам). MTProto распределяет аккаунты по DC. Если ваш прокси в Амстердаме — задержка минимальна.

Мониторинг и отладка

Что смотреть в первую очередь:

- Коды ответов. 200 — ок, 429 — rate limit, 403 — бот заблокирован пользователем, 400 — ошибка запроса.

- Время ответа. Рост с 50 мс до 500 мс — сигнал, что IP в сером списке.

- Процент 429. Больше 5% — снижайте скорость.

- Расход адресов. Если из 1000 адресов 200 уже отдают 429 — они сожжены, выводите из пула.

Простой мониторинг через curl:

```bash

for ip in 2001:db8:1234::2 2001:db8:1234::3 2001:db8:1234::4; do

start=\$(date +%s%N)

code=\$(curl -6 --interface \$ip -s -o /dev/null -w "%{http_code}" \

https://api.telegram.org/bot\$TOKEN/getMe)

end=\$(date +%s%N)

echo "\$ip -> \$code in \$(( (end - start) / 1000000 ))ms"

done

```

Запускать раз в 5 минут через cron. Адреса с кодом не 200 или с задержкой выше 300 мс — в карантин.

Правовые грабли

Массовые рассылки в Telegram без согласия получателей — это не техническая проблема, а юридическая. В России — нарушение 38-ФЗ о рекламе, штрафы до 500 000 рублей для юрлиц. В ЕС — GDPR, штрафы до 4% оборота. Технически пул IPv6 обходит лимиты, но не обходит закон.

Парсинг публичных каналов — серая зона. Данные публичные, но их сбор и хранение могут нарушать ToS Telegram. Аккаунты за это банят, и восстановить их нельзя. Прокси-провайдер может заблокировать вас при жалобах.

Использовать пул IPv6 стоит для легальных задач: уведомления подписчикам, которые дали согласие, аналитика своего канала, интеграции с CRM. Для спама — это путь к бану и суду. Технически работает, юридически — нет.

Итоги

IPv6-пул — рабочий инструмент для масштабирования Telegram-ботов. /64 от VPS даёт тысячи адресов бесплатно. 3proxy или Dante раздают их через прокси, либо клиент биндится напрямую. Ротация адресов снижает риск 429, но не отменяет лимиты на бота и аккаунт. Ключевое — не скорость, а равномерность: 30 сообщений в секунду с одного адреса безопаснее, чем 300 за секунду с десяти. И помните про `retry_after` — игнорирование этого параметра убивает бота быстрее, чем любые лимиты.