Почему Telegram-боты массово банят IPv6-подсети хостингов: анализ ASN и репутации диапазонов

Что происходит с Telegram-ботами на хостингах

Картина знакомая: бот работает месяцами, потом внезапно ловит `403` от `api.telegram.org`. Перезапуск не помогает. Смена токена — тоже. А стоит переехать на другой сервер — всё оживает. Причина почти всегда в том, что вы попали в забаненную IPv6-подсеть хостера.

Telegram банит не конкретный IP, а диапазоны. И IPv6 тут особенно уязвим: один `/64` — это 18 квинтиллионов адресов, и если в нём замечен спам-бот, инфраструктура Telegram может пометить весь блок. Владельцы VPS из этого блока получают отказ на пустом месте.

Проблема усугубляется тем, что хостеры выдают IPv6 бесплатно и щедро. Абузеры это знают и используют. Один клиент с `2001:db8:aaaa::/64` может за пару дней похоронить репутацию всего диапазона.

Почему именно IPv6 и почему именно подсети

IPv4-адреса на хостингах дорогие и выдаются поштучно. Каждый адрес — учтённый ресурс. Абузеру приходится покупать новые или менять провайдера, чтобы продолжать спамить. Экономика работает против него.

С IPv6 всё иначе. Хостер даёт `/64` или даже `/48` в базовом тарифе за 0 рублей. Абузер получает огромный пул и может ротировать адреса внутри него, не платя ни копейки. Telegram видит поток запросов с одного диапазона и банит префикс целиком.

Блокировка по префиксу — стандартная практика для крупных API. Cloudflare, Google, AWS делают то же самое. Логика простая: если из `/64` за сутки прилетело 50 000 запросов от новых ботов с подозрительными паттернами — проще забанить весь `/64`, чем разбираться с каждым адресом.

Как Telegram определяет «плохие» диапазоны

Точного алгоритма Telegram не публикует. Но по косвенным признакам и наблюдаемому поведению можно восстановить примерную логику.

Считаются метрики по префиксу: количество новых ботов, зарегистрированных с адресов диапазона за единицу времени, доля запросов, получивших `429` или `403`, частота создания ботов с похожими паттернами (одинаковые `setWebhook` URL, схожие тайминги), жалобы пользователей на спам от ботов с этих адресов.

Дальше работает порог. Превышение — бан префикса на срок от нескольких часов до недель. Иногда — перманентно. Восстановление репутации диапазона — задача хостера, не ваша.

Есть ещё один слой: ASN. Telegram смотрит на автономную систему, из которой идут запросы. Если ASN известна как «помойка» — хостинг с дешёвыми VPS, где 80% клиентов крутят парсеры и спам-боты — бан прилетает быстрее и держится дольше.

Таблица: типичные ASN и их репутация

| ASN | Провайдер | Тип | Наблюдаемое поведение |

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

| AS14061 | DigitalOcean | VPS | Частые баны `/64`, восстановление 2-7 дней |

| AS16276 | OVH | VPS/Dedicated | Средняя репутация, баны точечные |

| AS24940 | Hetzner | VPS/Dedicated | Умеренные баны, зависит от подсети |

| AS20473 | Vultr | VPS | Частые баны на дешёвых тарифах |

| AS9009 | M247 | VPS/VPN | Высокий риск, много абуза |

| AS210644 | Aeza | VPS | Нестабильная репутация |

Таблица отражает общие тренды, а не гарантию. Внутри одного провайдера разные `/64` могут иметь разную репутацию. Hetzner в целом чище, чем M247, но конкретный диапазон может быть уже отравлен.

Как проверить, забанен ли ваш IPv6

Первым делом — прямой запрос к API и чтение ответа. Telegram не всегда возвращает явный `403` с текстом «banned». Иногда это `401` с невнятным описанием или таймаут.

```bash

curl -6 -sS -w "\nHTTP: %{http_code}\n" \

"https://api.telegram.org/bot/getMe"

```

Если получаете `403` с телом вроде `{"ok":false,"error_code":403,"description":"Forbidden: bot was blocked"}` — это не бан IP, это блок бота. А вот `{"ok":false,"error_code":403,"description":"Forbidden"}` без деталей — часто признак блокировки на уровне сети или префикса.

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

```bash

curl -6 -sS https://ifconfig.co

curl -4 -sS https://ifconfig.co

```

Если IPv6-запрос висит или отваливается по таймауту, а IPv4 работает — проблема на уровне маршрутизации или фильтрации, не обязательно бан Telegram. Сравните поведение.

Python-скрипт для диагностики

Простой скрипт, который покажет, что именно происходит с вашим ботом и сетевым стеком.

```python

import socket

import requests

from requests.exceptions import RequestException, ConnectTimeout

TOKEN = "123456:ABC-DEF..."

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

def check_ipv6():

try:

s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)

s.connect(("2001:4860:4860::8888", 80))

return s.getsockname()[0]

except OSError as e:

return f"no ipv6: {e}"

finally:

s.close()

def probe_api():

try:

r = requests.get(f"{API}/getMe", timeout=10)

return r.status_code, r.text[:200]

except ConnectTimeout:

return None, "connect timeout"

except RequestException as e:

return None, str(e)[:200]

if __name__ == "__main__":

print("IPv6:", check_ipv6())

code, body = probe_api()

print("API:", code, body)

```

Запустите дважды: с флагом `-4` и `-6` через переменную окружения или отдельными сессиями. Разница в поведении покажет, где зарыта собака.

Почему смена IPv6 внутри `/64` не помогает

Классическая ошибка: «у меня же `/64`, сменю адрес — и всё заработает». Не работает. Telegram банит префикс, а не отдельный адрес. Смена `2001:db8:aaaa:1::1` на `2001:db8:aaaa:1::2` ничего не даёт — вы в том же `/64`.

Хуже того, некоторые провайдеры выдают статический `/64`, привязанный к VM. Сменить его без пересоздания сервера нельзя. А пересоздание — это новый IP, но часто из того же пула хоста, то есть из соседнего отравленного диапазона.

Вот тут и выручает внешний прокси-слой. Если трафик к `api.telegram.org` идёт через отдельный пул адресов с чистой репутацией — бан на хостерском диапазоне перестаёт быть вашей проблемой. Именно для таких сценариев используют IPv6-прокси пулы вроде lexic.ml, где адреса не пересекаются с массовыми хостингами и не наследуют их репутацию.

Кейс: DigitalOcean и `/64` после спам-волны

Пример: клиент запустил Telegram-бота на дроплете DigitalOcean (AS14061), регион Frankfurt. Бот работал три недели. На четвёртой — `getUpdates` начал возвращать `403` с пустым телом. При этом `getMe` проходил. Странно, но объяснимо: `getMe` — лёгкий метод без нагрузки, а `getUpdates` — тяжёлый, и именно на нём срабатывает фильтр.

Причина выяснилась после проверки подсети: в том же `/64` другой клиент DO крутил рассылку спама через 40+ ботов. Telegram пометил префикс. Наш клиент попал под раздачу.

Решение: переезд на IPv4-адрес того же дроплета (у DO он есть по умолчанию) плюс настройка `curl`/`requests` на принудительный IPv4. Бот ожил в течение часа. Через 6 дней проверили IPv6 — репутация восстановилась, но клиент остался на IPv4 для надёжности.

Кейс: Hetzner и ASN-фильтр

Другой сценарий: сервер на Hetzner (AS24940), свежий `/64`. Бот только что развёрнут, никакой активности не было. `getMe` возвращает `403` сразу. Пересоздание сервера с новым IP из другого `/64` — та же история.

Причина: конкретный `/64` уже был в чёрном списке Telegram до того, как клиент его получил. Hetzner переиспользует диапазоны после ухода предыдущих клиентов, а «остывание» репутации занимает время. Новый арендатор получает отравленный блок.

Решение: запрос в поддержку Hetzner на смену IPv6-подсети с обоснованием. Hetzner пошёл навстречу, выдал другой `/64`. Проблема ушла. Но это сработало потому, что клиент был на выделенном сервере — на дешёвых VPS поддержка отвечает медленнее и не всегда меняет подсеть.

Кейс: M247 и полный бан ASN

Сервер на M247 (AS9009), тариф VPS за €5. Бот работал неделю, потом — стабильный `403` на все методы. Смена IPv6 внутри `/64` — безрезультатно. Смена на IPv4 — тоже `403`. Переезд на другой сервер того же провайдера — `403`.

Причина: M247 известна как провайдер с высоким уровнем абуза, и Telegram, судя по поведению, применяет фильтр на уровне ASN для части диапазонов. Не все адреса M247 забанены, но конкретный пул, куда попал клиент, был закрыт целиком.

Решение: смена провайдера. Клиент переехал на OVH, бот заработал с первого запроса. Урок: дешёвый VPS в «шумной» ASN — лотерея. Экономия €3/мес оборачивается днями простоя.

Как снизить риск попадания под бан

Первое — не размещать бота в дешёвых VPS-пулах с высокой долей абуза. Разница в €5-10/мес не стоит рисков. Hetzner, OVH, Scaleway — приемлемый уровень. M247, дешёвые реселлеры, «безлимитные» VPS за €2 — плохая идея.

Второе — использовать отдельный исходящий IP для Telegram-трафика. Если бот ходит через прокси или NAT с чистым адресом, репутация хостера перестаёт иметь значение. Настройка простая: `HTTPS_PROXY` в окружении или явный прокси в коде.

```python

import os

import requests

proxies = {

"https": os.environ["TG_PROXY"],

}

r = requests.get(

"https://api.telegram.org/bot/getMe",

proxies=proxies,

timeout=15,

)

```

Третье — мониторить статус. Простой healthcheck раз в 5 минут с алертом при `403` даёт фору: вы узнаете о бане раньше, чем пользователи.

Что делать, если бан уже случился

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

Если IPv4 тоже забанен — проблема на уровне ASN или конкретного IP. Смена IP внутри того же хостера может не дать результата. Тогда — либо ждать (репутация восстанавливается от нескольких дней до недель), либо менять провайдера, либо ставить прокси-слой.

Не пытайтесь «обойти» бан сменой User-Agent или заголовков. Telegram фильтрует по сетевому уровню, а не по HTTP-метаданным. Заголовки не помогут.

Итог

Баны IPv6-подсетей — не баг, а фича антиспам-инфраструктуры Telegram. Хостеры с дешёвыми VPS страдают первыми, потому что абузеры любят бесплатные `/64`. Понимание того, как работают фильтры по префиксу и ASN, экономит часы диагностики.

Проверяйте сетевой стек до того, как писать в поддержку. Сравнивайте IPv4 и IPv6. Держите запасной путь в виде прокси или второго провайдера. И не селитесь в ASN с дурной славой, если бот — часть продакшена, а не эксперимент на выходные.