| Автор |
Сообщение |
Новости ®
Вольный ветер
Стаж: 19 лет 10 мес.
Сообщений: 6670
Ratio: 25.216
Поблагодарили: 13443
100%
|
В августе 2026 года в Telegram появился четвёртый тип прокси — WEB-прокси (tproxy, веб-прокси Телеграм). Он отличается от всего, что было раньше: приложение перестаёт выходить в сеть само и просит сделать это встроенный в него браузер, обращаясь к самому обычному сайту. Здесь — что это такое простыми словами, зачем понадобилось, чем отличается от привычного MTProxy и можно ли этим пользоваться по состоянию на 22 августа 2026 года.
Разбор сделан по исходному коду серверной части tproxy-server и клиента Telegram Desktop по состоянию на 22 августа 2026 года. Автор сам называет проект доказательством работоспособности (proof-of-concept) — то есть демонстрацией, что идея в принципе работает, а не готовым продуктом. Официальной документации Telegram по этому протоколу нет, гарантий совместимости между версиями никто не давал. Всё описанное ниже может измениться.
TL;DR
- WEB-прокси — это способ доставки, а не новое шифрование. Внутри всё тот же MTProxy, который Telegram использует много лет. Меняется только то, как байты попадают на сервер.
- Приложение больше не открывает сетевые соединения само. Оно просит встроенный браузерный движок (тот же, на котором работают мини-приложения Telegram) сходить на обычный сайт по вашему домену — и трафик едет внутри этих веб-запросов.
- На сервере стоит настоящий сайт. Кто угодно может открыть ваш домен в браузере и увидеть нормальные страницы. По содержанию ответов сервера понять, что здесь же живёт прокси, нельзя.
- Пользователю нужны два значения — имя домена и обычный 32-символьный секрет MTProxy. Никаких файлов конфигурации и ключей.
- Работает пока только в собранном вручную клиенте. Код Telegram Desktop написан 9 августа 2026 года и опубликован 18 августа, но лежит в ветке разработки: в выпущенных версиях (последняя — 7.0.9 от 6 августа) его ещё нет. Android — экспериментальный прототип, iOS — только планы.
- Звонки через него не пойдут — голос и видео ходят по другому сетевому протоколу, который внутрь веб-запросов не укладывается.
Что такое прокси для Telegram и почему их несколько типов
Чтобы понять новизну, нужно сначала вспомнить, что уже было. Telegram умеет работать через посредника — сервер, который принимает трафик от приложения и передаёт его дальше в сторону настоящих серверов мессенджера. Это и есть прокси. До августа 2026 года приложение знало три типа таких посредников: SOCKS5 и HTTP — общие стандарты, придуманные вообще не для Telegram, — и MTProxy, собственную разработку мессенджера.
MTProxy отличается от первых двух тем, что понимает внутренний протокол Telegram, который называется MTProto, и умеет прятать его от посторонних глаз. У MTProxy есть режим маскировки FakeTLS (ФейкТЛС, транспорт ee): соединение притворяется обычным защищённым визитом на какой-нибудь популярный сайт. Подробнее об устройстве самого MTProxy — в заметке MTProxy и mtproto.zig: что это и как пережить ТСПУ.
Проблема в том, что притворство здесь остаётся притворством. Соединение с MTProxy — это всё равно отдельное подключение, которое приложение открывает своими руками, своим сетевым кодом. А в России такие подключения разбирает ТСПУ (технические средства противодействия угрозам) — оборудование фильтрации, установленное прямо у операторов связи. Оно учится распознавать подключения по мелким деталям: по тому, как именно клиент начинает разговор, какие параметры шифрования предлагает, как выглядит первый пакет. Об этой стороне борьбы есть отдельная заметка SNI и почему обход — клиентский.
WEB-прокси решает задачу иначе. Вместо того чтобы всё лучше маскировать собственные соединения, приложение перестаёт их открывать вообще.
Почему WEB-прокси появился именно в 2026 году
1 апреля 2026 года в России началась волна отказов MTProxy: в журналах прокси массово появились ошибки «Telegram handshake timeout» и «obfuscated handshake is failed» — они зафиксированы в баг-трекерах серверных реализаций. По сообщениям пользователей, отказ зависел от оператора и способа подключения: у одних не работало вовсе, у других на том же операторе работало. В тот же день выросло число жалоб на Telegram на сервисах мониторинга сбоев: по подсчётам в разборе на Habr от 2 апреля — около четырёх тысяч обращений на Downdetector и более трёх тысяч на «Сбой.РФ». Эти числа приводятся по одному источнику и относятся к мессенджеру в целом, а не к прокси отдельно.
В конце мая 2026 года прошла вторая, более жёсткая волна. Издание te-st.org провело полевой тест с 27 по 31 мая в четырёх регионах и шести сетях: из 27 проверенных конфигураций рабочими оказались три, причём все — в сетях региональных провайдеров, а у двух федеральных операторов ни один из восьми проверенных прокси соединения не установил. Перенос на нестандартные порты не помогал — их блокировали наравне с обычным. Авторы теста специально оговариваются, что выборка невелика и это «срез, а не замер по стране».
Самая технически достоверная версия причины апрельской волны при этом не про всемогущий искусственный интеллект, а про обыкновенную небрежность реализации. Маскировка под защищённое соединение в коде Telegram использовала устаревший идентификатор одного из расширений протокола вместо действующего и объявляла криптографический ключ длиной 32 байта, генерируя при этом 20. Такое приветственное сообщение не мог бы отправить ни один настоящий браузер, и ловила его простейшая проверка по образцу. То есть распознавать научились не саму идею маскировки, а конкретную ошибку в конкретном коде.
Проще говоря: Telegram притворялся браузером, но в двух местах представился неправильно — назвал устаревший номер одной из служебных пометок и сам себе соврал про длину ключа. Достаточно было сверить эти два места с тем, как их заполняет настоящий браузер, и притворство становилось видно без всякого анализа поведения.
Ошибку закрыли быстро: в Telegram Desktop — 3 апреля, в мобильных клиентах — 7–8 апреля. Но майская волна пришла уже поверх исправленных клиентов, и te-st.org связывает её с переходом систем фильтрации к статистическому анализу трафика — а это как раз то, что подделкой отдельных байтов не лечится. Официальный репозиторий MTProxy при этом почти всё это время стоял без движения: между ноябрём 2025-го и началом августа 2026-го в него не внесли ни одной правки — как раз в те месяцы, когда блокировки и работали.
Отсюда и мысль вообще не эмулировать браузер, а использовать настоящий. У WEB-прокси отпечаток соединения не подделывается вручную: его формирует реальный браузерный движок, который обновляется вместе с системой. Догонять свежие версии браузеров в основном не приходится — правда, ровно настолько, насколько свеж сам движок: на старых системах встроенный браузер тоже отстаёт.
Отдельно стоит понимать, что именно на практике блокирует такие инструменты. Надёжно задокументированы измерительными проектами вещи прозаичные: белые списки доменов (с сентября 2025 года действует «реестр социально значимых сервисов»), блокировка по имени домена в запросе, блокировка по адресу и по его репутации. Про более тонкие механизмы известно почти исключительно из разборов сообщества: фильтр сам стучится на подозрительный сервер и смотрит, как тот отвечает; считает, сколько байт уже перекачано, и режет соединение при превышении порога; или просто «замораживает» соединение после первых полутора-двух десятков килобайт, не разбираясь в протоколе. Автор самого подробного такого разбора сам называет свою схему реконструкцией по единственному источнику, так что принимать эти пороги за установленные константы не стоит.
А вот распространённое «блокировки теперь делает искусственный интеллект» пока не подтверждается. Движение в эту сторону реальное и не отдалённое: в январе 2026 года Роскомнадзор законтрактовал механизм фильтрации трафика на машинном обучении с внедрением в том же году, а целевой показатель «эффективности» блокировок средств обхода в 92% поставлен на конец 2030 года (разбор этой дорожной карты — в заметке Планы РКН по блокировке VPN до 2030 года). Но публичных свидетельств того, что прокси в апреле и мае ловили именно поведенческие модели, нет: есть разбор конкретной ошибки в байтах приветственного сообщения и наблюдения о переходе к статистическому анализу размеров и объёмов.
Главная идея: пусть в сеть ходит браузер
Внутри Telegram Desktop, как и внутри мобильных приложений, есть встроенный браузерный движок. Он называется WebView — это полноценный браузер без собственного окна, встроенный в чужую программу. На Windows это WebView2 на движке Chromium, на Android — Android System WebView, на устройствах Apple — WKWebView. Именно он открывает мини-приложения внутри Telegram, страницы оплаты и встроенные веб-вставки. Для прокси при этом заводится отдельный, изолированный экземпляр движка со своим хранилищем — с мини-приложениями он ничего не делит.
Идея WEB-прокси в том, чтобы отдать этому браузеру всю сетевую работу. Выглядит это так: приложение открывает в скрытом WebView страницу вашего сайта, и дальше внутри этой страницы работает небольшой скрипт, который обменивается с сервером обычными веб-запросами. В этих запросах и едет трафик Telegram.
Проще говоря: раньше Telegram сам звонил на прокси-сервер, и этот звонок можно было опознать. Теперь Telegram просит браузер открыть обычный сайт, а всё нужное передаёт внутри посещения этого сайта. Наблюдателю в сети видно ровно одно — кто-то зашёл на сайт и активно им пользуется.
На схеме видно, что цепочка получается длиннее привычной. Приложение отдаёт свои соединения встроенному браузеру, тот обычными веб-запросами доносит их до вашего домена, программа-посредник на сервере раскладывает всё обратно по отдельным соединениям и передаёт обычному MTProxy, который стоит тут же и работает без изменений.
Выигрыш здесь не только в маскировке. Браузерный движок умеет всё то, чему годами учили браузеры: правильно проходить через корпоративные прокси, работать с нестандартными сертификатами, использовать современные версии протокола HTTP. В сетях, где наружу выпускают только веб-трафик, самодельное соединение мессенджера не пройдёт, а браузерный запрос пройдёт.
Что при этом происходит с шифрованием
Новый транспорт — то есть способ доставки байт до сервера — не добавляет и не убавляет шифрования переписки. Приложение сначала обрабатывает данные ровно так же, как для обычного MTProxy, и только потом отдаёт получившиеся байты браузеру. На сервере эти байты передаются настоящему MTProxy, который стоит рядом и работает без единого изменения.
Программа-посредник, которая всё это перекладывает, называется реле (relay, релей). Ключевое её свойство: она не может прочитать то, что перевозит. Для неё данные — просто непрозрачный набор байт. Более того, адрес получателя жёстко записан в настройках реле и указывает на локальный MTProxy, а клиент выбрать его не может. То есть даже злонамеренный клиент не заставит сервер сходить куда-то ещё, и открытым прокси для чужого трафика он не станет. Речь именно про клиента: тот, кто получил на сервере права администратора, конфигурацию, разумеется, перепишет.
Отдельно защищён и сам секрет. Пользователь вводит его в приложении, но в браузер этот секрет не передаётся: из него вычисляется производное значение — постоянный пропуск, привязанный к конкретной паре «домен плюс секрет». По этому пропуску сервер выдаёт уже одноразовое: страницу-мост и короткоживущий токен на одну сессию. Как именно это устроено — разобрано в заметке Как устроен WEB-прокси изнутри.
Со стороны пользователя: два поля и всё
Проще, чем всё, к чему привыкли пользователи VPN. Нужны два поля:
- Hostname: proxy.example.com
- Secret: 000102030405060708090a0b0c0d0e0f
Имя хоста — просто домен, без https://, без порта и без косой черты в конце: тип прокси WEB жёстко подразумевает защищённое соединение на стандартном порту 443. Секрет — те же 32 шестнадцатеричных символа, что и у обычного MTProxy.
Есть и ссылка для передачи одним сообщением:
| Код: выделить все https://t.me/webproxy?server=proxy.example.com&secret=000102030405060708090a0b0c0d0e0f
|
Правда, на 22 августа 2026 года публичный сайт t.me этот адрес ещё не обслуживает — в документации проекта это сказано прямо. Пока ссылку приходится открывать напрямую в клиенте (в форме tg://webproxy?server=…&secret=…) либо вводить оба поля руками.
В самом приложении это выглядит как четвёртый переключатель в списке типов прокси, рядом с MTPROTO, SOCKS5 и HTTP. При его выборе поля адреса и порта исчезают — остаётся одно поле имени хоста и поле секрета, а порт всегда 443. Три особенности стоит знать заранее: проверка доступности для таких прокси отключена (строка всегда показывает «не проверено»), в автоматической ротации прокси такие записи не участвуют, а секреты с префиксом ee клиент прямо помечает как неподдерживаемые.
Отдельно предусмотрен запасной путь на случай, когда встроенный браузер недоступен. Клиент предлагает открыть страницу прокси в обычном браузере. Для этого Telegram запускает крошечный веб-сервер прямо на вашем компьютере, открывает его страницу по адресу 127.0.0.1 (это адрес «сам себя», наружу он не виден), и дальше эта вкладка работает переносчиком трафика — её придётся держать открытой всё время, пока нужен Telegram. Встроенный вариант при этом продолжает пытаться подключиться в фоне и, как только у него получится, вкладка становится не нужна.
Требования к встроенному браузеру различаются по системам: на Windows используется компонент Edge WebView2 (в Windows 10 и 11 он обычно уже установлен), на macOS — штатный WKWebView, на Linux нужна библиотека WebKitGTK. Если движок недоступен или скрытое окно не поднимается, клиент и предлагает тот самый запасной путь через системный браузер.
Чем это отличается от VPN и от обычного прокси
Первое и главное: это не VPN. Через WEB-прокси идёт только трафик Telegram и ничего больше. Браузер, почта, другие приложения им не пользуются. Если задача — открыть заблокированный сайт, нужен другой инструмент; здесь речь исключительно о том, чтобы работал мессенджер.
Второе: это не универсальный прокси. Настроить его в стороннем клиенте или в системе нельзя — нужна поддержка именно в приложении Telegram, потому что вся хитрость происходит внутри него.
Третье: голос и видео через такой транспорт не идут. Звонки в Telegram идут по протоколу UDP — это способ отправлять пакеты без установленного соединения и без гарантии доставки, зато быстро; для разговора так лучше, но внутрь веб-запросов такое не заворачивается. В списке того, что сознательно не поддерживается в первой версии, звонки названы прямо. Справедливости ради, обычный MTProxy их тоже не переносит: при любом прокси Telegram Desktop ведёт звонки мимо него, напрямую. То же касается веб-версии Telegram — она с этим протоколом не работает.
Сравнение с соседними решениями удобнее в таблице
Что нужно, чтобы поднять такой прокси
Кратко: отдельный сервер, свой домен и настоящий сайт на нём. Развёрнутая инструкция — в заметке Установка tproxy-server, здесь только суть.
Домен обязателен, и заменить его голым IP-адресом нельзя: пропуск, по которому клиент опознаётся, вычисляется в том числе из имени домена. Сертификат для защищённого соединения выпускается автоматически, для этого нужен работающий доступ снаружи к портам 80 и 443.
А вот требование настоящего сайта — самое непривычное. Это не декоративная заглушка: реле отдаёт страницы этого сайта всем, кто пришёл без правильного пропуска, и делает это тем же самым кодом, что и обычный веб-сервер. В проекте намеренно не поставляется шаблон сайта — потому что если бы все операторы поставили один и тот же образец, его страницы стали бы отличным признаком для поиска таких серверов. Сайт должен быть ваш, с вашими текстами и вашим оформлением.
Насколько хорошо WEB-прокси прячется от анализа
Разработчики продумали неотличимость довольно дотошно, и это видно по коду. Запрос к служебным адресам без правильного пропуска — с чужим паролем, неверным методом или битыми заголовками — получает ровно тот же ответ, что и запрос несуществующей страницы: тот же код, тот же набор заголовков, то же содержимое. А главная страница с неправильным, лишним или повторённым параметром отдаёт обычную главную с кодом 200 — ровно как любой сайт, который просто не знает такого параметра. В проекте есть отдельный тест, который перебирает десятки комбинаций методов и заголовков и требует побайтового совпадения ответов.
Даже проверка пропуска устроена так, чтобы по времени ответа ничего нельзя было понять: сравнение всегда идёт по всем настроенным секретам до конца, без досрочного выхода, а если параметра в запросе вовсе не было, сервер всё равно проделывает ту же работу вхолостую.
Но об одном стоит сказать прямо: анализа устойчивости к более тонким методам обнаружения в проекте нет. Разбор всех способов блокировки — от списков доменов до анализа формы трафика — вынесен в отдельную заметку Можно ли заблокировать WEB-прокси и как именно. В архитектурном документе не разбирается ни распознавание по размерам и таймингам пакетов, ни характерный ритм долгих ожидающих запросов, ни отпечаток самого браузерного движка. Приём данных здесь устроен так: браузер отправляет запрос, а сервер держит его открытым до 25 секунд и, если данных не появилось, отвечает пустотой — и всё повторяется. Такая ровная пауза сама по себе выглядит характерно, и обсуждения этого риска в документации не найдено. Так что «неотличимо от сайта» здесь означает «неотличимо по содержанию ответов», а не «неотличимо при любом анализе».
Отдельная уязвимая точка — сам домен. Одно реле обслуживает ровно одно имя, и если это имя заблокируют целиком, прокси перестанет работать для всех сразу. Ставить перед сервером сеть доставки контента в первой версии прямо запрещено — в том числе потому, что такая сеть записывала бы адреса запросов в свои журналы, а в адресе едет пропуск. Так что домен смотрит в интернет напрямую своим адресом.
Насколько это быстро
Скорость упирается в устройство транспорта. В базовом режиме в каждую сторону одновременно едет один запрос размером до 2 мегабайт, поэтому потолок считается просто: два мегабайта, делённые на время оборота пакета до сервера и обратно. Разработчики приводят такую таблицу:
Это верхняя граница, реальная скорость ниже: своё забирают накладные расходы протокола, лишний участок пути от реле до MTProxy и работа самого браузерного движка. В качестве целевых показателей приёмки названы 20 Мбит/с при задержке 500 мс и 40 Мбит/с при 200 мс. Обратите внимание, что цели названы в мегабитах, а потолок в таблице — в мегабайтах: 20 Мбит/с — это примерно 2,5 МБ/с, то есть около двух третей теоретического потолка на той же задержке. Никаких измеренных результатов в документации нет — только цели.
Чтобы обойти этот потолок, предусмотрены четыре режима доставки, от самого консервативного до варианта с отдельным постоянным соединением на каждый поток данных. Выбираются они на сервере, клиент об этом даже не знает. Разбор всех четырёх — в заметке про устройство протокола.
Можно ли этим пользоваться прямо сейчас
Короткий ответ на 22 августа 2026 года: поднять сервер можно, а вот подключиться к нему обычным пользователям — ещё нет. Дальше — по частям, потому что ответ разный.
Серверная часть готова. Это не набросок: рабочий код, автоматический установщик, проверка состояния, метрики, скрипт обновления с автоматическим откатом при неудаче. Установщик рассчитан на чистый сервер и за один запуск ставит всё нужное, включая сборку официального MTProxy из проверенного исходника.
Клиентская часть — вот здесь стоп. Код Telegram Desktop написан 9 августа 2026 года и опубликован 18 августа, но лежит в ветке разработки. В выпущенных сборках его нет — последний релиз 7.0.9 вышел 6 августа, то есть ещё до появления этого кода. Значит, попробовать можно только собрав приложение из исходников самостоятельно. Для Android есть экспериментальный прототип с отдельной инструкцией по сборке, для устройств Apple — пока только описание будущей реализации.
Есть и юридическая деталь, которую легко пропустить. У репозитория нет файла лицензии. По умолчанию это значит «все права защищены»: формального разрешения использовать, изменять и распространять код никто не давал. Для личного эксперимента на это обычно закрывают глаза, но закладывать такое в платный сервис до появления лицензии — плохая идея.
Практический вывод. Возиться имеет смысл, если хочется разобраться заранее или если есть конкретная сеть, где не проходит вообще ничего, кроме веб-трафика, и есть возможность собрать клиент самостоятельно. Ждать, что этим в ближайшее время начнут пользоваться обычные люди, не стоит: их приложение просто не поймёт такую ссылку.
Zapret |
_________________
Почему, когда дело касается контроля за интернетом, наши чиновники ссылаются на китайский опыт?
А если речь заходит о наказаниях за коррупцию, то о китайском опыте молчат?
|
|
 |
pazik
Стаж: 18 лет 7 мес.
Сообщений: 101
Ratio: 1495.189
100%
Откуда: 404
|
| Цитата: | бесплатно работать не будет |
Будет. Ищите "free website hosting" и обрящете. Дальше делаете какой-нибудь примитивный веб-сайт (ИИ вам в помощь!). Вживляете туда этот прокси-скрипт и вуаля! Трафика оно при частном использовании много генерить не будет. Нагрузки на процессор/память тоже сильной создавать не должно. Да, требуется оторвать от дивана пятую точку и использовать голову по прямому назначению. Только и всего. P.S. Вопрос только в том позволят ли вам на бесплатном хостинге внешние запросы гонять. Если нет, тогда да, тогда нужен хотя-бы дешевенький VPS/VDS. |
_________________
Гололёд на земле, гололёд...
|
|
|
|
Next
FTP 85, Uploader 100+
Стаж: 19 лет
Сообщений: 2911
Ratio: 150.235
Раздал: 248.5 TB
Поблагодарили: 53640
100%
|
Ну и кто его туда просил лезть? Сидел на своих впн и прокси, и сидел бы дальше, ан нет. Вломился со своим свиным рылом, и всё поломал. Год было тихо и спокойно на вебверсиях телеграм, воцап, ютюб, инстаграм, икс и т.д. Но тут вылезла красная пашечка, и всё полетело к чёртовой матери. Всё, к чему прикасается красная пашечка, превращается в тлен и дерьмо... |
|
|
|
|
gamaz
Стаж: 10 мес. 19 дней
Сообщений: 16
Ratio: 0.716
0%
|
sereoja2 писал(а):  | | AlekseyPopovv писал(а): | |
Где взять? Есть инструкция по разворачиванию на своем впс? |
Тоже не понимаю, перерыл всё, нигде нет нормальной инфы, как этот WEB прокси запустить на своём сервере и привязать к хостингу, везде только про этот MTProto и socks5 которые давно заблокированы в рф. |
|
|
|
|
MAKSUS1255
Стаж: 13 лет 5 мес.
Сообщений: 380
Ratio: 7.351
Поблагодарили: 11
20.19%
|
Когда-то был такой чиновник, он заходил на разваленный завод, и его инвесторы там всякие, которые были заинтересованы в его деньгах, ну давайте назовем это не чиновник, а просто дядька, у которого есть деньги, да. И вот он заходил, и вокруг него лебезили, бегали люди которые были заинтересованы в его вложениях и говорили, слушайте, так этот завод мы когда восстановим, деньги пойдут рекой.
И вот, знаете, я думаю за Telegram примерно то же самое. Но этот дядька поднимал голову, осматривал этот завод и говорил, здесь денег не будет. Вот с Telegram примерно так же, люди бегут массово в безопасность, здорово, но, как говорят, дьявол кроется в деталях. И когда начинает вспоминаться та история, когда открывается секретный брат, который в принципе сооснователь Telegram, а Павел Дуров это, можно сказать, эффективный менеджер, который продаёт задорого смайлики под брендом Павел Дуров, тогда становится понятно, почему люди любят повторять действия за другими людьми. Но разве не понятно, что у Telegram есть сервера, есть дата-центры, и что всё обо всём пишется, что историю можно прошлогоднего чата восстановить двумя кликами у себя прямо в Telegram. То есть это говорит почти как обо всём, но только не о том, что проталкивает Павел Дуров о своей анонимности. Поэтому это я так для мыслящих людей, чтобы понимали, что за красивыми словами и интригами о том, как Павла Дурова преследуют и хотят его сделать на стороне тёмных, это всё пиар, только с обратной стороны. Вот, мыслящим людям надо поднять голову, так осмотреться, посмотреть на Telegram и смайлики, которые они купили, и сказать себе: здесь анонимности не будет. Вот если бы Павел Дуров был на самом деле настоящий создатель Телеграма, можно было бы сказать, да, этот парень не врёт, но он врал всегда, потому что на самом деле сооснователь — это его брат, который создал Телеграм, а Павел Дуров — это менеджер. Но раз этот менеджер пытается людям продать за большие деньги смайлики, подкрепляя то, что Телеграм анонимен, ну тогда, может быть, давайте вспомним, что дьявол в деталях всё-таки. И Павел Дуров конкретно изначально обманул, сказав, что он создатель. Может, стоит всё-таки в детали глянуть и не верить вот этому всему?
Отклоняюсь от темы, но все эти трюки, которые вы делаете, изначально подумайте о том, что дьявол кроется в деталях, прежде чем настраивать какие-то лазейки. |
|
|
|
|
Delerium_tremons
Стаж: 13 лет 2 мес.
Сообщений: 86
Ratio: 158.026
100%
|
gamaz
socks5 в телеге например у меня работает через 3proxy. Проблема в том, что это TCP, да каналы, видосы и голосовухи приходят, все работает. А вот звонки нет, потому что UDP. В это (у меня во всяком случае) не работает MTProto, а WEB и подавно в это работать не будет.
В связи с этим вопрос, что можно докрутить, чтоб звонки заработали? |
|
|
|
|
lve55
Олигарх+
Стаж: 16 лет 10 мес.
Сообщений: 1754
Ratio: 15.072
Раздал: 10.49 TB
Поблагодарили: 5279
100%
Откуда: Петроград - Ленинград
|
Долго и нудно читал. Не понял причем здесь девочки на картинке. Наверно одну зовут WEB, а другую Прокси  Понял?, пора вместо "замудрённого Telegram создавать новый месенджер - Gramoffon, а создаст его группа под руководством профессора Туполобова  По мне так клуб NNM большая польза . |
_________________
Сначала революция, потом - мир... С врагами нужно биться, а не соглашаться!
Иосиф Виссарионович Сталин
|
|
|
|
gamaz
Стаж: 10 мес. 19 дней
Сообщений: 16
Ratio: 0.716
0%
|
| Delerium_tremons писал(а): | gamazsocks5 в телеге например у меня работает через 3proxy. Проблема в том, что это TCP, да каналы, видосы и голосовухи приходят, все работает. А вот звонки нет, потому что UDP. В это (у меня во всяком случае) не работает MTProto, а WEB и подавно в это работать не будет. В связи с этим вопрос, что можно докрутить, чтоб ... |
лично мне плевать на голосовухи и звонки, я этим не пользовался и не собираюсь. С домашнего провайдера да, бывает рабочие прокси даже на socks5. Но через мобильный интернет всё начисто блокируется, с горем пополам работает только по Hysteria2 протоколу. Я говорю именно про прямую прокси для телеграма, чтобы вручную их вбить родственникам и друзьям (которые бояться интернета и vpn) в само приложение телеграма и не плодить лишние приложение на смартфоне, которые будут постоянно висеть и создавать виртуальную или реальную доп. сеть vpn. И вот как раз тут этот WEB прокси бы идеально подошёл бы, с моего домашнего сервера, где есть и Tor и VPN спокойно бы все пользовались без лишних костылей и доп приложений висящих в памяти смартфона и переодически отваливающихся. |
|
|
|
|
TRT
Стаж: 16 лет 1 мес.
Сообщений: 139
Ratio: 100.626
100%
|
| Master of Shadows писал(а): | amarr
Осталось ещё под Linux надыбать...... |
Так там же, на Гитхабе у Flowseal, и готовые пакеты и сорцы https://github.com/Flowseal/tg-ws-proxy/blob/main/docs/RU/README.linux.md | zz13 писал(а): | всё завязано на конкретный сервер с определённым адресом |
На конкретный домен, адрес у него может меняться. Но блочат и по по домену, это да. | zz13 писал(а): | проблемы начнутся когда телега начнёт как вирус использовать чужие адреса и по ним начнёт прилетать блокировка, это уже чистой воды вредительство и паразитизм. |
Что то совсем непонятно, что Вы имеете ввиду. Если на домене не размещена прокся -- ТГ её в принципе использовать не сможет для целей проксирования. Если сайт дрявый, как дуршлаг -- то явно "вредители" найдут гораздо более монетизируемые варианты эксплуатации, чем размещать там ТГшную проксю) |
|
|
|
|
Delerium_tremons
Стаж: 13 лет 2 мес.
Сообщений: 86
Ratio: 158.026
100%
|
gamazНу вот и заворачивай 3proxy, можешь dante, в туннель своего впн, тем более что пишешь что твой домашний сервер. VPS? или реальный физический сервер на чердаке?. Если телефония не нужна, этого за глаза тебе. и никаких торов и прочих мутных web прокси. свой личный прокси, либо работающий на впс, либо(если физический) завернутый в туннель впн |
|
|
|
|
lazy_dog777
Стаж: 12 лет 3 мес.
Сообщений: 27
Ratio: 1.488
100%
|
AlekseyPopovv
Где брать адрес и данные хоста ? |
|
|
|
|
|
|
|
