Zapret Wiki

Недавно обновлено

время чтения ~18 мин.

.md

🧯 Ограничения WSS для Telegram: что не работает и почему

О чём заметка

Симптомы, с которыми сталкиваются пользователи WSS-транспорта в ZaStoGram и мостов вроде tg-ws-proxy, их причины и способы их проверить: не грузятся стикеры или медиа из части датацентров, загрузка идёт рывками, вход не проходит, звонки не соединяются. Как сам транспорт устроен — релеи, правила кадров, лестница запасных путей через Cloudflare, — разобрано в парной заметке WSS для Telegram: MTProto внутри WebSocket; здесь из неё берутся только выводы.

Откуда взяты данные

Статья переписана 16 октября 2026 года. Основа — исходный код и сообщения коммитов ZaStoGram для Android (версия 1.1.30 от 15 октября 2026 года) и Desktop (выпуск zsg-7.3.1 от 16 октября 2026 года), модуля telegram_proxy в ZapretGUI и tg-ws-proxy. Симптомы взяты из того, как авторы этих проектов описали жалобы и журналы тестировщиков, и из обращений в трекер tg-ws-proxy. Числа вроде «соединение замирает на 16 КБ» измерены в конкретных сетях: у другого провайдера всё может выглядеть иначе.

TL;DR

  1. Если текст ходит, а стикеры, эмодзи или фото из части датацентров не грузятся, почти всегда закрыт веб-релей одного датацентра в вашей сети. ZaStoGram тогда уводит этот датацентр через Cloudflare, и медиа начинают грузиться, но заметно медленнее.
  2. Самый медленный запасной путь — туннель через воркер Cloudflare. На мобильной сети такие соединения замирают примерно на 16 КБ, поэтому файл через туннель качается кусками по 8 КБ.
  3. Медиа аккаунтов без Premium частично лежат в DC203, у которого нет веб-релея вообще. До 16 октября 2026 года туда вёл только туннель через воркеры, и когда у них кончался суточный лимит Cloudflare в 100 000 запросов, эти файлы переставали грузиться у всех. Теперь DC203 идёт и через домены за Cloudflare.
  4. Звонки через WSS не идут ни в одной реализации: голос и видео Telegram ходят по UDP мимо любого TCP-транспорта. Их закрывают пакетным обходом zapret или VPN.
  5. Desktop-клиент не отключает перенаправление загрузок на CDN-серверы Telegram, а у них нет веб-релеев, поэтому такие загрузки уходят прямым TCP. Android при включённом WSS просит сервер отдавать файлы без перенаправления.
  6. Часть подписей в интерфейсе устарела: «DC2/DC4 only» и «No certificate check is done» в Desktop не соответствуют коду. Проверять поведение нужно по журналу и диагностике, а не по подписям.

Где искать причину

WSS-транспорт решает одну задачу: доставить MTProto до датацентра Telegram, когда прямые адреса Telegram закрыты. Всё, что не помещается в эту задачу, он не решает. Это звонки (они идут по UDP), загрузки с отдельных CDN-серверов Telegram и пропускная способность запасных путей через Cloudflare. Поэтому первым делом стоит понять, к какому слою относится симптом: к самому подключению, к одному датацентру, к запасному пути или к трафику, который WSS не везёт вовсе.

Порядок, в котором ZaStoGram ищет путь к датацентру, подробно описан в парной заметке. Коротко: сначала веб-релей Telegram kwsN.web.telegram.org, затем 20 доменов за Cloudflare, затем туннель через три воркера Cloudflare, а если всё на паузе — снова домены. Каждая ступень медленнее предыдущей, и большинство симптомов ниже — это признаки того, что соединение спустилось на одну из нижних ступеней. Почему сервер Telegram при этом так часто молчит, а не сообщает об ошибке, разобрано в разделе об архитектуре Telegram.

Не грузятся стикеры, эмодзи или фото из части датацентров

Это самый частый и самый обманчивый случай. Переписка идёт, скорость нормальная, ошибок нет, но часть содержимого не загружается или грузится минутами. Обычно это выглядит как «фото открываются, а эмодзи, реакции и стикеры нет».

Причина в том, что содержимое Telegram разложено по пяти датацентрам, а у каждого датацентра свой веб-релей и свой адрес входа. Провайдер может закрыть один из них и оставить остальные. В замере 9 августа 2026 года в одной российской сети релей DC2 был открыт, а релей DC1 не отвечал ни по IPv4, ни по IPv6, и прямой адрес DC1 тоже был закрыт. Фото на DC2 грузились, эмодзи и реакции на DC1 — нет. 15 октября 2026 года пользователь tg-ws-proxy написал, что его провайдер закрыл по IP и адрес 149.154.167.220, то есть релей DC2 и DC4.

Проверять доступность нужно по TCP, а не ping. Фильтр провайдера режет соединения по порту и оставляет пинг живым: в августовском замере все четыре адреса отвечали на ping, и только один принимал TCP на порт 443. В Windows проверка выглядит так:

tnc 149.154.174.100 -Port 443

Смотреть нужно на строку TcpTestSucceeded. Адрес пишется без порта, порт — отдельным параметром: вариант Test-NetConnection 1.2.3.4:443 PowerShell принимает за имя хоста и висит до таймаута, что легко спутать с блокировкой. Адреса релеев: 149.154.174.100 для DC1 и DC3, 149.154.170.100 для DC5. У DC2 и DC4 рабочих адресов два, 149.154.167.220 и 149.154.167.99 (его отдаёт DNS), и проверять стоит оба. С 16 октября 2026 года ZaStoGram и ZapretGUI держат оба и при отказе одного сами переходят на второй; tg-ws-proxy по умолчанию знает только .220.

Что с этим делает клиент, зависит от реализации. ZaStoGram после трёх неудач подряд ставит релей на паузу и уходит на домены за Cloudflare, а затем в туннель. Медиа тогда начинают грузиться, но медленнее; это ожидаемое поведение, а не поломка. tg-ws-proxy и ZapretGUI по умолчанию ходят через релей только для DC2 и DC4, а для остальных датацентров сразу используют свои запасные пути. Поэтому инструкция tg-ws-proxy советует владельцам аккаунтов без Premium, у которых не грузятся фото и видео, оставить в настройке «DC → IP» только 4:149.154.167.220: остальные датацентры тогда пойдут через Cloudflare.

Медиа грузятся медленно или встают: туннель через Cloudflare

Туннель — третья ступень лестницы. Клиент подключается к воркеру Cloudflare на домене workers.dev, а воркер сам открывает TCP до датацентра Telegram. Для провайдера это соединение с Cloudflare, и поэтому туннель работает там, где закрыты и релеи, и сами адреса Telegram. Платить за это приходится скоростью.

В конце сентября 2026 года тестировщики ZaStoGram на мобильной сети заметили, что соединение через туннель замирает примерно на 16 КБ входящих данных: ни одна сессия в их журналах не прошла дальше 13–15 КБ. Обычный кусок файла в Telegram — 128 КБ, так что через туннель он не доходил никогда: в журналах тестировщиков не догрузился ни один из 48 стикеров и ни один из 62 смайликов. Клиенты подстроились под этот порог.

Через туннель файл качается кусками по 8 КБ, до восьми кусков параллельно. После нескольких килобайт ответа соединение закрывается на границе пакета и открывается новое: Android делает это после 6 КБ, Desktop — после 4 КБ для файлов и 8 КБ для чата. Лимит повторов для одного запроса на Android поднят с 6 до 30, потому что после переключения в туннель видео в 3,5 МБ и архив в 35 КБ падали с ошибкой исчерпания повторов. Проще говоря: через туннель файл приходит множеством мелких порций по отдельным соединениям, поэтому медленнее, но приходит.

Отдельный и неприятный случай — DC203. Из него Telegram отдаёт часть медиа аккаунтам без Premium, и веб-релея у этого датацентра нет совсем. До 16 октября 2026 года клиенты возили его только туннелем, поэтому, когда у воркеров кончался лимит, первыми вставали именно эти медиа и именно у пользователей без подписки. Так было и вечером 16 октября: два из трёх воркеров отвечали 429, туннель ушёл на паузу, и Desktop пытался подключиться к DC203 напрямую, через закрытый TCP, — раз в несколько секунд, без результата. В тот же день выяснилось, что домены за Cloudflare несут и DC203 (kws203.‹домен› отвечает настоящим MTProto), и ZaStoGram с ZapretGUI перевели его на них: теперь лимит воркеров замедляет эти файлы, но не отключает. Отсюда частое заблуждение «у знакомого с Premium всё грузится, значит дело в подписке»: подписка здесь меняет только датацентр, из которого приходит файл.

Лимиты Cloudflare: 429, 503 и 403

Обе запасные ступени живут на чужой инфраструктуре и упираются в её ограничения.

Воркеры. У бесплатного тарифа Cloudflare Workers лимит — 100 000 запросов в сутки, со сбросом в полночь UTC. После исчерпания воркер отвечает кодом 429 с ошибкой 1027. Вечером 8 октября 2026 года единственный тогда воркер ZaStoGram исчерпал лимит, и медиа DC203 перестали грузиться у всех пользователей. По статистике Cloudflare, на которую ссылаются авторы, один воркер исчерпывал лимит каждый день к 10–12 часам UTC. С 9 октября воркеров три, на трёх разных учётных записях Cloudflare. Каждая установка начинает со случайного воркера, а ответивший 429 сразу уходит на паузу, не дожидаясь трёх отказов. В tg-ws-proxy такая же пауза для воркера, ответившего 429, в коде есть, но отключена ранним выходом из функции с пометкой «TODO: проверить код статуса после исчерпания дневного лимита»: исчерпавший лимит воркер продолжает получать запросы.

Домены за Cloudflare. Здесь отказ выглядит как 503 на запрос апгрейда. По тесту ZaStoGram от 27 сентября 2026 года соединение с таким доменом либо обслуживается сразу, либо отвечает 503 на каждую попытку; в комментариях кода доля отказов оценивается в 40–50%. Клиент повторяет апгрейд до восьми раз на том же TLS-соединении и ставит домены на паузу только после шести неудач подряд. В трекере tg-ws-proxy с этим симптомом пришло обращение от 14 октября 2026 года: часть картинок и голосовых грузится сразу, часть — минутами, в журнале 503. Автор проекта посоветовал настроить свой воркер по инструкции, и двум пользователям это помогло.

Код 403 от воркера. В обращении от 9 октября 2026 года пользователь tg-ws-proxy не мог отправить ни одной картинки. Автор ответил, что воркер отвечает 403: он либо заблокирован, либо упёрся в лимит 100 000 запросов, — и посоветовал выключить воркер. Это помогло.

Сам Cloudflare может быть закрыт. Документация tg-ws-proxy предупреждает, что подсеть Cloudflare может быть заблокирована, например в России, и что домен по умолчанию может перестать работать в любой момент из-за лимитов Cloudflare на одновременные WebSocket-подключения. Для своего домена там же требуется режим SSL Flexible. Если провайдер режет и Cloudflare, запасные ступени не помогут: в правила обхода стоит добавить cloudflare.com, cloudflare.dev и workers.dev.

CDN Telegram: Android и Desktop ведут себя по-разному

Слово CDN в этой теме означает две разные вещи, и их легко спутать. Первая — домены за Cloudflare из предыдущего раздела, в коде ZaStoGram они называются CdnFront. Вторая — собственные CDN-серверы Telegram: отдельные датацентры, с которых Telegram раздаёт популярные файлы. Сервер может ответить на запрос файла перенаправлением, и клиент пойдёт качать его с такого CDN-сервера. Веб-релеев у CDN-серверов Telegram нет.

Android при включённом WSS сообщает серверу, что перенаправления на CDN не поддерживает, и сервер отдаёт файл через обычный датацентр — тот, до которого WSS дотягивается. Desktop этого не делает: он принимает перенаправление, маршрута через WSS для CDN-сервера не находит и открывает к нему обычное TCP-соединение. В сети, где прямые адреса Telegram закрыты, такая загрузка просто зависает, хотя переписка при этом работает. Если в Desktop не грузятся отдельные популярные файлы, а в Android на той же сети всё в порядке, причина, скорее всего, в этом. Ни на какой ступени лестницы это не лечится.

«Соединение есть, данных нет»

Отдельный класс отказов: TCP открылся, TLS прошёл, WebSocket ответил 101, а данных от Telegram нет. С точки зрения сети соединение исправно, с точки зрения пользователя Telegram висит в «Соединение…».

У этого симптома три известные причины. Первая — нарушение правил кадров на стороне клиента: первый кадр короче 64 байт или два MTProto-пакета в одном кадре. Релей в обоих случаях молчит, не сообщая об ошибке; правила и замеры — в парной заметке. Вторая — «чёрная дыра»: в некоторых сетях релей принимает TLS и апгрейд, но данные до Telegram не доходят. До 27 августа 2026 года успешный апгрейд обнулял счётчик неудач ZaStoGram, и клиент бесконечно возвращался к такому релею. Пользователь видел это как «Telegram не ответил на запрос кода» при входе. Теперь тишина после отправки считается отказом: 5,5 секунды для обычного соединения и 20 секунд для медиа. ZapretGUI после переписывания своего ядра 28 сентября 2026 года использует те же пороги.

Третья причина — сам транспорт исправен, но клиент ждёт чего-то другого. В Desktop первый запуск длился 25–45 секунд, потому что поток соединения синхронно ждал проверку отзыва сертификата доменов за Cloudflare, а список отзыва ещё не был в кэше; исправлено 2 октября 2026 года. Там же после смены маршрута файлы не грузились около 9 секунд: ключ для медиа, созданный на одной стороне маршрута, на другой был неизвестен.

Как отличить блокировку от ошибки клиента

Если до релея не доходит даже TCP, режет сеть. Если TCP и TLS проходят, апгрейд отвечает 101, а дальше тишина — это либо «чёрная дыра», либо ошибка нарезки кадров. Обновите клиент: оба случая исправлены в ZaStoGram с конца августа 2026 года, и клиент теперь сам уходит с такого релея на запасную ступень.

Звонки

Голосовые и видеозвонки через WSS не идут ни в одной реализации. WebSocket работает поверх TCP, а звонки Telegram используют UDP и отдельные релеи, адреса которых выдаёт сервер в момент звонка. Транспорт, который везёт MTProto-сессию, звонков просто не видит. То же ограничение действует и для классического MTProxy; в FAQ tg-ws-proxy оно сформулировано как архитектурное ограничение MTProto-прокси.

В клиентах ZaStoGram это видно прямо в коде. Android создаёт звонок без прокси, какой бы прокси ни был выбран. В Desktop проверка «поддерживает ли прокси звонки» всегда отвечает «нет», поэтому галочка «Use proxy for calls» не появляется вовсе. В Android есть отдельный экспериментальный пункт «Звонки через TCP/TLS» в настройках прокси, под переключателем WSS. Он добавляет к UDP-адресам релеев звонка те же адреса по TCP и по TLS и пускает их в ход, только если UDP не заработал. TLS там нужен лишь для того, чтобы трафик выглядел как HTTPS. Подпись честно предупреждает, что качество связи при этом заметно хуже. К WSS этот пункт отношения не имеет, хотя стоит на том же экране.

«Не идут через WSS» не значит «не работают»

Звонок просто идёт мимо транспорта, напрямую. Заработает он или нет, зависит от того, режет ли провайдер сам этот UDP-трафик, а не от настроек WSS.

Правильный инструмент для звонков — обход на уровне пакетов. zapret через WinDivert перехватывает и UDP: типовые профили покрывают UDP 443 и диапазон 50000–50100, то есть ровно тот трафик, из которого состоит звонок (подробнее — в заметке про WinDivert). Второй вариант — VPN. В ZapretGUI есть экспериментальный проброс UDP через внешний SOCKS5: сервер должен уметь UDP ASSOCIATE, а фрагментированные датаграммы, характерные для видеозвонков, модуль отбрасывает.

WSS, прокси и VPN: что гасит что

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

СитуацияAndroidDesktop
Выбран SOCKS5 или MTProxyWSS приостановлен, работает проксиSOCKS5 — WSS поверх него; MTProxy — обычный TCP
Выбран локальный SOCKS5 на 127.0.0.1 или порту 1353WSS приостановленWSS выключен
Выбранный прокси не подключается 15 секундвременно WSS, прокси проверяется каждые 30 секунд — 5 минутто же
Активен VPNWSS приостановленне учитывается

Две ловушки здесь стоит знать. До 1 октября 2026 года Desktop сам добавлял локальный SOCKS5 127.0.0.1:1353 — адрес моста из ZapretGUI — и выбирал его на новой установке. У тех, у кого мост не был запущен, клиент бесконечно висел в подключении. В выпуске zsg-7.3.1 эту запись удаляют один раз, а новая установка сразу ходит через WSS. Вторая ловушка — в Android: при обновлении флаг миграции один раз принудительно включил WSS и тем, кто раньше выключил его сам. Если после обновления клиент вдруг пошёл через WSS, причина в этом.

Подписи, которым нельзя верить

Транспорт менялся быстрее интерфейса, и часть подписей описывает то, чего в коде давно нет.

  • «Route via WSS (web, DC2/DC4 only)» — подпись переключателя в Desktop. С 8 августа 2026 года клиент ходит через релеи всех пяти датацентров, а DC203 — через туннель. Та же устаревшая формулировка — в README Desktop-клиента и в подсказке поля своего релея «empty = official DC2/DC4».
  • «No certificate check is done — use only a relay you trust» — предупреждение у полей своего релея в Desktop. Сертификат на деле проверяется по указанному имени.
  • «WSS unavailable for this DC. Add a proxy.» — уведомление Desktop. Оно появляется, только когда для датацентра нет ни одной ступени лестницы; для DC1–DC5 и DC203 маршрут есть всегда, так что увидеть его почти невозможно.
  • «Telegram WSS транспорт: Официальный» — подзаголовок экрана прокси в Android. Он отражает положение переключателя, а не то, что соединение действительно идёт через WSS.
  • ZapretGUI до 16 октября 2026 года помечал релеи DC1, DC3 и DC5 как неподтверждённые, а диагностика проверяла их на чужом адресе и сообщала «релея нет», хотя все они работают (замеры — в парной заметке). Исправлено коммитом cb72426c, в выпуске после 21.1.7.176.
  • FAQ tg-ws-proxy (issue #389) написан под версию 1.7.2. Там сказано, что FakeTLS-секреты не поддерживаются, а в текущей версии они включаются через --fake-tls-domain.

Мелочи у мостов

У мостов, которые запускаются рядом с клиентом, есть свои бытовые отказы.

Мультиплексирование медиа. С версии 1.11.0 tg-ws-proxy по умолчанию собирает медиа через домены Cloudflare в одно соединение HTTP/2. 9 октября 2026 года у пользователя на macOS загрузка зависала примерно на 1,7 МБ, и помогло выключить мультиплексирование (флаг --no-h2).

Антивирус удаляет программу. Сборки tg-ws-proxy упакованы PyInstaller, и Windows Defender регулярно принимает их за вредоносные. FAQ проекта советует добавить файл в исключения и проверить его хеш на VirusTotal: у настоящей сборки детектов должно быть не больше двух-трёх. Отдельно предупреждают о поддельных копиях проекта — история, знакомая по поддельным репозиториям zapret.

Занятый порт. Мост не стартует, если порт занят другим процессом или запрещён системой: в Windows это ошибки 10048 и 10013. ZapretGUI три секунды повторяет попытку, потому что после перезапуска старый сокет освобождается не сразу. В FAQ tg-ws-proxy для 10013 предлагают net stop hns && net start hns от администратора.

IPv6. tg-ws-proxy предупреждает, что Telegram может пытаться подключаться по IPv6, который мост не поддерживает, и советует выключить IPv6 в настройках Telegram.

Файл hosts. Модуль ZapretGUI умеет прописать в hosts Windows 35 доменов Telegram. С 29 сентября 2026 года он делает это только по кнопке «Прописать» и убирает по кнопке «Убрать». Если hosts правит ещё какая-то программа, записи могут конфликтовать.

Как собрать диагностику

Когда что-то не работает, клиенты ZaStoGram сами записывают достаточно, чтобы разобраться. Нужно знать, куда смотреть.

Где смотретьЧто там видно
Android: окно ошибки входастрока wss=on, wss=suspended или wss=off; suspended значит, что WSS включён, но его приостановил прокси или VPN; proxy=…(wss_fallback) — клиент ушёл с недоступного прокси на WSS
Android: «Техническая информация» в меню сообщенияwss_configured, wss_active, ожидаемый адрес релея для датацентра сообщения и живые соединения
Android: сетевой журнал <дата>_net.txtпопадает в архив по кнопке «Отправить логи», если журналы включены в настройках отладки
Android: строки wss_routesuppressed — маршрут на паузе (reason=failures, quota, stalls), restored — пауза снята, all_suppressed — на паузе всё, клиент идёт через домены
Android: строки wss_disconnectполе route= показывает ступень (ip, dns, cdn, tunnel), phase=wss_tcp_connect — не поднялся TCP, phase=wss_tls_handshake — TCP есть, TLS нет, wss_appdata_no_response_timeout — «чёрная дыра»
Desktop: «Настройки» → «Продвинутые настройки» → «Тип соединения»Default (WSS used, ping: 87 ms) — транспорт работает
Desktop: диагностика в меню сообщенияwss.route, паузы маршрута и число неудач подряд, предпочтённый адрес релея; есть кнопка «Копировать»
Desktop: DebugLogs/mtproxy*.txtстрока wss_session на каждый сокет: transport=WSS, WSSFront или WSSTunnel, tcp=0 — TCP не поднялся, upgraded=0 — нет апгрейда

Если почти все строки показывают туннель (route=tunnel или WSSTunnel), медленные загрузки объясняются туннелем, а не вашей сетью в целом. Если на паузе стоит релей одного датацентра, а остальные работают, это та самая частичная блокировка из первого раздела.

Как это чинили

Почти каждый симптом из этой заметки сначала встретился у пользователей ZaStoGram, а потом получил исправление в коде. Старые сборки сохраняют старые ошибки, поэтому первый совет при любой проблеме — обновить клиент.

Особенно показательна последняя неделя сентября 2026 года. Туннель через Cloudflare добавили 24 сентября как запасной путь для закрытых релеев, и за два дня маршрут медиа менялся четыре раза: туннель не догружал смайлики, прямое подключение к медиа DC1 на мобильной сети не проходило ни разу из 27 попыток, а каждое следующее правило отменяло предыдущее. Устойчивым оказалось правило судить о туннеле по объёму полученных данных, а не по первому ответу. 27 сентября перед туннелем встали домены за Cloudflare, и прямое подключение к датацентру ушло из лестницы совсем.

Источники

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: исходник этой заметки · скачать весь репозиторий одним zip-архивом.

Вид графа

Обратные ссылки