> [!mirror] Резервное зеркало > Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/mtproxy/telegram-wss-limits](https://wiki.zapret.moe/mtproxy/telegram-wss-limits) # 🧯 Ограничения WSS для Telegram: что не работает и почему ![[telegram-wss-limits-header.jpg]] > [!info] О чём заметка > Симптомы, с которыми сталкиваются пользователи WSS-транспорта в ZaStoGram и мостов вроде tg-ws-proxy, их причины и способы их проверить: не грузятся стикеры или медиа из части датацентров, загрузка идёт рывками, вход не проходит, звонки не соединяются. Как сам транспорт устроен — релеи, правила кадров, лестница запасных путей через Cloudflare, — разобрано в парной заметке [[mtproxy/telegram-wss-transport|WSS для Telegram: MTProto внутри WebSocket]]; здесь из неё берутся только выводы. > [!warning] Откуда взяты данные > Статья переписана 16 октября 2026 года. Основа — исходный код и сообщения коммитов ZaStoGram для Android (версия 1.1.30 от 15 октября 2026 года) и Desktop (выпуск `zsg-7.3.1` от 16 октября 2026 года), модуля `telegram_proxy` в ZapretGUI и [tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy). Симптомы взяты из того, как авторы этих проектов описали жалобы и журналы тестировщиков, и из обращений в [трекер tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy/issues). Числа вроде «соединение замирает на 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-транспорта. Их закрывают пакетным обходом [[Zapret2/Zapret2|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 ищет путь к датацентру, подробно описан в [[mtproxy/telegram-wss-transport|парной заметке]]. Коротко: сначала веб-релей Telegram `kwsN.web.telegram.org`, затем 20 доменов за Cloudflare, затем туннель через три воркера Cloudflare, а если всё на паузе — снова домены. Каждая ступень медленнее предыдущей, и большинство симптомов ниже — это признаки того, что соединение спустилось на одну из нижних ступеней. Почему сервер Telegram при этом так часто молчит, а не сообщает об ошибке, разобрано в разделе [[mtproxy/telegram-wss-transport#Что мы теперь знаем об архитектуре Telegram|об архитектуре Telegram]]. ## Не грузятся стикеры, эмодзи или фото из части датацентров Это самый частый и самый обманчивый случай. Переписка идёт, скорость нормальная, ошибок нет, но часть содержимого не загружается или грузится минутами. Обычно это выглядит как «фото открываются, а эмодзи, реакции и стикеры нет». Причина в том, что содержимое Telegram разложено по пяти датацентрам, а у каждого датацентра свой веб-релей и свой адрес входа. Провайдер может закрыть один из них и оставить остальные. В замере 9 августа 2026 года в одной российской сети релей DC2 был открыт, а релей DC1 не отвечал ни по IPv4, ни по IPv6, и прямой адрес DC1 тоже был закрыт. Фото на DC2 грузились, эмодзи и реакции на DC1 — нет. 15 октября 2026 года пользователь tg-ws-proxy [написал, что его провайдер закрыл по IP и адрес `149.154.167.220`](https://github.com/Flowseal/tg-ws-proxy/issues/1450), то есть релей DC2 и DC4. Проверять доступность нужно по TCP, а не `ping`. Фильтр провайдера режет соединения по порту и оставляет пинг живым: в августовском замере все четыре адреса отвечали на `ping`, и только один принимал TCP на порт 443. В Windows проверка выглядит так: ```powershell 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](https://github.com/Flowseal/tg-ws-proxy/blob/main/docs/RU/CfProxy.md) советует владельцам аккаунтов без 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 смайликов. Клиенты подстроились под этот порог. ![[telegram-wss-tunnel-parts.png]] Через туннель файл качается кусками по 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 [перевели его на них](https://git.zapret.moe/zastogram/ZaStoGram_desktop/commit/09fefd7e6eb2f5acb3e908fe5b9ef6590d6366f4): теперь лимит воркеров замедляет эти файлы, но не отключает. Отсюда частое заблуждение «у знакомого с Premium всё грузится, значит дело в подписке»: подписка здесь меняет только датацентр, из которого приходит файл. ## Лимиты Cloudflare: 429, 503 и 403 Обе запасные ступени живут на чужой инфраструктуре и упираются в её ограничения. **Воркеры.** [У бесплатного тарифа Cloudflare Workers лимит — 100 000 запросов в сутки, со сбросом в полночь UTC](https://developers.cloudflare.com/workers/platform/limits/). После исчерпания воркер отвечает кодом `429` с ошибкой 1027. Вечером 8 октября 2026 года единственный тогда воркер ZaStoGram исчерпал лимит, и медиа DC203 перестали грузиться у всех пользователей. По статистике Cloudflare, на которую ссылаются авторы, один воркер исчерпывал лимит каждый день к 10–12 часам UTC. С 9 октября воркеров три, на трёх разных учётных записях Cloudflare. Каждая установка начинает со случайного воркера, а ответивший `429` сразу уходит на паузу, не дожидаясь трёх отказов. В tg-ws-proxy такая же пауза для воркера, ответившего `429`, в коде есть, но [отключена ранним выходом из функции с пометкой «TODO: проверить код статуса после исчерпания дневного лимита»](https://github.com/Flowseal/tg-ws-proxy/blob/main/proxy/pool.py): исчерпавший лимит воркер продолжает получать запросы. **Домены за Cloudflare.** Здесь отказ выглядит как `503` на запрос апгрейда. По тесту ZaStoGram от 27 сентября 2026 года соединение с таким доменом либо обслуживается сразу, либо отвечает `503` на каждую попытку; в комментариях кода доля отказов оценивается в 40–50%. Клиент повторяет апгрейд до восьми раз на том же TLS-соединении и ставит домены на паузу только после шести неудач подряд. В трекере tg-ws-proxy с этим симптомом пришло [обращение от 14 октября 2026 года](https://github.com/Flowseal/tg-ws-proxy/issues/1450): часть картинок и голосовых грузится сразу, часть — минутами, в журнале `503`. Автор проекта посоветовал настроить свой воркер по [инструкции](https://github.com/Flowseal/tg-ws-proxy/blob/main/docs/RU/CfWorker.md), и двум пользователям это помогло. **Код 403 от воркера.** В [обращении от 9 октября 2026 года](https://github.com/Flowseal/tg-ws-proxy/issues/1423) пользователь tg-ws-proxy не мог отправить ни одной картинки. Автор ответил, что воркер отвечает `403`: он либо заблокирован, либо упёрся в лимит 100 000 запросов, — и посоветовал выключить воркер. Это помогло. **Сам Cloudflare может быть закрыт.** [Документация tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy/blob/main/docs/RU/CfProxy.md) предупреждает, что подсеть 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-пакета в одном кадре. Релей в обоих случаях молчит, не сообщая об ошибке; правила и замеры — в [[mtproxy/telegram-wss-transport|парной заметке]]. Вторая — «чёрная дыра»: в некоторых сетях релей принимает TLS и апгрейд, но данные до Telegram не доходят. До 27 августа 2026 года успешный апгрейд обнулял счётчик неудач ZaStoGram, и клиент бесконечно возвращался к такому релею. Пользователь видел это как «Telegram не ответил на запрос кода» при входе. Теперь тишина после отправки считается отказом: 5,5 секунды для обычного соединения и 20 секунд для медиа. ZapretGUI после переписывания своего ядра 28 сентября 2026 года использует те же пороги. Третья причина — сам транспорт исправен, но клиент ждёт чего-то другого. В Desktop первый запуск длился 25–45 секунд, потому что поток соединения синхронно ждал проверку отзыва сертификата доменов за Cloudflare, а список отзыва ещё не был в кэше; исправлено 2 октября 2026 года. Там же после смены маршрута файлы не грузились около 9 секунд: ключ для медиа, созданный на одной стороне маршрута, на другой был неизвестен. > [!tip] Как отличить блокировку от ошибки клиента > Если до релея не доходит даже TCP, режет сеть. Если TCP и TLS проходят, апгрейд отвечает `101`, а дальше тишина — это либо «чёрная дыра», либо ошибка нарезки кадров. Обновите клиент: оба случая исправлены в ZaStoGram с конца августа 2026 года, и клиент теперь сам уходит с такого релея на запасную ступень. ## Звонки Голосовые и видеозвонки через WSS не идут ни в одной реализации. WebSocket работает поверх TCP, а звонки Telegram используют UDP и отдельные релеи, адреса которых выдаёт сервер в момент звонка. Транспорт, который везёт MTProto-сессию, звонков просто не видит. То же ограничение действует и для классического [[Zapret/mtproto/00-overview|MTProxy]]; в [FAQ tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy/issues/389) оно сформулировано как архитектурное ограничение MTProto-прокси. ![[telegram-wss-calls-bypass.png]] В клиентах ZaStoGram это видно прямо в коде. Android создаёт звонок без прокси, какой бы прокси ни был выбран. В Desktop проверка «поддерживает ли прокси звонки» всегда отвечает «нет», поэтому галочка «Use proxy for calls» не появляется вовсе. В Android есть отдельный экспериментальный пункт «Звонки через TCP/TLS» в настройках прокси, под переключателем WSS. Он добавляет к UDP-адресам релеев звонка те же адреса по TCP и по TLS и пускает их в ход, только если UDP не заработал. TLS там нужен лишь для того, чтобы трафик выглядел как HTTPS. Подпись честно предупреждает, что качество связи при этом заметно хуже. К WSS этот пункт отношения не имеет, хотя стоит на том же экране. > [!important] «Не идут через WSS» не значит «не работают» > Звонок просто идёт мимо транспорта, напрямую. Заработает он или нет, зависит от того, режет ли провайдер сам этот UDP-трафик, а не от настроек WSS. Правильный инструмент для звонков — обход на уровне пакетов. [[Zapret2/Zapret2|zapret]] через WinDivert перехватывает и UDP: типовые профили покрывают UDP 443 и диапазон 50000–50100, то есть ровно тот трафик, из которого состоит звонок (подробнее — в [[Zapret2/windivert|заметке про WinDivert]]). Второй вариант — VPN. В ZapretGUI есть экспериментальный проброс UDP через внешний SOCKS5: сервер должен уметь `UDP ASSOCIATE`, а фрагментированные датаграммы, характерные для видеозвонков, модуль отбрасывает. ## WSS, прокси и VPN: что гасит что Сочетать WSS с другими способами обхода можно не всегда, и правила у двух клиентов разные. Полная логика описана в [[mtproxy/telegram-wss-transport|парной заметке]]; здесь — то, что ведёт к жалобам. | Ситуация | Android | Desktop | |---|---|---| | Выбран SOCKS5 или MTProxy | WSS приостановлен, работает прокси | SOCKS5 — WSS поверх него; MTProxy — обычный TCP | | Выбран локальный SOCKS5 на `127.0.0.1` или порту 1353 | WSS приостановлен | WSS выключен | | Выбранный прокси не подключается 15 секунд | временно WSS, прокси проверяется каждые 30 секунд — 5 минут | то же | | Активен VPN | WSS приостановлен | не учитывается | Две ловушки здесь стоит знать. До 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 как неподтверждённые, а диагностика проверяла их на чужом адресе и сообщала «релея нет», хотя все они работают (замеры — в [[mtproxy/telegram-wss-transport|парной заметке]]). Исправлено [коммитом cb72426c](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/commit/cb72426c8de4d15da363968845ea8725fad7656e), в выпуске после 21.1.7.176. - **FAQ tg-ws-proxy** ([issue #389](https://github.com/Flowseal/tg-ws-proxy/issues/389)) написан под версию 1.7.2. Там сказано, что FakeTLS-секреты не поддерживаются, а в текущей версии они включаются через `--fake-tls-domain`. ## Мелочи у мостов У мостов, которые запускаются рядом с клиентом, есть свои бытовые отказы. **Мультиплексирование медиа.** С версии 1.11.0 tg-ws-proxy по умолчанию собирает медиа через домены Cloudflare в одно соединение HTTP/2. [9 октября 2026 года у пользователя на macOS](https://github.com/Flowseal/tg-ws-proxy/issues/1424) загрузка зависала примерно на 1,7 МБ, и помогло выключить мультиплексирование (флаг `--no-h2`). **Антивирус удаляет программу.** Сборки tg-ws-proxy упакованы PyInstaller, и Windows Defender регулярно принимает их за вредоносные. [FAQ проекта](https://github.com/Flowseal/tg-ws-proxy/issues/389) советует добавить файл в исключения и проверить его хеш на VirusTotal: у настоящей сборки детектов должно быть не больше двух-трёх. Отдельно предупреждают о поддельных копиях проекта — история, знакомая по [[virus/flowseal-fake-youtube-salatstealer-july-2026|поддельным репозиториям 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_route` | `suppressed` — маршрут на паузе (`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, а потом получил исправление в коде. Старые сборки сохраняют старые ошибки, поэтому первый совет при любой проблеме — обновить клиент. ![[telegram-wss-fixes-timeline.png]] Особенно показательна последняя неделя сентября 2026 года. Туннель через Cloudflare добавили 24 сентября как запасной путь для закрытых релеев, и за два дня маршрут медиа менялся четыре раза: туннель не догружал смайлики, прямое подключение к медиа DC1 на мобильной сети не проходило ни разу из 27 попыток, а каждое следующее правило отменяло предыдущее. Устойчивым оказалось правило судить о туннеле по объёму полученных данных, а не по первому ответу. 27 сентября перед туннелем встали домены за Cloudflare, и прямое подключение к датацентру ушло из лестницы совсем. ## Источники - [tg-ws-proxy (Flowseal): исходники и README](https://github.com/Flowseal/tg-ws-proxy) - [tg-ws-proxy: трекер обращений](https://github.com/Flowseal/tg-ws-proxy/issues) - [tg-ws-proxy: FAQ, issue #389](https://github.com/Flowseal/tg-ws-proxy/issues/389) - [tg-ws-proxy, issue #1423 от 9 октября 2026 года — не отправляются медиа, воркер отвечает 403](https://github.com/Flowseal/tg-ws-proxy/issues/1423) - [tg-ws-proxy, issue #1424 от 9 октября 2026 года — загрузка зависает на 1,7 МБ, помогло выключить мультиплексирование](https://github.com/Flowseal/tg-ws-proxy/issues/1424) - [tg-ws-proxy, issue #1450 от 14 октября 2026 года — медиа грузятся минутами, 503 от Cloudflare; провайдер закрыл 149.154.167.220](https://github.com/Flowseal/tg-ws-proxy/issues/1450) - [tg-ws-proxy: код пула воркеров с отключённой паузой при 429](https://github.com/Flowseal/tg-ws-proxy/blob/main/proxy/pool.py) - [tg-ws-proxy: инструкция по своему домену за Cloudflare](https://github.com/Flowseal/tg-ws-proxy/blob/main/docs/RU/CfProxy.md) - [tg-ws-proxy: инструкция по своему воркеру Cloudflare](https://github.com/Flowseal/tg-ws-proxy/blob/main/docs/RU/CfWorker.md) - [ZapretGUI, коммит cb72426c от 16 октября 2026 года — релеи DC1–DC5 и два адреса у DC2/DC4](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/commit/cb72426c8de4d15da363968845ea8725fad7656e) - [ZaStoGram Desktop, коммит 09fefd7e6e от 16 октября 2026 года — DC203 через домены за Cloudflare](https://git.zapret.moe/zastogram/ZaStoGram_desktop/commit/09fefd7e6eb2f5acb3e908fe5b9ef6590d6366f4) - [Cloudflare Workers: лимиты бесплатного тарифа, 100 000 запросов в сутки и ошибка 1027](https://developers.cloudflare.com/workers/platform/limits/) ## 📚 См. также - [[mtproxy/telegram-wss-transport|WSS для Telegram: MTProto внутри WebSocket]] — парная заметка: релеи, правила кадров, лестница запасных путей, кто видит трафик - [[mtproxy/mtproxy|Раздел MTProxy]] — обзор всех заметок про MTProxy, WSS и WEB-прокси - [[premium/android|ZaStoGram для Android]] — установка клиента и где в нём переключатель WSS - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — классический MTProxy и его ограничения - [[mtproxy/faketls-relay-diagnosis|Релей или клиент: диагностика MTProxy]] — как понять, кто виноват, когда не подключается - [[mtproxy/ja4-sni-client-side|Кто может менять JA4 и SNI]] — второй класс блокировок, по почерку соединения - [[Zapret2/Zapret2|zapret]] — пакетный обход, который закрывает звонки - [[Zapret2/windivert|WinDivert и профили портов]] — какие UDP-порты нужны звонкам - 🔗 [zastogram/ZaStoGram](https://git.zapret.moe/zastogram/ZaStoGram) — исходники Android-клиента, сборки в [релизах](https://git.zapret.moe/zastogram/ZaStoGram/releases) - 🔗 [zastogram/ZaStoGram_desktop](https://git.zapret.moe/zastogram/ZaStoGram_desktop) — исходники Desktop-клиента --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/mtproxy/telegram-wss-limits.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).